一文詳解WebSocket協(xié)議

Labs 導讀

在WebSocket出現之前，一個(gè)Web應用（即時(shí)聊天、多人協(xié)作）的客戶(hù)端和服務(wù)端之間常見(jiàn)的雙向數據交換方式有短輪詢(xún)、長(cháng)輪詢(xún)、SSE（Server-Sent Events，服務(wù)器發(fā)送事件）。這些方式在效率和網(wǎng)絡(luò )帶寬利用率方面存在諸多問(wèn)題。WebSocket協(xié)議應運而生，對外提供了簡(jiǎn)單的雙向數據傳輸能力。

作者：朱磊

單位：中國移動(dòng)智慧家庭運營(yíng)中心成都業(yè)務(wù)支持中心

Part 01 ●介紹●

WebSocket是一種在TCP連接上進(jìn)行全雙工通訊的網(wǎng)絡(luò )通信協(xié)議。在2009年誕生，于2011年被IETF（The Internet Engineering Task Force，國際互聯(lián)網(wǎng)工程任務(wù)組）定為標準并發(fā)布RFC 6455互聯(lián)網(wǎng)標準跟蹤文檔，2016發(fā)布了RFC7936文檔進(jìn)行補充。WebSocket API同時(shí)也被W3C定為標準。

WebSocket協(xié)議設計之初是為了取代HTTP形式的通信，因為RFC6202中提到HTTP協(xié)議最初不是用來(lái)做雙向數據通信的。WebSocket協(xié)議并沒(méi)有完全舍棄HTTP，它基于HTTP基礎服務(wù)在現有環(huán)境中實(shí)現了雙向通信目標。正如RFC 6455中說(shuō)的那樣，WebSocke的設計哲學(xué)是最小約束的框架，唯一的約束就是協(xié)議是基于幀而不是流，并且支持Unicode文本和二進(jìn)制幀兩者。

Part 02 ●握手●

WebSocket協(xié)議分為建連握手、消息傳輸和斷連握手三個(gè)部分，整體流程如下圖所示。

2.1 建連握手-客戶(hù)端

為了兼容HTTP服務(wù)器側的應用程序和代理，客戶(hù)端的建連握手（包括通過(guò)代理或通過(guò)TLS加密隧道進(jìn)行的連接）是一個(gè)遵循RFC2616中定義的有效HTTP升級請求，客戶(hù)端連接握手請求header部分字段如下圖所示。此外，客戶(hù)端一旦發(fā)送了的連接握手就必須等待來(lái)自服務(wù)器的響應。

- 請求URI

格式，ws-URI = "ws:" "http://" host [ ":" port ] path [ "?" query ]或者wss-URI = "wss:" "http://" host [ ":" port ] path [ "?" query ]，任何無(wú)效值都會(huì )造成建連失敗

- 請求行

必須是GET方法，HTTP版本至少是1.1

- Upgrade

值必須是“websocket”，ASCII值，不區分大小寫(xiě)

- Connection

值必須包含“Upgrade”，ASCII值，不區分大小寫(xiě)

- Sec-WebSocket-Key

客戶(hù)端為本次建連隨機生成的16字節base64編碼的字符串

- Origin

源地址，瀏覽器客戶(hù)端必填，非瀏覽器客戶(hù)端選填

- Sec-WebSocket-Protocol

客戶(hù)端支持的一個(gè)或多個(gè)以逗號分隔的子協(xié)議，按優(yōu)先級排序

- Sec-WebSocket-Version

客戶(hù)端擬使用協(xié)議版本號，值必須為13。歷史版本9、10、11和12不再作為有效值

- Sec-WebSocket-Extensions

客戶(hù)端擬使用協(xié)議擴展。目前HyBi Working Group進(jìn)行了多路復用擴展和壓縮擴展，多路復用擴展實(shí)現共享底層TCP連接。壓縮擴展為WebSocket協(xié)議增加了壓縮功能，例如 x-webkit-deflate-frame

2.2 建連握手-服務(wù)端

當客戶(hù)端與服務(wù)端建立WebSocket連接時(shí)，服務(wù)端必須回復客戶(hù)端建連握手請求，握手回復header部分字段如下圖所示。

- 狀態(tài)行

HTTP/1.1 101 Switching Protocols，表示接受客戶(hù)端建連。若服務(wù)器想要停止處理客戶(hù)端的握手，可返回例如401這樣的錯誤代碼的HTTP響應

- Upgrade

值必須是“websocket”

- Connection

值必須包含“Upgrade”

- Sec-WebSocket-Accept

