WebSocket 協議詳解

一、WebSocket 協議背景

早期，在網站上推送消息給用戶，只能通過輪詢的方式或 Comet 技術。輪詢就是瀏覽器每隔幾秒鐘向服務端發送 HTTP 請求，然後服務端返回消息給客戶端。

輪詢技術一般在瀏覽器上就是使用 setInerval 或 setTimeout

這種方式的缺點：

需要不斷的向服務端發送 HTTP 請求，這種就比較浪費頻寬資源。而且發送 HTTP 請求只能由客戶端發起，這也是早期 HTTP1.0/1.1 協議的一個缺點。它做不到由服務端向客戶端發起請求。

為了能實現客戶端和服務端的雙向通訊，經過多年發展於是 WebSocket 協議在 2008 年就誕生了。

它最初是在 HTML5 中引入的。經過多年發展後，該協議慢慢被多個瀏覽器支援，RFC 在 2011 年就把該協議作為一個國際標準，叫 rfc6455。

二、協議簡介

WebSocket 是一種支援雙向通訊的網路協議。

雙向通訊：客戶端（比如瀏覽器）可以向服務端發送消息，服務端也可以主動向客戶端發送消息。

這樣就實現了客戶端和服務端的雙向通訊，那麼上面所說的消息推送就比較容易實現了。

原先的 HTTP1.0/1.1 只能是客戶端向服務端發送消息。

協議特點：

建立在 TCP 協議之上。
WebSocket 協議是從 HTTP 協議升級而來。
與 HTTP 協議良好兼容新。默認埠是 80 和 443，握手階段採用 HTTP 協議。
數據格式比較輕量，通訊效率高，性能開銷小。
可以發送文本，也可以發送二進位數據。
沒有同源限制，客戶端可以與任意服務端通訊。
協議標識符是 ws（如果加密，則為 wss），伺服器網址就是 URL。
可以支援擴展，定了擴展協議。
保持連接狀態，websocket 是一種有狀態的協議，通訊就可以省略部分狀態資訊。
實時性更強，因為是雙向通訊協議，所以服務端可以隨時向客戶端發送數據。

三、HTTP 升級到 WebSocket 過程

WebSocket 協議建立復用了 HTTP 的握手請求過程。

客戶端通過 HTTP 請求與 WebSocket 服務端協商升級協議。協議完成後，後續的數據交互則遵循 WebSocket 的協議。

客戶端發起協議升級請求

GET / HTTP/1.1
Host: localhost:8080
Origin: //127.0.0.1:3000
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw==

說明：上面請求資訊忽略了 HTTP 的一些非必要頭部請求資訊，剔除多餘的干擾。

Origin: //127.0.0.1:3000 ：原始的協議和URL
Connection: Upgrade：表示要升級協議了
Upgrade: websocket：表示要升級到 WebSocket 協議；
Sec-WebSocket-Version: 13：表示 WebSocket 的版本。如果服務端不支援該版本，需要返回一個 Sec-WebSocket-Versionheader ，裡面包含服務端支援的版本號
Sec-WebSocket-Key：與後面服務端響應首部的 Sec-WebSocket-Accept 是配套的，提供基本的防護，比如惡意的連接，或者無意的連接

服務端響應協議升級

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

HTTP/1.1 101 Switching Protocols：狀態碼 101 表示協議切換
Sec-WebSocket-Accept：根據客戶端請求首部的 Sec-WebSocket-Key 計算出來
將 Sec-WebSocket-Key 跟 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 拼接。

通過 SHA1 計算出摘要，並轉成 base64 字元串。計算公式如下：
```
Base64(sha1(Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11))
```
Connection:Upgrade：表示協議升級
Upgrade: websocket：升級到 websocket 協議

四、WebSocket 數據交換

數據幀格式

在 WebSocket 協議中，客戶端與服務端數據交換的最小資訊單位叫做幀（frame），由 1 個或多個幀按照次序組成一條完整的消息（message）。

數據傳輸的格式是由 ABNF 來描述的。

WebSocket 數據幀的統一格式如下圖：

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

（//www.rfc-editor.org/rfc/rfc6455.html#section-5.2 Base Framing Protocol）

上面圖中名詞解釋：

