五分鐘技術趣談 | 淺談WebSocket協定-RFC 6455
2024.12.19
01 介紹
WebSocket是一種在TCP連接上進行全雙工通訊的網路通信協定。 在2009年誕生，於2011年被IETF（The Internet Engineering Task Force，國際互聯網工程任務組）定為標準併發佈RFC 6455互聯網標準跟蹤文檔，2016發佈了RFC7936文檔進行補充。 WebSocket API同時也被W3C定為標準。
WebSocket協議設計之初是為了取代HTTP形式的通信，因為RFC6202中提到HTTP協定最初不是用來做雙向數據通信的。 WebSocket協議並沒有完全捨棄HTTP，它基於HTTP基礎服務在現有環境中實現了雙向通信目標。 正如RFC 6455中說的那樣，WebSocke的設計哲學是最小約束的框架，唯一的約束就是協定是基於幀而不是流，並且支援Unicode文本和二進位幀兩者。
02 握手
WebSocket協定分為建連握手、消息傳輸和斷連握手三個部分，整體流程如下圖所示。
2.1 建連握手-用戶端
為了相容HTTP伺服器側的應用程式和代理，用戶端的建連握手（包括通過代理或通過TLS加密隧道進行的連接）是一個遵循RFC2616中定義的有效HTTP升級請求，用戶端連接握手請求header部分欄位如下圖所示。 此外，用戶端一旦發送了的連接握手就必須等待來自伺服器的回應。
- 請求URI
格式，ws-URI = “ws：” “/” host [ “：” port ] path [ “？” query ]或者wss-URI = “wss：” “/” host [ “：” port ] path [ “？” query ]，任何無效值都會造成建連失敗
- 請求行
必須是GET方法，HTTP版本至少是1.1
- Upgrade
值必須是“websocket”，ASCII值，不區分大小寫
- Connection
值必須包含“Upgrade”，ASCII值，不區分大小寫
- Sec-WebSocket-Key
用戶端為本次建連隨機生成的16位元節base64編碼的字元串
- Origin
源位址，瀏覽器用戶端必填，非瀏覽器用戶端選填
- Sec-WebSocket-Protocol
用戶端支援的一個或多個以逗號分隔的子協定，按優先順序排序
- Sec-WebSocket-Version
用戶端擬使用協定版本號，值必須為13。 歷史版本9、10、11和12不再作為有效值
- Sec-WebSocket-Extensions
用戶端擬使用協議擴展。 目前HyBi Working Group進行了多路複用擴展和壓縮擴展，多路復用擴展實現共用底層TCP連接。 壓縮擴展為WebSocket協定增加了壓縮功能，例如 x-webkit-deflate-frame
2.2 建連握手-服務端
當用戶端與服務端建立WebSocket連接時，服務端必須回復用戶端建連握手請求，握手回復header部分字段如下圖所示。
- 狀態行
HTTP/1.1 101 Switching Protocols，表示接受用戶端建連。 若伺服器想要停止處理用戶端的握手，可返回例如401這樣的錯誤代碼的HTTP回應
- Upgrade
值必須是“websocket”
- Connection
值必須包含“Upgrade”
- Sec-WebSocket-Accept
若服務端接受用戶端連接，生成該值。 先將用戶端請求頭的 Sec-WebSocket-Key值與RFC4122文檔中定義的全域唯一標識“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”拼接，然後進行SHA-1哈希再進行base64-encoded得到該值
- Sec-WebSocket-Protocol
服務端擬使用的協定，該值從客戶端發送的Sec-WebSocket-Protocol中選擇，若服務端都不支援，值為空
- Sec-WebSocket-Extensions
服務端擬使用協議擴展
2.3 斷接握手
用戶端和服務端都可以發送包含指定控制序列的控制幀（Close控制幀）以開始關閉握手。 一方在接收到關閉控制幀時，只需發送一個關閉幀作為回應，然後關閉連接。 存在攔截代理等情況下，TCP關閉握手並不總是可靠的端到端握手，上述關閉握手過程旨在補充TCP關閉握手（FIN/ACK）。
03 數據傳輸
用戶端一旦和服務端連接握手成功，雙方就可以開始數據傳輸了。 這是一個雙向通信通道，在遵循RFC 6455規範中“消息”概念的基礎上，雙方均可以獨立地隨意發送數據。 一條消息包含一個或者多個數據幀（不一定對應於網路層中的消息），Websocket幀格式如下圖所示。
3.1 幀結構
- FIN
1位，表示是否是一條消息的最後一個分片。
- RSV1, RSV2, RSV3
1位，擴展功能未使用的情況下預設值為0。
- Opcode
4位，定義「Playload data」數據類型。
- 0（十進位）：連續幀
- 1：文本幀
- 2：二進位幀
- 3-7：預留非控制幀
- 8：連接關閉幀
- 9：心跳ping幀
- 10：心跳pong幀
- 11-15：預留控制幀
- MASK
1位，是否遮罩“Playload data”，1是，0否。
- Payload length
7位，或者7+16位，或者7+64位，表示Payload data的長度。 具體地，Payload length小於125，數據長度用Payload length表示; Payload length等於126，數據長度用Payload length後面16位表示; Payload length等於127，數據長度用Payload length後面64位表示。
- Masking-key
32位，存放用戶端發送的掩碼。 為了防止代理緩存污染攻擊，RFC6455中要求掩碼必須來自強大的熵源，不可被預測。 常規演算法以位元組為步長遍歷載荷數據， 對於載荷數據的第i個字節， 做i對4取模得到j，掩碼覆蓋后的載荷數據的第i個字節的值為原第i個字節與Masking-Key的第j個字節做按位異或操作。
- Payload data
載荷數據分為擴展數據和應用數據兩種，擴展數據在握手階段協商是否使用，應用數據在擴展數據之後。
3.2 控制幀
控制幀由Opcode值確定，協定當前定義的控制幀的操作碼包括 0x8 （Close）、0x9（Ping）、和0xA（Pong）。 控制幀必須有一個小於等於125位元組的有效載荷長度，對於Close控制幀有效載荷的前2個字節表示狀態碼，剩餘位元組表示關閉原因，如下圖所示。
3.3 消息分片
消息分片指將概念上的一條「消息」通過多個數據幀發送。 消息分片允許發送未知大小的消息，而不必緩衝整條消息。 同時，消息分片結合多路複用協定的擴展，可以分割消息為更小的分段以共享輸出通道。
協定中分片消息開始幀的FIN位為0，opcode位為非0表示該幀為某消息分片，中間幀FIN位為0，opcode位為0，最後通過FIN位為1，opcode為0標識分片結束。 協定要求分片數據幀按順序發送到另一端。
04 總結
WebSocke是設計在TCP層之上，不需要考慮數據長度，數據粘包拆包。 也能通過擴展功能與HTTP/2多路複用結合，充分利用頻寬。 開發者只需在服務端和用戶端代碼中按序處理消息分片邏輯。