若服務(wù)端接受客戶(hù)端連接，生成該值。先將客戶(hù)端請求頭的 Sec-WebSocket-Key值與RFC4122文檔中定義的全局唯一標識“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”拼接，然后進(jìn)行SHA-1哈希再進(jìn)行base64-encoded得到該值

- Sec-WebSocket-Protocol

服務(wù)端擬使用的協(xié)議，該值從客戶(hù)端發(fā)送的Sec-WebSocket-Protocol中選擇，若服務(wù)端都不支持，值為空

- Sec-WebSocket-Extensions

服務(wù)端擬使用協(xié)議擴展

2.3 斷接握手

客戶(hù)端和服務(wù)端都可以發(fā)送包含指定控制序列的控制幀（Close控制幀）以開(kāi)始關(guān)閉握手。一方在接收到關(guān)閉控制幀時(shí)，只需發(fā)送一個(gè)關(guān)閉幀作為響應，然后關(guān)閉連接。存在攔截代理等情況下，TCP關(guān)閉握手并不總是可靠的端到端握手，上述關(guān)閉握手過(guò)程旨在補充TCP關(guān)閉握手（FIN/ACK）。

Part 03 ● 數據傳輸●

客戶(hù)端一旦和服務(wù)端連接握手成功，雙方就可以開(kāi)始數據傳輸了。這是一個(gè)雙向通信信道，在遵循RFC 6455規范中“消息”概念的基礎上，雙方均可以獨立地隨意發(fā)送數據。一條消息包含一個(gè)或者多個(gè)數據幀（不一定對應于網(wǎng)絡(luò )層中的消息），Websocket幀格式如下圖所示。

3.1 幀結構

- FIN

1位，表示是否是一條消息的最后一個(gè)分片。

- RSV1, RSV2, RSV3

1位，擴展功能未使用的情況下默認值為0。

- Opcode

4位，定義“Playload data”數據類(lèi)型。

0（十進(jìn)制）：連續幀

1：文本幀

2：二進(jìn)制幀

3-7：預留非控制幀

8：連接關(guān)閉幀

9：心跳ping幀

10：心跳pong幀

11-15：預留控制幀

- MASK

1位，是否屏蔽“Playload data”，1是，0否。

- Payload length

7位，或者7+16位，或者7+64位，表示Payload data的長(cháng)度。具體地，Payload length小于125，數據長(cháng)度用Payload length表示;Payload length等于126，數據長(cháng)度用Payload length后面16位表示；Payload length等于127，數據長(cháng)度用Payload length后面64位表示。

- Masking-key

32位，存放客戶(hù)端發(fā)送的掩碼。為了防止代理緩存污染攻擊，RFC6455中要求掩碼必須來(lái)自強大的熵源，不可被預測。常規算法以字節為步長(cháng)遍歷載荷數據, 對于載荷數據的第i個(gè)字節, 做i對4取模得到j(luò )，掩碼覆蓋后的載荷數據的第i個(gè)字節的值為原第i個(gè)字節與Masking-Key的第j個(gè)字節做按位異或操作。

- Payload data

載荷數據分為擴展數據和應用數據兩種，擴展數據在握手階段協(xié)商是否使用，應用數據在擴展數據之后。

3.2 控制幀

控制幀由Opcode值確定，協(xié)議當前定義的控制幀的操作碼包括 0x8 （Close）、0x9（Ping）、和0xA（Pong）?？刂茙仨氂幸粋€(gè)小于等于125字節的有效載荷長(cháng)度，對于Close控制幀有效載荷的前2個(gè)字節表示狀態(tài)碼，剩余字節表示關(guān)閉原因，如下圖所示。

3.3 消息分片

消息分片指將概念上的一條“消息”通過(guò)多個(gè)數據幀發(fā)送。消息分片允許發(fā)送未知大小的消息，而不必緩沖整條消息。同時(shí)，消息分片結合多路復用協(xié)議的擴展，可以分割消息為更小的分段以共享輸出通道。

協(xié)議中分片消息開(kāi)始幀的FIN位為0，opcode位為非0表示該幀為某消息分片，中間幀FIN位為0，opcode位為0，最后通過(guò)FIN位為1，opcode為0標識分片結束。協(xié)議要求分片數據幀按順序發(fā)送到另一端。

Part 04 ●總結●

WebSocke是設計在TCP層之上，不需要考慮數據長(cháng)度，數據粘包拆包。也能通過(guò)擴展功能與HTTP/2多路復用結合，充分利用帶寬。開(kāi)發(fā)者只需在服務(wù)端和客戶(hù)端代碼中按序處理消息分片邏輯。

審核編輯：湯梓紅