簡介
我們知道WebSocket是建立在TCP協定基礎上的一種網絡協定，用來進行用戶端和伺服器端的實時通信。非常的好用。最簡單的使用WebSocket的辦法就是直接使用浏覽器的API和伺服器端進行通信。
本文将會深入分析WebSocket的消息互動格式，讓大家得以明白，websocket到底是怎麼工作的。
WebSocket的握手流程
我們知道WebSocket為了相容HTTP協定，是在HTTP協定的基礎之上進行更新得到的。在用戶端和伺服器端建立HTTP連接配接之後，用戶端會向伺服器端發送一個更新到webSocket的協定，如下所示：
GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13 注意，這裡的HTTP版本必須是1.1以上。HTTP的請求方法必須是GET
通過設定Upgrade和Connection這兩個header，表示我們準備更新到webSocket了。
除了這裡列的屬性之外，其他的HTTP自帶的header屬性都是可以接受的。
這裡還有兩個比較特别的header，他們是Sec-WebSocket-Version和Sec-WebSocket-Key。
先看一下Sec-WebSocket-Version， 它表示的是用戶端請求的WebSocket的版本号。如果伺服器端并不明白用戶端發送的請求，則會傳回一個400 (“Bad Request”)，在這個傳回中，伺服器端會傳回失敗的資訊。
如果是不懂用戶端發送的Sec-WebSocket-Version，伺服器端同樣會将Sec-WebSocket-Version傳回，以告知用戶端。
這裡要特别關注的一個header字段就是Sec-WebSocket-Key。我們接下來看一下這個字段到底有什麼用。
當伺服器端收到用戶端的請求之後，會傳回給用戶端一個響應，告訴用戶端協定已經從HTTP更新到WebSocket了。
傳回的響應可能是這樣的：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 這裡的Sec-WebSocket-Accept是根據用戶端請求中的Sec-WebSocket-Key來生成的。具體而言是将用戶端發送的Sec-WebSocket-Key 和 字元串”258EAFA5-E914-47DA-95CA-C5AB0DC85B11″ 進行連接配接。然後使用SHA1算法求得其hash值。
最後将hash值進行base64編碼即可。
當伺服器端傳回Sec-WebSocket-Accept之後，用戶端可以對其進行校驗，已完成整個握手過程。
webSocket的消息格式
之是以要使用webSocket是因為client和server可以随時随地發送消息。這是websocket的神奇所在。那麼發送的消息是什麼格式的呢？我們來詳細看一下。
client和server端進行溝通的消息是以一個個的frame的形式來傳輸的。frame的格式如下：
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 ... |
+---------------------------------------------------------------+ MASK表示的是消息是否是被編碼過的，對于從client過來的消息來說，MASK必須是1。如果client發送給server端的消息，MASK不為1，則server需要斷開和client的連接配接。但是server端發送給client端的消息，MASK字段就不需要設定了。
RSV1-3是擴充的字段，可以忽略。
opcode表示怎麼去解釋payload字段。payload就是實際要傳遞的消息。0x0表示繼續，0x1表示文本，0x2表示二進制，其他的表示控制字段。
FIN表示是否是消息的最後一個frame。如果是0，表示該消息還有更多的frame。如果是1表示，該frame是消息的最後一部分了，可以對消息進行處理了。
為什麼需要Payload len字段呢？因為我們需要知道什麼時候停止接收消息。是以需要一個表示payload的字段來對消息進行具體的處理。
怎麼解析Payload呢？這個就比較複雜。
- 首先讀取9-15 bits，将其解析為無符号整數。如果其小于125，那麼這個就是payload的長度，結束。如果是126，那麼就去到第二步。如果是127，那麼就去到第三步。
- 讀取下一個16 bits，然後将其解析為無符号整數，結束。
- 讀取下一個64 bits。将其解析為符号整數。結束。
如果設定了Mask，那麼讀取下4個位元組，也就是32bits。這個是masking key。當資料讀取完畢之後，我們就擷取到了編碼過後的payload:ENCODED,和MASK key。要解碼的話，其邏輯如下：
var DECODED = "";
for (var i = 0; i < ENCODED.length; i++) {
DECODED[i] = ENCODED[i] ^ MASK[i % 4]; FIN可以和opcode一起配合使用，用來發送長消息。
FIN=1表示，是最後一個消息。 0x1表示是text消息，0x2是0，表示是二淨值消息，0x0表示消息還沒有結束，是以0x0通常和FIN=0 一起使用。
Extensions和Subprotocols
在用戶端和伺服器端進行握手的過程中，在标準的websocket協定基礎之上，用戶端還可以發送Extensions或者Subprotocols。這兩個有什麼差別呢？
首先這兩個都是通過HTTP頭來設定的。但是兩者還是有很大的不同。Extensions可以對WebSocket進行控制，并且修改payload，而subprotocols隻是定義了payload的結構，并不會對其進行修改。
Extensions是可選的，而Subprotocols是必須的。
你可以将Extensions看做是資料壓縮，它是在webSocket的基礎之上，對資料進行壓縮或者優化操作，可以讓發送的消息更短。
而Subprotocols 表示的是消息的格式，比如使用soap或者wamp。
子協定是在WebSocket協定基礎上發展出來的協定，主要用于具體的場景的處理，它是是在WebSocket協定之上，建立的更加嚴格的規範。
比如，用戶端請求伺服器時候，會将對應的協定放在Sec-WebSocket-Protocol頭中：
GET /socket HTTP/1.1
...
Sec-WebSocket-Protocol: soap, wamp 伺服器端會根據支援的類型，做對應的傳回，如：
Sec-WebSocket-Protocol: soap 總結
本文講解了webSocket消息互動的具體格式，可以看到很多強大功能的協定，都是由最最基本的結構組成的。
本文已收錄于 http://www.flydean.com/07-websocket-message/最通俗的解讀，最深刻的幹貨，最簡潔的教程，衆多你不知道的小技巧等你來發現！
歡迎關注我的公衆号:「程式那些事」,懂技術，更懂你！
![查找算法之二分查找查找算法之二分查找[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)