名詞	說明	大小
FIN	如果是 1，表示這是消息（message）的最後一個分片（fragment）；如果是 0，表示不是是消息（message）的最後一個分片（fragment）	1 個比特
RSV1, RSV2, RSV3	一般情況下全為 0。當客戶端、服務端協商採用 WebSocket 擴展時，這三個標誌位可以非 0，且值的含義由擴展進行定義。如果出現非零的值，且並沒有採用 WebSocket 擴展，連接出錯	各占 1 個比特
opcode	操作程式碼，Opcode 的值決定了應該如何解析後續的數據載荷（data payload）。如果操作程式碼是不認識的，那麼接收端應該斷開連接（fail the connection）	4 個比特
mask	表示是否要對數據載荷進行掩碼操作。從客戶端向服務端發送數據時，需要對數據進行掩碼操作；從服務端向客戶端發送數據時，不需要對數據進行掩碼操作。如果服務端接收到的數據沒有進行過掩碼操作，服務端需要斷開連接。如果 Mask 是 1，那麼在 Masking-key 中會定義一個掩碼鍵（masking key），並用這個掩碼鍵來對數據載荷進行反掩碼。所有客戶端發送到服務端的數據幀，Mask 都是 1。	1 個比特
Payload length	數據載荷的長度，單位是位元組。假設數 Payload length === x，如果： x 為 0~126：數據的長度為 x 位元組。 x 為 126：後續 2 個位元組代表一個 16 位的無符號整數，該無符號整數的值為數據的長度。 x 為 127：後續 8 個位元組代表一個 64 位的無符號整數（最高位為 0），該無符號整數的值為數據的長度。此外，如果 payload length 佔用了多個位元組的話，payload length 的二進位表達採用網路序（big endian，重要的位在前）。	為 7 位，或 7+16 位，或 1+64 位。
Masking-key	所有從客戶端傳送到服務端的數據幀，數據載荷都進行了掩碼操作，Mask 為 1，且攜帶了 4 位元組的 Masking-key。如果 Mask 為 0，則沒有 Masking-key。備註：載荷數據的長度，不包括 mask key 的長度。	0 或 4 位元組（32 位
Payload data	載荷數據：包括了擴展數據、應用數據。其中，擴展數據 x 位元組，應用數據 y 位元組。The “Payload data” is defined as “Extension data” concatenated with “Application data”. 擴展數據：如果沒有協商使用擴展的話，擴展數據數據為 0 位元組。所有的擴展都必須聲明擴展數據的長度，或者可以如何計算出擴展數據的長度。此外，擴展如何使用必須在握手階段就協商好。如果擴展數據存在，那麼載荷數據長度必須將擴展數據的長度包含在內。應用數據：任意的應用數據，在擴展數據之後（如果存在擴展數據），佔據了數據幀剩餘的位置。載荷數據長度減去擴展數據長度，就得到應用數據的長度。	(x+y) 位元組

表中 opcode 操作碼：

%x0：表示一個延續幀（continuation frame）。當 Opcode 為 0 時，表示本次數據傳輸採用了數據分片，當前收到的數據幀為其中一個數據分片。

%x1：表示這是一個文本幀（frame），text frame

%x2：表示這是一個二進位幀（frame），binary frame

%x3-7：保留的操作程式碼，用於後續定義的非控制幀。

%x8：表示連接斷開。connection close

%x9：表示這是一個 ping 操作。a ping

%xA：表示這是一個 pong 操作。a pong

%xB-F：保留的操作程式碼，用於後續定義的控制幀。

數據幀另外一種表達方式

    ws-frame                = frame-fin           ; 1 bit in length
                              frame-rsv1          ; 1 bit in length
                              frame-rsv2          ; 1 bit in length
                              frame-rsv3          ; 1 bit in length
                              frame-opcode        ; 4 bits in length
                              frame-masked        ; 1 bit in length
                              frame-payload-length   ; either 7, 7+16,
                                                     ; or 7+64 bits in
                                                     ; length
                              [ frame-masking-key ]  ; 32 bits in length
                              frame-payload-data     ; n*8 bits in
                                                     ; length, where
                                                     ; n >= 0

    frame-fin               = %x0 ; more frames of this message follow
                            / %x1 ; final frame of this message
                                  ; 1 bit in length

    frame-rsv1              = %x0 / %x1
                              ; 1 bit in length, MUST be 0 unless
                              ; negotiated otherwise

    frame-rsv2              = %x0 / %x1
                              ; 1 bit in length, MUST be 0 unless
                              ; negotiated otherwise

    frame-rsv3              = %x0 / %x1
                              ; 1 bit in length, MUST be 0 unless
                              ; negotiated otherwise

    frame-opcode            = frame-opcode-non-control /
                              frame-opcode-control /
                              frame-opcode-cont

    frame-opcode-cont       = %x0 ; frame continuation

    frame-opcode-non-control= %x1 ; text frame
                            / %x2 ; binary frame
                            / %x3-7
                            ; 4 bits in length,
                            ; reserved for further non-control frames

    frame-opcode-control    = %x8 ; connection close
                            / %x9 ; ping
                            / %xA ; pong
                            / %xB-F ; reserved for further control
                                    ; frames
                                    ; 4 bits in length
                                    
    frame-masked            = %x0
                            ; frame is not masked, no frame-masking-key
                            / %x1
                            ; frame is masked, frame-masking-key present
                            ; 1 bit in length

    frame-payload-length    = ( %x00-7D )
                            / ( %x7E frame-payload-length-16 )
                            / ( %x7F frame-payload-length-63 )
                            ; 7, 7+16, or 7+64 bits in length,
                            ; respectively

    frame-payload-length-16 = %x0000-FFFF ; 16 bits in length

    frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF
                            ; 64 bits in length

    frame-masking-key       = 4( %x00-FF )
                              ; present only if frame-masked is 1
                              ; 32 bits in length

    frame-payload-data      = (frame-masked-extension-data
                               frame-masked-application-data)
                            ; when frame-masked is 1
                              / (frame-unmasked-extension-data
                                frame-unmasked-application-data)
                            ; when frame-masked is 0

    frame-masked-extension-data     = *( %x00-FF )
                            ; reserved for future extensibility
                            ; n*8 bits in length, where n >= 0

    frame-masked-application-data   = *( %x00-FF )
                            ; n*8 bits in length, where n >= 0

    frame-unmasked-extension-data   = *( %x00-FF )
                            ; reserved for future extensibility
                            ; n*8 bits in length, where n >= 0

    frame-unmasked-application-data = *( %x00-FF )
                            ; n*8 bits in length, where n >= 0

