一文喫透 WebSocket 原理

哈羅大家好，我是 Range。

通常我們開發 H5，都是基於 HTTP 協議，典型的請求 / 響應模式。隨着 web 能力越來越豐富，更多的小夥伴有機會嘗試一些新的網絡協議，比如 WebSocket ，這在一些實時性要求比較高的場景出現頻率很高。今天帶來一篇關於 WebSocket 原理的文章，對於接觸過的同學，可以看看自己是否已經掌握了這些基礎知識，還不瞭解的同學也可以擴展下知識面，畢竟知識面越廣，將來在項目裏進行技術選型、決策時候，才能更加科學、嚴謹。

下面是正文部分。

一、前言

踩着年末的尾巴，提前佈局來年，爲來年的工作做個好的鋪墊，所以就開始了面試歷程，因爲項目中使用到了 WebSocket ，面試官在深挖項目經驗的時候，也難免提到 WebSocket 相關的知識點，因爲之前並沒有考慮這麼深，所以，回答的還是有所欠缺，因此，趕緊趁熱再熟悉熟悉，也藉此機會，整理出來供大家咀嚼，每個項目都有其值得挖掘的閃光點，要用有愛的眼睛👁去發現。

二、什麼是 WebSocket

WebSocket 是一種在單個 TCP 連接上進行全雙工通信的協議。WebSocket 使得客戶端和服務器之間的數據交換變得更加簡單，允許服務端主動向客戶端推送數據。

在 WebSocket API 中，瀏覽器和服務器只需要完成一次握手，兩者之間就直接可以創建持久性的連接，並進行雙向數據傳輸。（維基百科）

WebSocket 本質上一種計算機網絡應用層的協議，用來彌補 http 協議在持久通信能力上的不足。

WebSocket 協議在 2008 年誕生，2011 年成爲國際標準。現在最新版本瀏覽器都已經支持了。

它的最大特點就是，服務器可以主動向客戶端推送信息，客戶端也可以主動向服務器發送信息，是真正的雙向平等對話，屬於服務器推送技術的一種。

WebSocket 的其他特點包括：

（1）建立在 TCP 協議之上，服務器端的實現比較容易。

（2）與 HTTP 協議有着良好的兼容性。默認端口也是 80 和 443，並且握手階段採用 HTTP 協議，因此握手時不容易屏蔽，能通過各種 HTTP 代理服務器。

（3）數據格式比較輕量，性能開銷小，通信高效。

（4）可以發送文本，也可以發送二進制數據。

（5）沒有同源限制，客戶端可以與任意服務器通信。

（6）協議標識符是ws（如果加密，則爲wss），服務器網址就是 URL。

ws://example.com:80/some/path

ws://example.com:80/some/path

爲什麼需要 WebSocket？

我們已經有了 HTTP 協議，爲什麼還需要另一個協議？它能帶來什麼好處？

因爲 HTTP 協議有一個缺陷：通信只能由客戶端發起，不具備服務器推送能力。

舉例來說，我們想了解查詢今天的實時數據，只能是客戶端向服務器發出請求，服務器返回查詢結果。HTTP 協議做不到服務器主動向客戶端推送信息。

這種單向請求的特點，註定瞭如果服務器有連續的狀態變化，客戶端要獲知就非常麻煩。我們只能使用 "輪詢"：每隔一段時候，就發出一個詢問，瞭解服務器有沒有新的信息。最典型的場景就是聊天室。輪詢的效率低，非常浪費資源（因爲必須不停連接，或者 HTTP 連接始終打開）。

在 WebSocket 協議出現以前，創建一個和服務端進雙通道通信的 web 應用，需要依賴 HTTP 協議，進行不停的輪詢，這會導致一些問題：

服務端被迫維持來自每個客戶端的大量不同的連接
大量的輪詢請求會造成高開銷，比如會帶上多餘的 header，造成了無用的數據傳輸。

http 協議本身是沒有持久通信能力的，但是我們在實際的應用中，是很需要這種能力的，所以，爲了解決這些問題，WebSocket 協議由此而生，於 2011 年被 IETF 定爲標準 RFC6455，並被 RFC7936 所補充規範。

並且在 HTML5 標準中增加了有關 WebSocket 協議的相關 api，所以只要實現了 HTML5 標準的客戶端，就可以與支持 WebSocket 協議的服務器進行全雙工的持久通信了。

WebSocket 與 HTTP 的區別

WebSocket 與 HTTP 的關係圖：

