前言

初次接觸 websocket 的人，可能都會有這樣的疑問：我們已經(jīng)有了 http 協(xié)議，為什么還需要websocket協(xié)議？它帶來了什么好處？

原因是http每次請求只能由客戶發(fā)起，而websocket最大特點就是，服務器可以主動向客戶端推送信息，客戶端也可以主動向服務器發(fā)送信息

剛好目前項目中用到了websocket，當然關(guān)于websocket的知識無論是前端還是后臺開發(fā)的同學都得掌握，不會也沒關(guān)系，關(guān)注小許，這次給你講明白！

使用場景再現(xiàn)

在線教育：

老師進行一對多的在線授課，在客戶端內(nèi)編寫的筆記、大綱等信息，需要實時推送至多個學生的客戶端，需要通過WebSocket協(xié)議來完成。

圖片

視頻彈幕：

終端用戶A在自己的手機端發(fā)送了一條彈幕信息，但是您也需要在客戶A的手機端上將其他N個客戶端發(fā)送的彈幕信息一并展示。需要通過WebSocket協(xié)議將其他客戶端發(fā)送的彈幕信息從服務端全部推送至客戶A的手機端，從而使客戶A可以同時看到自己發(fā)送的彈幕和其他用戶發(fā)送的彈幕。

當然還有體育實況更新、視頻會議和聊天等等，這里都不一一列舉了

Web端即時通信方式

什么是web端即時通訊技術(shù)？

可以理解為實現(xiàn)這樣一種功能：服務器端可以即時地將數(shù)據(jù)的更新或變化反應到客戶端，例如消息推送等功能都是通過這種技術(shù)實現(xiàn)的。

但是在Web中，由于瀏覽器的限制，實現(xiàn)即時通訊需要借助一些方法。這種限制出現(xiàn)的主要原因是，一般的Web通信都是瀏覽器先發(fā)送請求到服務器，服務器再進行響應完成數(shù)據(jù)的現(xiàn)實更新。

Web端實現(xiàn)即時通訊主要有四種方式：輪詢、長輪詢(comet)、長連接(SSE)、WebSocket。

它們大體可以分為兩類，一種是在HTTP基礎上實現(xiàn)的，包括短輪詢、長輪詢(comet)、長連接(SSE)；另一種不是在HTTP基礎上實現(xiàn)是，即WebSocket。下面分別介紹一下這四種輪詢方式。

圖片

輪詢

基本思路就是客戶端每隔一段時間向服務器發(fā)送http請求，服務器端在收到請求后，不管是否有所需數(shù)據(jù)返回，都直接進行響應。

圖片

這種方式本質(zhì)上還是客戶端不斷發(fā)送請求，才形成客戶端能實時接收服務端數(shù)數(shù)據(jù)變化的假象。

實現(xiàn)比較簡單，缺點是需要不斷建立http連接，浪費資源，而且在客戶端數(shù)量級很大的情況下會導致服務器壓力陡增，顯然不是好選擇！

輪詢方式，你會發(fā)現(xiàn)在你打開F12調(diào)試頁面時，你會發(fā)現(xiàn)大量的HTTP請求呢 ??????...

長輪詢

輪詢方式是在服務器接收到請求后迅速做出響應。

而長輪詢方式是服務器收到客戶端發(fā)來的請求后，想掛起請求，服務器端不會直接進行響應，在超時時間內(nèi)（比如20S）,接收請求和處理請求進行響應。

圖片

有兩種情況長輪詢會響應：

? 達到http請求超時時間

? 服務器正常處理請求返回響應結(jié)果

長輪詢和短輪詢比起來，明顯減少了很多不必要的http請求次數(shù)，但是連接掛起也會導致資源的浪費！

長連接 SSE

官方介紹：長連接是指在一個連接上可以連續(xù)發(fā)送多個數(shù)據(jù)包，在連接保持期間，如果沒有數(shù)據(jù)包發(fā)送，需要雙方發(fā)鏈路檢測包。

