WebSocket協定介紹

文章目錄

• 前言
• 一、WebSocket是什麼？
• 二、WebSocket出現之前的實時技術
• 三、WebSocket應用場景
• 四、WebSocket協定棧
• 五、WebSocket與HTTP的差別
• 六、WebSocket握手過程
• 七、WebSocket幀格式
• 八、WebSocket分片傳輸
• 九、WebSocket相關擴充

前言

WebSocket是一種在單個TCP連接配接上進行全雙工通信的協定。WebSocket通信協定于2011年被IETF定為标準RFC 6455，并由RFC7936補充規範。WebSocket API也被W3C定為标準。

一、WebSocket是什麼？

• WebSocket 協定在2008年誕生，2011年成為國際标準。主流浏覽器都已經支援。
• WebSocket 是一種全新的協定。它将 TCP 的 Socket（套接字）應用在了網頁上，進而使通信雙方建立起一個保持在活動狀态連接配接通道，并且屬于全雙工通信。
• WebSocket 協定借用 HTTP協定 的 101 switch protocol 來達到協定轉換，從HTTP協定切換WebSocket通信協定。它的最大特點就是，伺服器可以主動向用戶端推送資訊，用戶端也可以主動向伺服器發送資訊，是真正的雙向平等對話。

二、WebSocket出現之前的實時技術

• 輪詢：最早的一種實作實時 Web 應用的方案。用戶端以一定的時間間隔向服務端送出請求，以頻繁請求的方式來保持用戶端和伺服器端的通信。
• 長輪詢：長輪詢也采用輪詢的方式，不過采取的是阻塞模型，用戶端發起連接配接後，如果沒消息，就一直不傳回Response給用戶端。直到有消息才傳回，傳回完之後，用戶端再次建立連接配接，周而複始。
• 其他方式：如xhr-streaming、隐藏iframe、ActiveX控件、SSE。

下圖是長輪詢的一個示意圖:

輪詢技術非真正實時技術。使用 Ajax 方式模拟實時效果，每次用戶端和伺服器端互動，都是一次 HTTP 的請求和應答過程，且每次的 HTTP 請求和應答都帶有完整 HTTP 頭資訊，增加傳輸的資料量。需建構兩個http連接配接。用戶端和伺服器端程式設計實作比較複雜，為模拟真實的實時效果，需構造兩個 HTTP 連接配接來模拟用戶端和伺服器的雙向通信，一個連接配接用來處理用戶端到伺服器端的資料傳輸，一個連接配接用來處理伺服器端到用戶端的資料傳輸，增加了程式設計實作的複雜度、伺服器端的負載，制約了應用系統的擴充性。

三、WebSocket應用場景

BS架構下的即時通訊、遊戲等應用需要用戶端與服務端間的雙向通信，而HTTP的請求/響應模型并不适合這種場景。會存在一定的問題：

• 伺服器端被迫提供兩類接口，一類提供給用戶端輪詢新消息，一類提供給用戶端推送消息給伺服器端。
• HTTP協定有較多的額外開銷，每次發送消息都會有一個HTTP header資訊，而且如果不用Keep-Alive每次還都要握手。
• 用戶端的腳本比如JS可能還需要跟蹤整個過程，發送一個消息後，我可能需要跟蹤這個消息的傳回。

Websocket出現使得浏覽器提供socket的支援成為可能，進而在浏覽器和伺服器之間建立一條基于tcp的雙向連接配接通道，web開發人員可以很友善的利用websocket建構實時web應用。

WebSocket适用于以下場景:

• 線上聊天場景：例如qq聊天、淘寶與客服聊天、線上客服等等。這種場景都是需要實時的接收伺服器推送的内容。
• 協同辦公：例如騰訊線上文檔，騰訊的線上文檔是支援多人編輯的，在excel中，一旦有人修改就要立即同步給所有人。
• 直播彈幕：例如虎牙、鬥魚等各大直播平台，在直播時都是有彈幕的，遇到一些精彩片段時，往往會有彈幕刷屏。在這種情況下使用WebSocket會有一個更好的使用者體驗。
• 位置共享：例如微信裡位置共享，這種場景需要使用者實時的共享自己的位置給伺服器，伺服器收到位置資訊後，要實時的推送給其它共享者的，實時性要求較高；百度地圖導航系統，在自己位置到達某個地方之後，語音會立即播報前面道路情況，比如上高架、下道地、拐彎、直行、學校慢行等等。這種場景實時性特别高，汽車速度很快，延遲1秒鐘，可能就錯過了最佳提醒時機。
• 其他通過定義WebSocket子協定的擴充支援：例如sip、mqtt、xmpp、stomp等。

