WebSocket入門及使用指南

最近在一個項目中，須要使用到websocket，因而就花了一點時間來熟悉websocket並總結寫篇blog。

爲什麼使用websocket

在瀏覽器與服務器通訊間，傳統的 HTTP 請求在某些場景下並不理想，好比實時聊天、實時性的小遊戲等等，

其面臨主要兩個缺點：

• 沒法作到消息的「實時性」；
• 服務端沒法主動推送信息；

其基於 HTTP 的主要解決方案有：

• 基於 ajax 的輪詢：客戶端定時或者動態相隔短期內不斷向服務端請求接口，詢問服務端是否有新信息；其缺點也很明顯：多餘的空請求（浪費資源）、數據獲取有延時；
• Long Poll：其採用的是阻塞性的方案，客戶端向服務端發起 ajax 請求，服務端掛起該請求不返回數據直到有新的數據，客戶端接收到數據以後再次執行 Long Poll；該方案中每一個請求都掛起了服務器資源，在大量鏈接的場景下是不可接受的；

能夠看到，基於 HTTP 協議的方案都包含一個本質缺陷 —— 「被動性」，服務端沒法下推消息，僅能由客戶端發起請求不斷詢問是否有新的消息，同時對於客戶端與服務端都存在性能消耗。

WebSocket 是 HTML5 開始提供的一種瀏覽器與服務器間進行全雙工通信的網絡技術。 WebSocket 通訊協議於2011年被IETF定爲標準RFC 6455，WebSocketAPI 被 W3C 定爲標準。 在 WebSocket API 中，瀏覽器和服務器只須要要作一個握手的動做，而後，瀏覽器和服務器之間就造成了一條快速通道。二者之間就直接能夠數據互相傳送。

WebSocket 是 HTML5 中提出的新的網絡協議標準，其包含幾個特色：

• 創建於 TCP 協議之上的應用層；
• 一旦創建鏈接（直到斷開或者出錯），服務端與客戶端握手後則一直保持鏈接狀態，是持久化鏈接；
• 服務端可經過實時通道主動下發消息；
• 數據接收的「實時性（相對）」與「時序性」；
• 較少的控制開銷。鏈接建立後，ws客戶端、服務端進行數據交換時，協議控制的數據包頭部較小。在不包含頭部的狀況下，服務端到客戶端的包頭只有2~10字節（取決於數據包長度），客戶端到服務端的的話，須要加上額外的4字節的掩碼。而HTTP協議每次通訊都須要攜帶完整的頭部。
• 支持擴展。ws協議定義了擴展，用戶能夠擴展協議，或者實現自定義的子協議。（好比支持自定義壓縮算法等）

---

實踐

在瀏覽器中使用 Websocket 很是簡單，在支持 Websocket 的瀏覽器中會提供了原生的 WebSocekt 對象，其中對於消息的接收與數據幀處理在瀏覽器中已經封裝好了。
如下將用一個簡單的例子解釋如何使用 WebSocekt；
瀏覽器中提供了原生類 WebSocket ，使用 new 關鍵字實例化它：

WebSocket WebSocket(String url,optional String | [] protocols); //let websocket = new WebSocket("ws://echo.websocket.org/");

 

接收兩個參數：

• url 表示須要鏈接的地址，好比：ws://localhost:8080；

• protocols 可選參數，能夠是一個字符串或者一個數組，用來表示子協議，這樣作可讓一個服務器實現多種 WebSocket 子協議；
  實例化對象提供兩個方法：

• send 接收一個 String|ArrayBuffer|Blob 數據，做爲數據發送到服務端；

• close 接收一個（可選）的 code（關閉狀態號，默認爲 1000） 與一個（可選）的字符串（表示斷開緣由），客戶端主動斷開鏈接；
  鏈接狀態：

WebSocket 類提供了一些常量表示鏈接狀態：

• WebSocket.CONNECTING 0 鏈接還沒開啓；
• WebSocket.OPEN 1 鏈接已開啓並準備好進行通訊；
• WebSocket.CLOSING 3 鏈接正在關閉的過程當中；
• WebSocket.CLOSED 4 鏈接已經關閉，或者鏈接沒法創建；
• WebSocket 的實例對象中提供了 readyState 屬性來判斷當前狀態；

實例化對象中能夠監聽到如下事件：

• open 鏈接打開的回調事件，這時 readyState 變爲 OPEN；
• message 收到消息的回調事件，同時回調函數接收到一個 MessageEvent 數據；
• close 鏈接關閉的回調事件，這時 readyState 變爲 CLOSED；
• error 創建與鏈接過程發生錯誤的回調事件；