相同點： 都是一樣基於 TCP 的，都是可靠性傳輸協議。都是應用層協議。

聯繫： WebSocket 在建立握手時，數據是通過 HTTP 傳輸的。但是建立之後，在真正傳輸時候是不需要 HTTP 協議的。

下面一張圖說明了 HTTP 與 WebSocket 的主要區別：

1、WebSocket 是雙向通信協議，模擬 Socket 協議，可以雙向發送或接受信息，而 HTTP 是單向的；2、WebSocket 是需要瀏覽器和服務器握手進行建立連接的，而 http 是瀏覽器發起向服務器的連接。

注意：雖然 HTTP/2 也具備服務器推送功能，但 HTTP/2 只能推送靜態資源，無法推送指定的信息。

三、WebSocket 協議的原理

與 http 協議一樣，WebSocket 協議也需要通過已建立的 TCP 連接來傳輸數據。具體實現上是通過 http 協議建立通道，然後在此基礎上用真正的 WebSocket 協議進行通信，所以 WebSocket 協議和 http 協議是有一定的交叉關係的。

首先，WebSocket 是一個持久化的協議，相對於 HTTP 這種非持久的協議來說。簡單的舉個例子吧，用目前應用比較廣泛的 PHP 生命週期來解釋。

HTTP 的生命週期通過 Request 來界定，也就是一個 Request 一個 Response ，那麼在 HTTP1.0 中，這次 HTTP 請求就結束了。

在 HTTP1.1 中進行了改進，使得有一個 keep-alive，也就是說，在一個 HTTP 連接中，可以發送多個 Request，接收多個 Response。但是請記住 Request = Response，在 HTTP 中永遠是這樣，也就是說一個 Request 只能有一個 Response。而且這個 Response 也是被動的，不能主動發起。

首先 WebSocket 是基於 HTTP 協議的，或者說借用了 HTTP 協議來完成一部分握手。

首先我們來看個典型的 WebSocket 握手

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

熟悉 HTTP 的童鞋可能發現了，這段類似 HTTP 協議的握手請求中，多了這麼幾個東西。

Upgrade: websocket
Connection: Upgrade

Upgrade: websocket
Connection: Upgrade

這個就是 WebSocket 的核心了，告訴 Apache 、 Nginx 等服務器：注意啦，我發起的請求要用 WebSocket 協議，快點幫我找到對應的助理處理~ 而不是那個老土的 HTTP。

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

首先， Sec-WebSocket-Key 是一個 Base64 encode 的值，這個是瀏覽器隨機生成的，告訴服務器：泥煤，不要忽悠我，我要驗證你是不是真的是 WebSocket 助理。

然後， Sec_WebSocket-Protocol 是一個用戶定義的字符串，用來區分同 URL 下，不同的服務所需要的協議。簡單理解：今晚我要服務 A，別搞錯啦~

最後， Sec-WebSocket-Version 是告訴服務器所使用的 WebSocket Draft （協議版本），在最初的時候，WebSocket 協議還在 Draft 階段，各種奇奇怪怪的協議都有，而且還有很多期奇奇怪怪不同的東西，什麼 Firefox 和 Chrome 用的不是一個版本之類的，當初 WebSocket 協議太多可是一個大難題。。不過現在還好，已經定下來啦~ 大家都使用同一個版本：服務員，我要的是 13 歲的噢→_→

然後服務器會返回下列東西，表示已經接受到請求，成功建立 WebSocket 啦！

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

這裏開始就是 HTTP 最後負責的區域了，告訴客戶，我已經成功切換協議啦~

Upgrade: websocket
Connection: Upgrade

Upgrade: websocket
Connection: Upgrade

依然是固定的，告訴客戶端即將升級的是 WebSocket 協議，而不是 mozillasocket，lurnarsocket 或者 shitsocket。

然後， Sec-WebSocket-Accept 這個則是經過服務器確認，並且加密過後的 Sec-WebSocket-Key 。服務器：好啦好啦，知道啦，給你看我的 ID CARD 來證明行了吧。

後面的， Sec-WebSocket-Protocol 則是表示最終使用的協議。

至此，HTTP 已經完成它所有工作了，接下來就是完全按照 WebSocket 協議進行了。

總結，WebSocket 連接的過程是：

首先，客戶端發起 http 請求，經過 3 次握手後，建立起 TCP 連接；http 請求裏存放 WebSocket 支持的版本號等信息，如：Upgrade、Connection、WebSocket-Version 等；

然後，服務器收到客戶端的握手請求後，同樣採用 HTTP 協議回饋數據；