四、WebSocket協定棧

WebSocket是基于TCP的應用層協定。需要特别注意的是：雖然WebSocket協定在建立連接配接時會使用HTTP協定，但這并意味着WebSocket協定是基于HTTP協定實作的。

五、WebSocket與HTTP的差別

• 通信方式不同。WebSocket是雙向通信模式，用戶端與伺服器之間隻有在握手階段是使用HTTP協定的“請求-響應”模式互動，而一旦連接配接建立之後的通信則使用雙向模式互動，不論是用戶端還是服務端都可以随時将資料發送給對方；而HTTP協定則至始至終都采用“請求-響應”模式進行通信。也正因為如此，HTTP協定的通信效率沒有WebSocket高。
• 協定格式不同。HTTP協定的一個資料包就是一條完整的消息；而WebSocket用戶端與服務端通信的最小機關是幀，由1個或多個幀組成一條完整的消息。即：發送端将消息切割成多個幀，并發送給服務端；服務端接收消息幀，并将關聯的幀重新組裝成完整的消息。

六、WebSocket握手過程

• 用戶端到服務端

  

  GET ws://localhost…… HTTP/1.1 ：打開階段握手，使用http1.1協定。

  Upgrade：websocket，表示請求為特殊http請求，請求的目的是要将用戶端和服務端的通信協定從http更新為websocket。

  Sec-websocket-key：Base64 encode 的值，是浏覽器随機生成的。用戶端向服務端提供的握手資訊。

• 服務端到用戶端

  

  101狀态碼：表示切換協定。伺服器根據用戶端的請求切換到Websocket協定。

  Sec-websocket-accept: 将請求頭中的Set-websocket-key添加字元串并做SHA-1加密後做Base64編碼，告知用戶端伺服器能夠發起websocket連接配接。

• 用戶端發起連接配接的約定

  如果請求為wss,則在TCP建立後，進行TLS連接配接建立。

  請求的方式必須為GET，HTTP版本至少為HTTP1.1。

  請求頭中必須有Host。

  請求頭中必須有Upgrade，取值必須為websocket。

  請求頭中必須有Connection，取值必須為Upgrade。

  請求頭中必須有Sec-WebSocket-Key，取值為16位元組随機數的Base64編碼。

  請求頭中必須有Sec-WebSocket-Version，取值為13。

  請求頭中可選Sec-WebSocket-Protocol，取值為用戶端期望的一個或多個子協定(多個以逗号分割)。

  請求頭中可選Sec-WebSocket-Extensitons，取值為子協定支援的擴充集(一般是壓縮方式)。

  可以包含cookie、Authorization等HTTP規範内合法的請求頭。

• 用戶端檢查服務端的響應

  服務端傳回狀态碼為101代表更新成功，否則判定連接配接失敗。

  響應頭中缺少Upgrade或取值不是websocket，判定連接配接失敗。

  響應頭中缺少Connection或取值不是Upgrade，判定連接配接失敗。

  響應頭中缺少Sec-WebSocket-Accept或取值非法（其值為請求頭中的Set-websocket-key添加字元串并做SHA-1加密後做Base64編碼），判定連接配接失敗。

  響應頭中有Sec-WebSocket-Extensions,但取值不是請求頭中的子集，判定連接配接失敗。

  響應頭中有Sec-WebSocket-Protocol,但取值不是請求頭中的子集，判定連接配接失敗。

• 服務端處理用戶端連接配接

  服務端根據請求中的Sec-WebSocket-Protocol 字段，選擇一個子協定傳回，如果不傳回，表示不同意請求的任何子協定。如果請求中未攜帶，也不傳回。

  如果建立連接配接成功，傳回狀态碼為101。

  響應頭Connection設定為Upgrade。

  響應頭Upgrade設定為websocket。

  Sec-WebSocket-Accpet根據請求頭Set-websocket-key計算得到，計算方式為：Set-websocket-key的值添加字元串： 258EAFA5-E914-47DA-95CA-C5AB0DC85B11并做SHA-1加密後得到16進制表示的字元串，将每兩位當作一個位元組進行分隔，得到位元組數組，對位元組數組做Base64編碼。

七、WebSocket幀格式

WebSocket通信流程如下:

Websocket幀格式如下:

