記錄--WebSocket 原理_ZenDei技術網路在線

這裡給大家分享我在網上總結出來的一些知識，希望對大家有所幫助一、什麼是WebSocket WebSocket 是一種在單個TCP連接上進行全雙工通信的協議。WebSocket 使得客戶端和伺服器之間的數據交換變得更加簡單，允許服務端主動向客戶端推送數據。在 WebSocket API 中，瀏覽器 ...

這裡給大家分享我在網上總結出來的一些知識，希望對大家有所幫助

一、什麼是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

為什麼需要 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

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

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 是一個 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 最後負責的區域了，告訴客戶，我已經成功切換協議啦~

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.send("hello world");

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

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

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

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

首先瞭解一下心跳包機制

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

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

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

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

心跳檢測步驟：
1. 客戶端每隔一個時間間隔發生一個探測包給伺服器
2. 客戶端發包時啟動一個超時定時器
3. 伺服器端接收到檢測包，應該回應一個包
4. 如果客戶機收到伺服器的應答包，則說明伺服器正常，刪除超時定時器
5. 如果客戶端的超時定時器超時，依然沒有收到應答包，則說明伺服器掛了

// 前端解決方案：心跳檢測
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進行協議升級轉換。

記錄--WebSocket 原理