前言

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實際長度超過2^{16（包括），但在2}64-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，