最後，客戶端收到連接成功的消息後，開始藉助於 TCP 傳輸信道進行全雙工通信。

四、Websocket 的優缺點

優點：

WebSocket 協議一旦建議後，互相溝通所消耗的請求頭是很小的
服務器可以向客戶端推送消息了

缺點：

少部分瀏覽器不支持，瀏覽器支持的程度與方式有區別（IE10）

五、WebSocket 應用場景

即時聊天通信
多玩家遊戲
在線協同編輯 / 編輯
實時數據流的拉取與推送
體育 / 遊戲實況
實時地圖位置
即時Web應用程序：即時Web應用程序使用一個Web套接字在客戶端顯示數據，這些數據由後端服務器連續發送。在WebSocket 中，數據被連續推送 / 傳輸到已經打開的同一連接中，這就是爲什麼WebSocket更快並提高了應用程序性能的原因。例如在交易網站或比特幣交易中，這是最不穩定的事情，它用於顯示價格波動，數據被後端服務器使用 Web 套接字通道連續推送到客戶端。
遊戲應用程序：在遊戲應用程序中，你可能會注意到，服務器會持續接收數據，而不會刷新用戶界面。屏幕上的用戶界面會自動刷新，而且不需要建立新的連接，因此在WebSocket遊戲應用程序中非常有幫助。
聊天應用程序：聊天應用程序僅使用WebSocket建立一次連接，便能在訂閱戶之間交換，發佈和廣播消息。它重複使用相同的WebSocket連接，用於發送和接收消息以及一對一的消息傳輸。

不能使用 WebSocket 的場景

如果我們需要通過網絡傳輸的任何實時更新或連續數據流，則可以使用WebSocket。如果我們要獲取舊數據，或者只想獲取一次數據供應用程序使用，則應該使用HTTP協議，不需要很頻繁或僅獲取一次的數據可以通過簡單的HTTP請求查詢，因此在這種情況下最好不要使用WebSocket。

注意：如果僅加載一次數據，則RESTful Web服務足以從服務器獲取數據。

六、websocket 斷線重連

心跳就是客戶端定時的給服務端發送消息，證明客戶端是在線的，如果超過一定的時間沒有發送則就是離線了。

如何判斷在線離線？

當客戶端第一次發送請求至服務端時會攜帶唯一標識、以及時間戳，服務端到 db 或者緩存去查詢改請求的唯一標識，如果不存在就存入 db 或者緩存中，

第二次客戶端定時再次發送請求依舊攜帶唯一標識、以及時間戳，服務端到 db 或者緩存去查詢改請求的唯一標識，如果存在就把上次的時間戳拿取出來，使用當前時間戳減去上次的時間，

得出的毫秒秒數判斷是否大於指定的時間，若小於的話就是在線，否則就是離線；

如何解決斷線問題

通過查閱資料瞭解到 nginx 代理的 websocket 轉發，無消息連接會出現超時斷開問題。網上資料提到解決方案兩種，一種是修改 nginx 配置信息，第二種是 websocket 發送心跳包。

下面就來總結一下本次項目實踐中解決的 websocket 的斷線和重連這兩個問題的解決方案。

主動觸發包括主動斷開連接，客戶端主動發送消息給後端

主動斷開連接

ws.close();

ws.close();

主動斷開連接，根據需要使用，基本很少用到。

主動發送消息

ws.send("hello world");

ws.send("hello world");

針對 websocket 斷線我們來分析一下，

斷線的可能原因 1：websocket 超時沒有消息自動斷開連接，應對措施：

這時候我們就需要知道服務端設置的超時時長是多少，在小於超時時間內發送心跳包，有 2 中方案: 一種是客戶端主動發送上行心跳包，另一種方案是服務端主動發送下行心跳包。

下面主要講一下客戶端也就是前端如何實現心跳包：

首先了解一下心跳包機制

跳包之所以叫心跳包是因爲：它像心跳一樣每隔固定時間發一次，以此來告訴服務器，這個客戶端還活着。事實上這是爲了保持長連接，至於這個包的內容，是沒有什麼特別規定的，不過一般都是很小的包，或者只包含包頭的一個空包。

在 TCP 的機制裏面，本身是存在有心跳包的機制的，也就是 TCP 的選項：SO_KEEPALIVE。系統默認是設置的 2 小時的心跳頻率。但是它檢查不到機器斷電、網線拔出、防火牆這些斷線。而且邏輯層處理斷線可能也不是那麼好處理。一般，如果只是用於保活還是可以的。