SSE是HTML5新增的功能，全稱為Server-Sent Events，它可以允許服務器推送數(shù)據(jù)到客戶端。

SSE在本質(zhì)上就與之前的長輪詢、輪詢不同，雖然都是基于http協(xié)議的，但是輪詢需要客戶端先發(fā)送請求，服務端才能響應。而SSE最大的特點就是不需要持續(xù)客戶端發(fā)送請求，可以實現(xiàn)只要服務器端數(shù)據(jù)有更新，就可以馬上發(fā)送到客戶端。

圖片

長鏈接流程：連接->傳輸數(shù)據(jù)->保持連接 -> 傳輸數(shù)據(jù)-> ....->直到一方關(guān)閉連接，客戶端關(guān)閉連接

SSE的優(yōu)勢在于，它不需要建立或保持大量的客戶端發(fā)往服務器端的請求，節(jié)約了很多資源，提升應用性能，但是可以關(guān)閉一些長時間不讀寫操作的連接，這樣可以避免一些惡意連接導致server端壓力。

websocket

WebSocket協(xié)議是基于TCP的一種新的網(wǎng)絡協(xié)議，它實現(xiàn)了客戶端與服務器全雙工（full-duplex）通信（同一時間里，雙方都可以主動向?qū)Ψ桨l(fā)送數(shù)據(jù)）。

在WebSocket中，客戶端和服務器只需要完成一次握手，兩者之間就直接可以創(chuàng)建持久性的連接，并進行雙向數(shù)據(jù)傳輸。

圖片

通信方式總結(jié)

??兼容性角度：短輪詢>長輪詢>長連接SSE>WebSocket

??性能方面：WebSocket>長連接SSE>長輪詢>短輪詢

Websocket

我們已經(jīng)知道了WebSocket 是一種網(wǎng)絡傳輸協(xié)議，可在單個 TCP 連接上進行全雙工通信，位于 OSI 模型的應用層。

而通過WebSocket使得客戶端和服務器之間的數(shù)據(jù)交換變得更加簡單，允許服務端主動向客戶端推送數(shù)據(jù)，只需要完成一次握手，兩者之間就直接可以創(chuàng)建持久性的連接。

ok，一起來看看websocket知識！

協(xié)議升級

出于兼容性的考慮，websocket 的握手使用 HTTP 來實現(xiàn)，客戶端的握手消息就是一個「普通的，帶有 Upgrade 頭的，HTTP Request 消息」。

圖片

?? 想建立websoket連接，就需要在http請求上帶一些特殊的header頭才行！

我們看下WebSocket協(xié)議客戶端請求和服務端響應示例，關(guān)于http這里就不多介紹了（這里自行回想下Http請求的request和reposone部分）

header頭的意思是，瀏覽器想升級http協(xié)議，并且想升級成websocket協(xié)議。

客戶端請求：

以下是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. 1. Upgrade：字段必須設置 websocket，表示希望升級到 WebSocket 協(xié)議
2. 2. Connection：須設置 Upgrade，表示客戶端希望連接升級
3. 3. Sec-WebSocket-Key：是隨機的字符串，服務器端會用這些數(shù)據(jù)來構(gòu)造出一個 SHA-1 的信息摘要
4. 4. Origin：字段是可選的，只包含了協(xié)議和主機名稱
5. 5. Sec-WebSocket-Extensions：用于協(xié)商本次連接要使用的 WebSocket 擴展
6. 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. 1. 101 響應碼確認升級到 WebSocket 協(xié)議
2. 2. Connection：值為 “Upgrade” 來指示這是一個升級請求
3. 3. Upgrade：表示升級為 WebSocket 協(xié)議
4. 4. Sec-WebSocket-Accept：簽名的鍵值驗證協(xié)議支持

