你不知道的Websocket協議，這次給你講明白！
前言
初次接觸 websocket 的人，可能都會有這樣的疑問：我們已經有了 http 協議，為什么還需要websocket協議？它帶來了什么好處？
原因是http每次請求只能由客戶發起，而websocket最大特點就是，服務器可以主動向客戶端推送信息，客戶端也可以主動向服務器發送信息
剛好目前項目中用到了websocket，當然關于websocket的知識無論是前端還是后臺開發的同學都得掌握，不會也沒關系，關注小許，這次給你講明白！
使用場景再現
在線教育：
老師進行一對多的在線授課，在客戶端內編寫的筆記、大綱等信息，需要實時推送至多個學生的客戶端，需要通過WebSocket協議來完成。
圖片
視頻彈幕：
終端用戶A在自己的手機端發送了一條彈幕信息，但是您也需要在客戶A的手機端上將其他N個客戶端發送的彈幕信息一并展示。需要通過WebSocket協議將其他客戶端發送的彈幕信息從服務端全部推送至客戶A的手機端，從而使客戶A可以同時看到自己發送的彈幕和其他用戶發送的彈幕。
當然還有體育實況更新、視頻會議和聊天等等，這里都不一一列舉了
Web端即時通信方式
什么是web端即時通訊技術？
可以理解為實現這樣一種功能：服務器端可以即時地將數據的更新或變化反應到客戶端，例如消息推送等功能都是通過這種技術實現的。
但是在Web中，由于瀏覽器的限制，實現即時通訊需要借助一些方法。這種限制出現的主要原因是，一般的Web通信都是瀏覽器先發送請求到服務器，服務器再進行響應完成數據的現實更新。
Web端實現即時通訊主要有四種方式：輪詢、長輪詢(comet)、長連接(SSE)、WebSocket。
它們大體可以分為兩類，一種是在HTTP基礎上實現的，包括短輪詢、長輪詢(comet)、長連接(SSE)；另一種不是在HTTP基礎上實現是，即WebSocket。下面分別介紹一下這四種輪詢方式。
圖片
輪詢
基本思路就是客戶端每隔一段時間向服務器發送http請求，服務器端在收到請求后，不管是否有所需數據返回，都直接進行響應。
圖片
這種方式本質上還是客戶端不斷發送請求，才形成客戶端能實時接收服務端數數據變化的假象。
實現比較簡單，缺點是需要不斷建立http連接，浪費資源，而且在客戶端數量級很大的情況下會導致服務器壓力陡增，顯然不是好選擇！
輪詢方式，你會發現在你打開F12調試頁面時，你會發現大量的HTTP請求呢 ??????...
長輪詢
輪詢方式是在服務器接收到請求后迅速做出響應。
而長輪詢方式是服務器收到客戶端發來的請求后，想掛起請求，服務器端不會直接進行響應，在超時時間內（比如20S）,接收請求和處理請求進行響應。
圖片
有兩種情況長輪詢會響應：
? 達到http請求超時時間
? 服務器正常處理請求返回響應結果
長輪詢和短輪詢比起來，明顯減少了很多不必要的http請求次數，但是連接掛起也會導致資源的浪費！
長連接 SSE
官方介紹：長連接是指在一個連接上可以連續發送多個數據包，在連接保持期間，如果沒有數據包發送，需要雙方發鏈路檢測包。
SSE是HTML5新增的功能，全稱為Server-Sent Events，它可以允許服務器推送數據到客戶端。
SSE在本質上就與之前的長輪詢、輪詢不同，雖然都是基于http協議的，但是輪詢需要客戶端先發送請求，服務端才能響應。而SSE最大的特點就是不需要持續客戶端發送請求，可以實現只要服務器端數據有更新，就可以馬上發送到客戶端。
圖片
長鏈接流程：連接->傳輸數據->保持連接 -> 傳輸數據-> ....->直到一方關閉連接，客戶端關閉連接
SSE的優勢在于，它不需要建立或保持大量的客戶端發往服務器端的請求，節約了很多資源，提升應用性能，但是可以關閉一些長時間不讀寫操作的連接，這樣可以避免一些惡意連接導致server端壓力。
websocket
WebSocket協議是基于TCP的一種新的網絡協議，它實現了客戶端與服務器全雙工（full-duplex）通信（同一時間里，雙方都可以主動向對方發送數據）。
在WebSocket中，客戶端和服務器只需要完成一次握手，兩者之間就直接可以創建持久性的連接，并進行雙向數據傳輸。
圖片
通信方式總結
??兼容性角度：短輪詢>長輪詢>長連接SSE>WebSocket
??性能方面：WebSocket>長連接SSE>長輪詢>短輪詢
Websocket
我們已經知道了WebSocket 是一種網絡傳輸協議，可在單個 TCP 連接上進行全雙工通信，位于 OSI 模型的應用層。
而通過WebSocket使得客戶端和服務器之間的數據交換變得更加簡單，允許服務端主動向客戶端推送數據，只需要完成一次握手，兩者之間就直接可以創建持久性的連接。
ok，一起來看看websocket知識！
協議升級
出于兼容性的考慮，websocket 的握手使用 HTTP 來實現，客戶端的握手消息就是一個「普通的，帶有 Upgrade 頭的，HTTP Request 消息」。
圖片
?? 想建立websoket連接，就需要在http請求上帶一些特殊的header頭才行！
我們看下WebSocket協議客戶端請求和服務端響應示例，關于http這里就不多介紹了（這里自行回想下Http請求的request和reposone部分）
header頭的意思是，瀏覽器想升級http協議，并且想升級成websocket協議。
客戶端請求：
以下是WebSocket請求頭中的一些字段：
Upgrade: websocket // 1
Connection: Upgrade // 2
Sec-WebSocket-Key: xx== // 3
Origin: http: // 4
Sec-WebSocket-Protocol: chat, superchat // 5
Sec-WebSocket-Version: 13 // 6上述字段說明如下：
- 1. Upgrade：字段必須設置 websocket，表示希望升級到 WebSocket 協議
- 2. Connection：須設置 Upgrade，表示客戶端希望連接升級
- 3. Sec-WebSocket-Key：是隨機的字符串，服務器端會用這些數據來構造出一個 SHA-1 的信息摘要
- 4. Origin：字段是可選的，只包含了協議和主機名稱
- 5. Sec-WebSocket-Extensions：用于協商本次連接要使用的 WebSocket 擴展
- 6. Sec-WebSocket-Version：表示支持的 WebSocket 版本，RFC6455 要求使用的版本是 13
服務端響應：
HTTP/1.1 101 Web Socket Protocol Handshake // 1
Connection: Upgrade // 2
Upgrade: websocket // 3
Sec-WebSocket-Accept: 2mQFj9iUA/Nz8E6OA4c2/MboVUk= //4上述字段說明如下：
- 1. 101 響應碼確認升級到 WebSocket 協議
- 2. Connection：值為 “Upgrade” 來指示這是一個升級請求
- 3. Upgrade：表示升級為 WebSocket 協議
- 4. Sec-WebSocket-Accept：簽名的鍵值驗證協議支持
?? 1：ws 協議默認使用 80 端口，wss 協議默認使用 443 端口，和 http 一樣
?? 2：WebSocket 沒有使用 TCP 的“IP 地址 + 端口號”，開頭的協議名不是“http”，引入的是兩個新的名字：“ws”和“wss”，分別表示明文和加密的 WebSocket 協議
連接確認
發建立連接是前提，但是只有當請求頭參數Sec-WebSocket-Key字段的值經過固定算法加密后的數據和響應頭里的Sec-WebSocket-Accept的值保持一致，該連接才會被認可建立。
如下圖從瀏覽器截圖的兩個關鍵參數：
圖片
服務端返回的響應頭字段 Sec-WebSocket-Accept 是根據客戶端請求 Header 中的Sec-WebSocket-Key計算出來。
那么時如何進行參數加密驗證和比對確認的呢，如下圖！
圖片
具體流程如下：
- ? 客戶端握手中的 Sec-WebSocket-Key 頭字段的值是16字節隨機數，并經過base64編碼
- ? 服務端需將該值和固定的 GUID 字符串（ 258EAFA5-E914-47DA-95CA-C5AB0DC85B11）拼接后使用 SHA-1 進行哈希，并采用 base64 編碼后
- ? 服務端將編碼后的值作為響應作為的Sec-WebSocket-Accept 值返回。
- ? 客戶端也必須按照服務端生成 Sec-WebSocket-Accept 的方式一樣生成字符串，與服務端回傳的進行對比
- ? 相同就是協議升級成功，不同就是失敗
在協議升級完成后websokcet就建立完成了，接下來就是客戶端和服務端使用websocket進行數據傳輸通信了!
數據幀
一旦升級成功 WebSocket 連接建立后，后續數據都以幀序列的形式傳輸。
?? 協議規定了數據幀的格式，服務端要想給客戶端推送數據，必須將要推送的數據組裝成一個數據幀，這樣客戶端才能接收到正確的數據；同樣，服務端接收到客戶端發送的數據時，必須按照幀的格式來解包，才能真確獲取客戶端發來的數據
我們來看下對幀的格式定義吧！
圖片
看看數據幀字段代表的含義吧：
1. FIN 1個bit位，用來標記當前數據幀是不是最后一個數據幀
2. RSV1, RSV2, RSV3 這三個，各占用一個bit位用做擴展用途，沒有這個需求的話設置位0
3. Opcode 的值定義的是數據幀的數據類型
值為1 表示當前數據幀內容是文本
值為2 表示當前數據幀內容是二進制
值為8表示請求關閉連接
1. MASK 表示數據有沒有使用掩碼
服務端發送給客戶端的數據幀不能使用掩碼，客戶端發送給服務端的數據幀必須使用掩碼。
1. Payload len 數據的長度，Payload data的長度，占7bits，7+16bits，7+64bits
2. Masking-key 數據掩碼 (設置位0，則該部分可以省略，如果設置位1，則用來解碼客戶端發送給服務端的數據幀)
3. Payload data 幀真正要發送的數據，可以是任意長度
上面我們說到Payload len三種長度（最開始的7bit的值）來標記數據長度，這里具體看下是哪三種：
?? 情況1：值設置在0-125
那么這個有效載荷長度（Payload len）就是對應的數據的值。
圖片
?? 情況2：值設置為126
如果設置為 126，可表示payload的長度范圍在 126~65535 之間，那么接下來的 2 個字節（擴展用16bit Payload長度）會包含Payload真實數據長度。
圖片
?? 情況3：值設置為127
可表示payload的長度范圍在 >=65535 ，那么接下來的 8 個字節（擴展用16bit + 32bit + 16bit Payload長度）會包含Payload真實數據長度，這種情況能表示的數據就很大了，完全夠用。
圖片
socket和websocket
這兩者名字上差距不大，雖然都有帶個socket，但是完全是兩個不同的東西， 大家千萬別被名字給帶的傻傻分不清楚了！
我們來看下之間的區別：
socket：是在應用層和傳輸層之間的一個中間軟件抽象層，是一組接口，它把TCP/IP層復雜的操作抽象為幾個簡單的接口供應用層調用以實現進程在網絡中通信。
websocket：是基于TCP的一種新的網絡協議，和http協議一樣屬于應用層協議。
下圖中分別表示了socket和websocket在網絡中的位置：
圖片
常見狀態碼
下面顯示了從服務器到客戶端的通信的 WebSocket 狀態碼和錯誤提示，WebSocket 狀態碼遵循 RFC 正常關閉連接標準
? 1000 CLOSE_NORMAL 連接正常關閉
? 1001 CLOSE_GOING_AWAY 終端離開 例如：服務器錯誤，或者瀏覽器已經離開此頁面
? 1002 CLOSE_PROTOCOL_ERROR 因為協議錯誤而中斷連接
? 1003 CLOSE_UNSUPPORTED 端點因為受到不能接受的數據類型而中斷連接
? 1004 保留
? 1005 CLOSE_NO_STATUS 保留, 用于提示應用未收到連接關閉的狀態碼
? 1006 CLOSE_ABNORMAL 期望收到狀態碼時連接非正常關閉 (也就是說, 沒有發送關閉幀)
? 1007 Unsupported Data 收到的數據幀類型不一致而導致連接關閉
? 1008 Policy Violation 收到不符合約定的數據而斷開連接
? 1009 CLOSE_TOO_LARGE 收到的消息數據太大而關閉連接
? 1010 Missing Extension 客戶端因為服務器未協商擴展而關閉
? 1011 Internal Error 服務器因為遭遇異常而關閉連接
? 1012 Service Restart 服務器由于重啟而斷開連接
? 1013 Try Again Later 服務器由于臨時原因斷開連接, 如服務器過載因此斷開一部分客戶端連接
? 1015 TLS握手失敗關閉連接
總結
WebSocket 是一種網絡傳輸協議，可在單個 TCP 連接上進行全雙工通信。
適用于需要客戶端（瀏覽器）和服務端頻繁交互的大部分場景，比如網頁游戲，體育實況，彈幕，以及一些協同辦公軟件等
圖片
而websocket是利用http協議，然后加上一些特殊的header頭進行握手Upgrade升級操作，升級成功后就跟http沒有任何關系了，之后就用websocket的數據格式進行收發數據。