代碼實現

<h1>Echo Test</h1>
    <input id="sendTxt" type="text">
    <button id="sendBtn">發送</button>
    <div id="recv"></div>
    <script type="text/javascript">
        var websocket = new WebSocket("ws://echo.websocket.org/"); // 引入websocket
        websocket.onopen = function(){ console.log('websocket open'); document.getElementById("recv").innerHTML = "Connected"; } // 結束websocket
        websocket.onclose = function(){ console.log('websocket close'); } // 接受到信息
        websocket.onmessage = function(e){ console.log(e.data); document.getElementById("recv").innerHTML = e.data; } // 點擊發送webscoket
        document.getElementById("sendBtn").onclick = function(){ var txt = document.getElementById("sendTxt").value; websocket.send(txt); } </script>

 

首先觸發 open 事件，以後每次發送數據服務端都會回覆數據，所以觸發了 message 事件，若是觸發 close 事件；這裏最後一次發送以後未收到服務端回覆也是由於客戶端當即斷開了鏈接；websocket.send()是發送信息方法

 

---

事件與數據

對 WebSocket 實例監聽事件有兩種方式，這裏以 message 事件爲例：

• 對 onmessage 屬性直接賦值，正如以上：ws.onmessage = function () {};
• 使用 addEventListener 監聽事件，如：ws.addEventListener('message', function () {})；

在 message 回調函數中獲得 MessageEvent 類型參數 e ，咱們須要的數據能夠經過 e.data 獲取；

須要注意的一點是：不論服務端與客戶端，其接受到的數據都是序列化後的字符串（固然也有 ArrayBuffer|Blob 類型數據），不少時候咱們須要解析處理數據，好比 JSON.parse(e.data)；

鏈接穩定性

因爲網絡環境複雜，某些狀況會出現斷開鏈接或者鏈接出錯，須要咱們在 close 或者 error 事件中監聽非正常斷開並重連；

因爲一些緣由在 error 時瀏覽器並不會響應回調事件，所以穩妥的作法還須要在 open 以後開啓一個定時任務去判斷當前的鏈接狀態 readyState ，在出現異常狀況下嘗試重連；

心跳

websocket規範定義了心跳機制，一方能夠經過發送ping（opcode 0x9）消息給另外一方，另外一方收到ping後應該儘量快的返回pong（0xA）。

心跳機制是用於檢測鏈接的對方在線狀態，所以若是沒有心跳，那麼沒法判斷一方還在鏈接狀態中，一些網絡層好比 nginx 或者瀏覽器層會主動斷開鏈接，

在 JavaScript 中，WebSocket 並無開放 ping/pong 的 API ，雖然瀏覽器自帶了心跳處理，然而不一樣廠商的實現也不盡相同，所以須要在咱們開發時候與服務端約定好一個自實現的心跳機制；

好比瀏覽器中，檢測到 open 事件後，啓動一個定時任務，每次發送數據 0x9 給服務端，而服務端返回 0xA 做爲響應；

實踐下來，心跳的定時任務通常是相隔 15-20 秒發送一次。

 

舉例，WebSocket服務端向客戶端發送ping，只須要以下代碼（採用ws模塊）

ws.ping('', false, true);

 

 

網絡協議

前文說到，Websocket 是創建與 TCP 之上，那麼其與 HTTP 協議有和關係呢？

Websocket 鏈接分爲建連階段與鏈接階段，在創建鏈接階段藉助於 HTTP ，而在鏈接階段則與 HTTP 無關。

建連階段

從瀏覽器的 Network 中，找到 ws 鏈接，能夠看到：

General
Request URL:ws://localhost:8080/
Request Method:GET
Status Code:101 Switching Protocols

Response Headers
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: py9bt3HbjicUUmFWJfI0nhGombo=

Request Headers
GET ws://localhost:8080/ HTTP/1.1
Host: localhost:8080
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://localhost:8080
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,zh-TW;q=0.7,la;q=0.6,ja;q=0.5
Sec-WebSocket-Key: 2idFk3+96Hs5hh+c9GOQCg==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

 

這是一個標準的 HTTP 請求，相比於咱們常見的 HTTP 請求協議，請求頭中多了幾個字段：

Connection: Upgrade Upgrade: websocket Sec-WebSocket-Version: 13 Sec-WebSocket-Key: 2idFk3+96Hs5hh+c9GOQCg==