• 第一部分

  

  FIN：1位，用于描述消息是否結束，如果為1則該消息為消息尾部，如果為零則還有後續資料包。

  RSV1,RSV2,RSV3：各1位，用于擴充定義，如果沒有擴充約定的情況則必須為0。

  OPCODE：4位，用于表示消息接收類型，如果接收到未知的opcode，接收端必須關閉連接配接。

  OPCODE說明:

  0x0表示附加資料幀，目前資料幀為分片的資料幀。

  0x1表示文本資料幀，采用UTF-8編碼。

  0x2表示二進制資料幀。

  0x3-7暫時無定義，為以後的非控制幀保留。

  0x8表示連接配接關閉。

  0x9表示ping。

  0xA表示pong。

  0xB-F暫時無定義，為以後的控制幀保留。

• 第二部分

  

  MASK：1位，用于辨別PayloadData是否經過掩碼處理。服務端發送給用戶端的資料幀不能使用掩碼，用戶端發送給服務端的資料幀必須使用掩碼。如果一個幀的資料使用了掩碼，那麼在Maksing-key部分必須是一個32個bit位的掩碼，用來給服務端解碼資料。

  Payload len：資料的長度：預設位7個bit位。如果資料的長度小于125個位元組（注意：是位元組）則用預設的7個bit來标示資料的長度。如果資料的長度為126個位元組，則用後面相鄰的2個位元組來儲存一個16bit位的無符号整數作為資料的長度。如果資料的長度大于126個位元組，則用後面相鄰的8個位元組來儲存一個64bit位的無符号整數作為資料的長度。

  payload len本來是隻能用7bit來表達的，也就是最多一個frame的payload隻能有127個位元組，為了表示更大的長度，給出的解決方案是添加擴充payload len字段。當payload實際長度超過126（包括），但在2^16-1長度内，則将payload len置為126，payload的實際長度由長為16bit的extended payload length來表達。當payload實際長度超過216（包括），但在264-1長度内，則将payload置為127，payload的實際長度由長為64bit的extended payload length來表達。

• 第三部分

  

  資料掩碼：如果MASK設定位0，則該部分可以省略，如果MASK設定位1，則Masking-key是一個32位的掩碼。用來解碼用戶端發送給服務端的資料幀。
• 第四部分

  

  資料：該部分，也是最後一部分，是幀真正要發送的資料，可以是任意長度。

八、WebSocket分片傳輸

• 控制幀可能插在一個Message的多個分片之間，但一個Message的分片不能交替傳輸(除非有擴充特别定義)。
• 控制幀不可分片。
• 分片需要按照分送方送出順序傳遞給接收方，但由于IP路由特性，實際并不能保證順序到達。

控制幀包括:

Close：用于關閉連接配接，可以攜帶資料，表示關閉原因。

Ping：可以攜帶資料。

Pong：用于Keep-alive，傳回最近一次Ping中的資料，可以隻發送Pong幀，做單向心跳。

連接配接關閉時狀态碼說明:

九、WebSocket相關擴充

1. Stomp

   STOMP是基于幀的協定，它的前身是TTMP協定（一個簡單的基于文本的協定），專為消息中間件設計。是屬于消息隊列的一種協定, 和AMQP, JMS平級。它的簡單性恰巧可以用于定義websocket的消息體格式. STOMP協定很多MQ都已支援, 比如RabbitMq, ActiveMq。生産者（發送消息）、消息代理、消費者（訂閱然後收到消息）。

2. SockJs

SockJS是一個浏覽器JavaScript庫，它提供了一個類似于網絡的對象。SockJS提供了一個連貫的、跨浏覽器的Javascript API，它在浏覽器和web伺服器之間建立了一個低延遲、全雙工、跨域通信通道。

SockJS的一大好處在于提供了浏覽器相容性。優先使用原生WebSocket，如果在不支援websocket的浏覽器中，會自動降為輪詢的方式。 除此之外，spring也對socketJS提供了支援。

3. Socket.io

Socket.io實際上是WebSocket的父集，Socket.io封裝了WebSocket和輪詢等方法，會根據情況選擇方法來進行通訊。

Sockei.io最早由Node.js實作，Node.js提供了高效的服務端運作環境，但由于Browser對HTML5的支援不一，為了相容所有浏覽器，提供實時的使用者體驗，并為開發者提供用戶端與服務端一緻的程式設計體驗，于是Socket.io誕生了。Java模仿Node.js實作了Java版的Netty-socket.io庫。

Socket.io将WebSocket和Polling機制以及其它的實時通信方式封裝成通用的接口，并在服務端實作了這些實時機制相應代碼，包括：AJAX Long Polling、Adobe Flash Socket、AJAX multipart streaming、Forever Iframem、JSONP Polling。