?? 1：ws 協(xié)議默認使用 80 端口，wss 協(xié)議默認使用 443 端口，和 http 一樣

?? 2：WebSocket 沒有使用 TCP 的“IP 地址 + 端口號”，開頭的協(xié)議名不是“http”，引入的是兩個新的名字：“ws”和“wss”，分別表示明文和加密的 WebSocket 協(xié)議

連接確認

發(fā)建立連接是前提，但是只有當請求頭參數(shù)Sec-WebSocket-Key字段的值經(jīng)過固定算法加密后的數(shù)據(jù)和響應頭里的Sec-WebSocket-Accept的值保持一致，該連接才會被認可建立。

如下圖從瀏覽器截圖的兩個關(guān)鍵參數(shù)：

圖片

服務端返回的響應頭字段 Sec-WebSocket-Accept 是根據(jù)客戶端請求 Header 中的Sec-WebSocket-Key計算出來。

那么時如何進行參數(shù)加密驗證和比對確認的呢，如下圖！

圖片

具體流程如下：

• ? 客戶端握手中的 Sec-WebSocket-Key 頭字段的值是16字節(jié)隨機數(shù)，并經(jīng)過base64編碼
• ? 服務端需將該值和固定的 GUID 字符串（ 258EAFA5-E914-47DA-95CA-C5AB0DC85B11）拼接后使用 SHA-1 進行哈希，并采用 base64 編碼后
• ? 服務端將編碼后的值作為響應作為的Sec-WebSocket-Accept 值返回。
• ? 客戶端也必須按照服務端生成 Sec-WebSocket-Accept 的方式一樣生成字符串，與服務端回傳的進行對比
• ? 相同就是協(xié)議升級成功，不同就是失敗

在協(xié)議升級完成后websokcet就建立完成了，接下來就是客戶端和服務端使用websocket進行數(shù)據(jù)傳輸通信了!

數(shù)據(jù)幀

一旦升級成功 WebSocket 連接建立后，后續(xù)數(shù)據(jù)都以幀序列的形式傳輸。

?? 協(xié)議規(guī)定了數(shù)據(jù)幀的格式，服務端要想給客戶端推送數(shù)據(jù)，必須將要推送的數(shù)據(jù)組裝成一個數(shù)據(jù)幀，這樣客戶端才能接收到正確的數(shù)據(jù)；同樣，服務端接收到客戶端發(fā)送的數(shù)據(jù)時，必須按照幀的格式來解包，才能真確獲取客戶端發(fā)來的數(shù)據(jù)

我們來看下對幀的格式定義吧！

圖片

看看數(shù)據(jù)幀字段代表的含義吧：

1. FIN 1個bit位，用來標記當前數(shù)據(jù)幀是不是最后一個數(shù)據(jù)幀

2. RSV1, RSV2, RSV3 這三個，各占用一個bit位用做擴展用途，沒有這個需求的話設置位0

3. Opcode 的值定義的是數(shù)據(jù)幀的數(shù)據(jù)類型

值為1 表示當前數(shù)據(jù)幀內(nèi)容是文本

值為2 表示當前數(shù)據(jù)幀內(nèi)容是二進制

值為8表示請求關(guān)閉連接

1. MASK 表示數(shù)據(jù)有沒有使用掩碼

服務端發(fā)送給客戶端的數(shù)據(jù)幀不能使用掩碼，客戶端發(fā)送給服務端的數(shù)據(jù)幀必須使用掩碼。

1. Payload len 數(shù)據(jù)的長度，Payload data的長度，占7bits，7+16bits，7+64bits

2. Masking-key 數(shù)據(jù)掩碼 (設置位0，則該部分可以省略，如果設置位1，則用來解碼客戶端發(fā)送給服務端的數(shù)據(jù)幀)

3. Payload data 幀真正要發(fā)送的數(shù)據(jù)，可以是任意長度

