小菜學網(wǎng)絡(luò)之WebSocket協(xié)議
Web應(yīng)用 采用 HTTP 協(xié)議進行通信：客戶端向服務(wù)器發(fā)送 HTTP 請求，服務(wù)器對請求進行處理后，向客戶端回復 HTTP 響應(yīng)。換句話講，HTTP 協(xié)議只能客戶端主動發(fā)起請求，服務(wù)器被動進行響應(yīng)。
圖片
不少應(yīng)用場景要求服務(wù)主動向客戶端進行推送，這時 HTTP 協(xié)議就有點捉襟見肘了。舉個例子，為實現(xiàn) Web 聊天室功能，當新消息到達時，服務(wù)器必須向客戶端推送通知。只用 HTTP 協(xié)議來實現(xiàn)，我們必須在客戶端做輪詢。
輪詢有個致命的缺陷——性能比較差：如果輪詢頻率很高，服務(wù)器要消耗很多資源；但如果控制輪詢頻率，應(yīng)用消息通知的實時性又大打折扣。
很顯然，服務(wù)器主動向客戶端推送數(shù)據(jù)，也是一個非常常見的應(yīng)用場景，最好能從網(wǎng)絡(luò)協(xié)議層面進行支持。為此，計算機網(wǎng)絡(luò)先驅(qū)們設(shè)計了 WebSocket 協(xié)議。
WebSocket 協(xié)議，顧名思義為 Web 應(yīng)用引入了 套接字（ socket ）通信能力。Websocket 是一種應(yīng)用層協(xié)議，以 TCP 為底層傳輸協(xié)議，為通信雙方提供了一個 全雙工 的信道。
為了兼容 Web 主流應(yīng)用協(xié)議 HTTP ，WeSocket 復用 80 和 443 端口，并使用 HTTP 請求來建立連接（配合 Upgrade 頭部）。因此，WebSocket 可以兼容現(xiàn)有的 HTTP代理 和中間件，例如 Nginx 。
URL
和 HTTP 協(xié)議一樣，WebSocket 服務(wù)器地址也用 URL 表示，只是協(xié)議部分為 ws 或 wss 。例如：
# ws代表WebSocket協(xié)議，端口為80
ws://api.fasionchan.com/chat
# wss代表WebSocket安全協(xié)議，與https類似，端口為443
wss://api.fasionchan.com/chat連接建立
客戶端先通過 TCP 協(xié)議連到服務(wù)器，然后通過 TCP 連接向服務(wù)器發(fā)送 HTTP 請求。請注意，HTTP 請求頭中要帶 Upgrade 頭部，告訴服務(wù)器將連接升級到 WebSocket 協(xié)議：
GET /chat HTTP/1.1
Host: localhost:8080
User-Agent: Go-http-client/1.1
Connection: Upgrade
Sec-WebSocket-Key: bLPIf/xpAnrtCKuifPKTUg==
Sec-WebSocket-Version: 13
Upgrade: websocket服務(wù)器接到請求后，檢查 Upgrade 頭部，發(fā)現(xiàn)客戶端想將連接協(xié)議升級到 WebSocket 。如果應(yīng)用服務(wù)器支持 WebSocket ，它便回復 101 狀態(tài)碼，表示同意切換協(xié)議：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: lShvB7NL9TbGxezz+KUd5ee6jhA=
圖片
HTTP 請求和響應(yīng)交互完畢后，通信雙方就可以在 TCP 連接上互相發(fā)送 WebSocket 報文了。
數(shù)據(jù)幀
連接建好后，通信雙方就可以用 WebSocket 協(xié)議來發(fā)送數(shù)據(jù)了。WebSocket 將數(shù)據(jù)組織成一系列幀（ frame ）來傳輸，一條應(yīng)用層消息可以封裝成一個或多個數(shù)據(jù)幀。數(shù)據(jù)幀報文結(jié)構(gòu)如下所示：
圖片
- 標志位 ，占 4每個標識占一位；
a.FIN
b.RSV1 、RSV2 和 RSV3
a.0 這是前面數(shù)據(jù)幀的續(xù)幀（一個消息封裝成多個幀時）；
b.1表示這是一個文本幀；
c.2 表示這是一個二進制（ binary ）幀；
d3~7 保留，未來可以分配給新的非控制（ non-control ）幀；
e.8 表示這是一個連接關(guān)閉（ close ）幀；
f.9 表示這是一個 ping 幀；
g.10 表示這是一個 pong 幀；
h.11~15 保留，未來可以分配給新的控制（ control ）幀；
- MASK 位，表示 承載數(shù)據(jù)（ payload data ）是否做掩碼處理，1 表示掩碼處理，0 表示不做掩碼處理（客戶端發(fā)的幀必須做掩碼處理，主要出于避免網(wǎng)絡(luò)中間件混淆和安全上的考慮）；
- 數(shù)據(jù)長度（ payload len ），占 7 位，用來表示數(shù)據(jù)負載的長度（以字節(jié)為單位）；
a.該字段小于 126 時，該字段直接表示數(shù)據(jù)長度，其后的擴展字段為空（ 0 字節(jié)），可表示 0~125 字節(jié)的數(shù)據(jù)；
b.當該字段等于 126 時，數(shù)據(jù)長度由其后的擴展字段表示，這是擴展字段為 2 字節(jié)，可表示長度為 126~65535 字節(jié)的數(shù)據(jù)；
c.
- 擴展數(shù)據(jù)長度（ extended payload len ），占用 0 、2 或 8 字節(jié)，由前一個字段決定；
- 掩碼Key（ masking key ），數(shù)據(jù)幀開啟掩碼處理時（ MASK=1 ）才有，占用 4 個字節(jié)，用于掩碼計算；
- 承載數(shù)據(jù)（ payload data ），即數(shù)據(jù)幀承載的應(yīng)用層數(shù)據(jù)；
數(shù)據(jù)長度字段比較復雜，需要分三種情況討論，分別舉個例子幫助理解：
圖片
注意到，為了簡化報文，我們假設(shè) MASK=0 ，未啟動掩碼處理。
WebSocket 幀結(jié)構(gòu)看似復雜，但無非還是先分成 頭部 和 數(shù)據(jù) 兩大部分，其中頭部保存 數(shù)據(jù)類型（操作碼）和 數(shù)據(jù)長度 ，而操作碼又分成控制和非控制兩種。
控制幀則繼續(xù)分為 close 、ping 和 pong 三種：close 用于關(guān)閉連接；ping 和 pong 用于檢測連接狀態(tài)，檢測方發(fā) ping ，被檢測方回復 pong 。這樣當應(yīng)用暫時沒有數(shù)據(jù)要發(fā)送時，ping/pong 可讓連接保持活躍。當連接斷開時，也能及時檢測到。
而非控制幀則分為 text 和 binary 兩種，上層應(yīng)用使用文本協(xié)議，則選 text ；使用二進制協(xié)議，則選 binary 。
總結(jié)
- WebSocket 兼容 HTTP 協(xié)議，借助 HTTP 請求建立連接；
- WebSocket 通信分為兩個階段：
- 連接建立階段：使用 HTTP
- 數(shù)據(jù)通信階段：使用 WebSocket
- WebSocket 通信報文為 幀 ，一個幀由 頭部 和 數(shù)據(jù) 兩部分組成；
- WebSocket 幀頭部保存 操作碼 和 數(shù)據(jù)長度 等字段；
- 根據(jù)操作碼不同，WebSocket 幀可以分成 控制幀 和 非控制幀 兩類；
- WebSocket 控制幀分為 close 、ping 和 pong 三種；
- ping / pong 控制幀用于連接?；詈蜖顟B(tài)檢測；
- close 控制幀用于關(guān)閉連接；
- WebSocket 非控制幀分為 文本幀 和 二進制幀 兩種；