心跳包一般來說都是在邏輯層發送空的 echo 包來實現的。下一個定時器，在一定時間間隔下發送一個空包給客戶端，然後客戶端反饋一個同樣的空包回來，服務器如果在一定時間內收不到客戶端發送過來的反饋包，那就只有認定說掉線了。

在長連接下，有可能很長一段時間都沒有數據往來。理論上說，這個連接是一直保持連接的，但是實際情況中，如果中間節點出現什麼故障是難以知道的。更要命的是，有的節點 (防火牆) 會自動把一定時間之內沒有數據交互的連接給斷掉。在這個時候，就需要我們的心跳包了，用於維持長連接，保活。

心跳檢測步驟：

// 前端解決方案：心跳檢測
var heartCheck = {
    timeout: 30000, //30秒發一次心跳
    timeoutObj: null,
    serverTimeoutObj: null,
    reset: function(){
        clearTimeout(this.timeoutObj);
        clearTimeout(this.serverTimeoutObj);
        return this;
    },
    start: function(){
        var self = this;
        this.timeoutObj = setTimeout(function(){
            //這裏發送一個心跳，後端收到後，返回一個心跳消息，
            //onmessage拿到返回的心跳就說明連接正常
            ws.send("ping");
            console.log("ping!")
    
            self.serverTimeoutObj = setTimeout(function(){//如果超過一定時間還沒重置，說明後端主動斷開了
                ws.close(); //如果onclose會執行reconnect，我們執行ws.close()就行了.如果直接執行reconnect 會觸發onclose導致重連兩次
            }, self.timeout);
        }, this.timeout);
    }
}

客戶端每隔一個時間間隔發生一個探測包給服務器
客戶端發包時啓動一個超時定時器
服務器端接收到檢測包，應該回應一個包
如果客戶機收到服務器的應答包，則說明服務器正常，刪除超時定時器
如果客戶端的超時定時器超時，依然沒有收到應答包，則說明服務器掛了

斷線的可能原因 2：websocket 異常包括服務端出現中斷，交互切屏等等客戶端異常中斷等等

當若服務端宕機了，客戶端怎麼做、服務端再次上線時怎麼做？

客戶端則需要斷開連接，通過 onclose 關閉連接，服務端再次上線時則需要清除之間存的數據，若不清除則會造成只要請求到服務端的都會被視爲離線。

針對這種異常的中斷解決方案就是處理重連，下面我們給出的重連方案是使用 js 庫處理：引入 reconnecting-websocket.min.js，ws 建立鏈接方法使用 js 庫 api 方法：

var ws = new ReconnectingWebSocket(url);
// 斷線重連：
reconnectSocket(){
    if ('ws' in window) {
        ws = new ReconnectingWebSocket(url);
    } else if ('MozWebSocket' in window) {
       ws = new MozWebSocket(url);
    } else {
      ws = new SockJS(url);
    }
}

斷網監測支持使用 js 庫：offline.min.js

onLineCheck(){
    Offline.check();
    console.log(Offline.state,'---Offline.state');
    console.log(this.socketStatus,'---this.socketStatus');
    
    if(!this.socketStatus){
        console.log('網絡連接已斷開！');
        if(Offline.state === 'up' && websocket.reconnectAttempts > websocket.maxReconnectInterval){
            window.location.reload();
        }
        reconnectSocket();
    }else{
        console.log('網絡連接成功！');
        websocket.send("heartBeat");
    }
}
    
// 使用：在websocket斷開鏈接時調用網絡中斷監測
websocket.onclose => () {
    onLineCheck();
};

以上方案，只是拋磚引玉，如果大家有更好的解決方案歡迎評論區分享交流。

七、總結

WebSocket 是爲了在 web 應用上進行雙通道通信而產生的協議，相比於輪詢 HTTP 請求的方式，WebSocket 有節省服務器資源，效率高等優點。
WebSocket 中的掩碼是爲了防止早期版本中存在中間緩存污染攻擊等問題而設置的，客戶端向服務端發送數據需要掩碼，服務端向客戶端發送數據不需要掩碼。
WebSocket 中 Sec-WebSocket-Key 的生成算法是拼接服務端和客戶端生成的字符串，進行 SHA1 哈希算法，再用 base64 編碼。
WebSocket 協議握手是依靠 HTTP 協議的，依靠於 HTTP 響應 101 進行協議升級轉換。

原文地址：https://juejin.cn/post/7020964728386093093

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/sxCbauPhybjchnfxFDG6yA