上面我們說到Payload len三種長度（最開始的7bit的值）來標記數(shù)據(jù)長度，這里具體看下是哪三種：

?? 情況1：值設置在0-125

那么這個有效載荷長度（Payload len）就是對應的數(shù)據(jù)的值。

圖片

?? 情況2：值設置為126

如果設置為 126，可表示payload的長度范圍在 126~65535 之間，那么接下來的 2 個字節(jié)（擴展用16bit Payload長度）會包含Payload真實數(shù)據(jù)長度。

圖片

?? 情況3：值設置為127

可表示payload的長度范圍在 >=65535 ，那么接下來的 8 個字節(jié)（擴展用16bit + 32bit + 16bit Payload長度）會包含Payload真實數(shù)據(jù)長度，這種情況能表示的數(shù)據(jù)就很大了，完全夠用。

圖片

socket和websocket

這兩者名字上差距不大，雖然都有帶個socket，但是完全是兩個不同的東西， 大家千萬別被名字給帶的傻傻分不清楚了！

我們來看下之間的區(qū)別：

socket：是在應用層和傳輸層之間的一個中間軟件抽象層，是一組接口，它把TCP/IP層復雜的操作抽象為幾個簡單的接口供應用層調(diào)用以實現(xiàn)進程在網(wǎng)絡中通信。

websocket：是基于TCP的一種新的網(wǎng)絡協(xié)議，和http協(xié)議一樣屬于應用層協(xié)議。

下圖中分別表示了socket和websocket在網(wǎng)絡中的位置：

圖片

常見狀態(tài)碼

下面顯示了從服務器到客戶端的通信的 WebSocket 狀態(tài)碼和錯誤提示，WebSocket 狀態(tài)碼遵循 RFC 正常關(guān)閉連接標準

? 1000 CLOSE_NORMAL 連接正常關(guān)閉

? 1001 CLOSE_GOING_AWAY 終端離開 例如：服務器錯誤，或者瀏覽器已經(jīng)離開此頁面

? 1002 CLOSE_PROTOCOL_ERROR 因為協(xié)議錯誤而中斷連接

? 1003 CLOSE_UNSUPPORTED 端點因為受到不能接受的數(shù)據(jù)類型而中斷連接

? 1004 保留

? 1005 CLOSE_NO_STATUS 保留, 用于提示應用未收到連接關(guān)閉的狀態(tài)碼

? 1006 CLOSE_ABNORMAL 期望收到狀態(tài)碼時連接非正常關(guān)閉 (也就是說, 沒有發(fā)送關(guān)閉幀)

? 1007 Unsupported Data 收到的數(shù)據(jù)幀類型不一致而導致連接關(guān)閉

? 1008 Policy Violation 收到不符合約定的數(shù)據(jù)而斷開連接

? 1009 CLOSE_TOO_LARGE 收到的消息數(shù)據(jù)太大而關(guān)閉連接

? 1010 Missing Extension 客戶端因為服務器未協(xié)商擴展而關(guān)閉

? 1011 Internal Error 服務器因為遭遇異常而關(guān)閉連接

? 1012 Service Restart 服務器由于重啟而斷開連接

? 1013 Try Again Later 服務器由于臨時原因斷開連接, 如服務器過載因此斷開一部分客戶端連接

? 1015 TLS握手失敗關(guān)閉連接

總結(jié)

WebSocket 是一種網(wǎng)絡傳輸協(xié)議，可在單個 TCP 連接上進行全雙工通信。

適用于需要客戶端（瀏覽器）和服務端頻繁交互的大部分場景，比如網(wǎng)頁游戲，體育實況，彈幕，以及一些協(xié)同辦公軟件等

圖片

而websocket是利用http協(xié)議，然后加上一些特殊的header頭進行握手Upgrade升級操作，升級成功后就跟http沒有任何關(guān)系了，之后就用websocket的數(shù)據(jù)格式進行收發(fā)數(shù)據(jù)。