重點請求首部意義以下：

• Connection: Upgrade：表示要升級協議
• Upgrade: websocket：表示要升級到websocket協議。
• Sec-WebSocket-Version: 13：表示websocket的版本。若是服務端不支持該版本，須要返回一個Sec-WebSocket-Versionheader，裏面包含服務端支持的版本號。
• Sec-WebSocket-Key ：是一個 Base64 encode 的值，由瀏覽器隨機生成的，用於驗證服務器鏈接的正確性；與後面服務端響應首部的Sec-WebSocket-Accept是配套的，提供基本的防禦，好比惡意的鏈接，或者無心的鏈接。
• Connection 爲 Upgrade ，Upgrade 爲 websocket ，表示告知 Nginx 與 Apache 等服務器該次鏈接並不是爲 HTTP 鏈接，實質上是一個 websocket ，所以服務器會轉發到相應的 websocket 任務處理；
• Sec-WebSocket-Versio 表示爲使用的 websocket 服務版本；

 

響應頭中：

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: py9bt3HbjicUUmFWJfI0nhGombo=

 

能夠看到其返回狀態碼爲 101 ，表示切換協議；
Upgrade 與 Connection 用於回覆客戶端表示已經切換協議成功；
Sec-WebSocket-Accept 字段與 Sec-WebSocket-Key 相對應，用於驗證服務的正確性；

鏈接階段

當經過 HTTP 創建鏈接握手後，接下來則是真正的 Websocket 鏈接了，其基於 TCP 收發數據，Websocket 封裝並開放接口。

WSS

在 HTTP 協議中，不少時候爲了加密與安全須要使用 HTTPS 請求（HTTP + TCL）；
相應的，在 Websocket 協議中，也是可使用加密傳輸的 —— wss ，好比 wss://localhost:8080。

使用的也是與 HTTPS 同樣的證書，在這裏通常是交由 Nginx 等服務層去作證書處理。

 

Sec-WebSocket-Key/Accept的做用

前面提到了，Sec-WebSocket-Key/Sec-WebSocket-Accept在主要做用在於提供基礎的防禦，減小惡意鏈接、意外鏈接。

做用大體概括以下：

1. 避免服務端收到非法的websocket鏈接（好比http客戶端不當心請求鏈接websocket服務，此時服務端能夠直接拒絕鏈接）
2. 確保服務端理解websocket鏈接。由於ws握手階段採用的是http協議，所以可能ws鏈接是被一個http服務器處理並返回的，此時客戶端能夠經過Sec-WebSocket-Key來確保服務端認識ws協議。（並不是百分百保險，好比老是存在那麼些無聊的http服務器，光處理Sec-WebSocket-Key，但並無實現ws協議。。。）
3. 用瀏覽器裏發起ajax請求，設置header時，Sec-WebSocket-Key以及其餘相關的header是被禁止的。這樣能夠避免客戶端發送ajax請求時，意外請求協議升級（websocket upgrade）
4. 能夠防止反向代理（不理解ws協議）返回錯誤的數據。好比反向代理先後收到兩次ws鏈接的升級請求，反向代理把第一次請求的返回給cache住，而後第二次請求到來時直接把cache住的請求給返回（無心義的返回）。
5. Sec-WebSocket-Key主要目的並非確保數據的安全性，由於Sec-WebSocket-Key、Sec-WebSocket-Accept的轉換計算公式是公開的，並且很是簡單，最主要的做用是預防一些常見的意外狀況（非故意的）。

強調：Sec-WebSocket-Key/Sec-WebSocket-Accept 的換算，只能帶來基本的保障，但鏈接是否安全、數據是否安全、客戶端/服務端是否合法的 ws客戶端、ws服務端，其實並無實際性的保證。

 

數據掩碼的做用

WebSocket協議中，數據掩碼的做用是加強協議的安全性。但數據掩碼並非爲了保護數據自己，由於算法自己是公開的，運算也不復雜。除了加密通道自己，彷佛沒有太多有效的保護通訊安全的辦法。

那麼爲何還要引入掩碼計算呢，除了增長計算機器的運算量外彷佛並無太多的收益。

答案仍是兩個字：安全。但並非爲了防止數據泄密，而是爲了防止早期版本的協議中存在的代理緩存污染攻擊（proxy cache poisoning attacks）等問題。

 

 

 

本文參考文章: https://qiutc.me/post/websocket-guide.html 、https://segmentfault.com/a/1190000012709475