客戶端到服務端的掩碼演算法

//www.rfc-editor.org/rfc/rfc6455.html#section-5.3 Client-to-Server Masking

掩碼鍵（Masking-key）是由客戶端挑選出來的 32 位的隨機數。掩碼操作不會影響數據載荷的長度。掩碼、反掩碼操作都採用如下演算法：

舉例說明：

Octet i of the transformed data ("transformed-octet-i") is the XOR of
octet i of the original data ("original-octet-i") with octet at index
i modulo 4 of the masking key ("masking-key-octet-j"):

     j                   = i MOD 4
     transformed-octet-i = original-octet-i XOR masking-key-octet-j
original-octet-i：為原始數據的第 i 位元組。

transformed-octet-i：為轉換後的數據的第 i 位元組。

j：為i mod 4的結果。

masking-key-octet-j：為 mask key 第 j 位元組。

演算法描述為： original-octet-i 與 masking-key-octet-j 異或後，得到 transformed-octet-i。

j  = i MOD 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j

數據分片

分片的目的：

有了消息分片，發送一個消息的時候，就可以發送未知大小的資訊。如果消息不能被分片，那麼就不得不緩衝整個消息，以便計算長度。而有了分片就可以選擇合適大小緩衝區來緩衝分片。
第二個目的是可以使用多路復用。

WebSocket 的每條消息（message）可能被切分為多個數據幀。

當 WebSocket 的接收方接收到一個數據幀時，會根據 FIN 值來判斷是否收到消息的最後一個數據幀。

從上圖可以看出，FIN = 1 時，表示為消息的最後一個數據幀；FIN = 0 時，則不是消息的最後一個數據幀，接收方還要繼續監聽接收剩餘數據幀。

opcode 表示數據傳輸的類型，0x01 表示文本類型的數據；0x02 表示二進位類型的數據；0x00 比較特殊，表示延續幀（continuation frame），意思就是完整數據對應的數據幀還沒有接收完。

更多分片內容請看這裡：//www.rfc-editor.org/rfc/rfc6455.html#section-5.4

消息分片example：

Client: FIN=1, opcode=0x1, msg="hello"
Server: (process complete message immediately) Hi.
Client: FIN=0, opcode=0x1, msg="and a"
Server: (listening, new message containing text started)
Client: FIN=0, opcode=0x0, msg="happy new"
Server: (listening, payload concatenated to previous message)
Client: FIN=1, opcode=0x0, msg="year!"
Server: (process complete message) Happy new year to you too!

(具體例子見：//developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers)

五：怎麼保持連接

在第二小結中我們介紹了 websocket 的特點，其中有一個是保持連接狀態。

websocket 是建立在 tcp 之上，那也就是客戶端與服務端的 tcp 通道要保持連接不斷開。

怎麼保持呢？可以用心跳來實現。

其實 websocket 協議早就想到了，它的幀數據格式中有一個欄位 opcode，定義了 2 種類型操作， ping 和 pong，opcode 分別是 0x9、0xA。

說明：對於長時間沒有數據往來的連接，如果依舊長時間保持連接的狀態，那麼就會浪費連接資源。

[完]

六、參考

//www.rfc-editor.org/rfc/rfc6455.html WebScoket RFC6455
//www.rfc-editor.org/rfc/rfc5234 ABNF 格式
//www.ruanyifeng.com/blog/2017/05/websocket.html websocket 教程，阮一峰
//developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers

Tags: [05-1]協議-tcp/ip-rpc Websocket 協議