你不知道的Websocket協(xié)議，這次給你講明白！

作者：小許code 2023-11-29 08:01:38

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

前言

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

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

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

使用場景再現(xiàn)

在線教育：

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

圖片

視頻彈幕：

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

當(dāng)然還有體育實(shí)況更新、視頻會(huì)議和聊天等等，這里都不一一列舉了

Web端即時(shí)通信方式

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

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

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

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

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

圖片

輪詢

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

圖片

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

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

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

長輪詢

輪詢方式是在服務(wù)器接收到請求后迅速做出響應(yīng)。

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

圖片

有兩種情況長輪詢會(huì)響應(yīng)：

? 達(dá)到http請求超時(shí)時(shí)間

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

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

長連接 SSE

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

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

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

圖片

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

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

websocket

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

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

圖片

通信方式總結(jié)

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

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

Websocket

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

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

ok，一起來看看websocket知識！

協(xié)議升級

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

圖片

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

我們看下WebSocket協(xié)議客戶端請求和服務(wù)端響應(yīng)示例，關(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. Upgrade：字段必須設(shè)置 websocket，表示希望升級到 WebSocket 協(xié)議
2. Connection：須設(shè)置 Upgrade，表示客戶端希望連接升級
3. Sec-WebSocket-Key：是隨機(jī)的字符串，服務(wù)器端會(huì)用這些數(shù)據(jù)來構(gòu)造出一個(gè) SHA-1 的信息摘要
4. Origin：字段是可選的，只包含了協(xié)議和主機(jī)名稱
5. Sec-WebSocket-Extensions：用于協(xié)商本次連接要使用的 WebSocket 擴(kuò)展
6. Sec-WebSocket-Version：表示支持的 WebSocket 版本，RFC6455 要求使用的版本是 13

服務(wù)端響應(yīng)：

HTTP/1.1 101 Web Socket Protocol Handshake  // 1
Connection: Upgrade  // 2
Upgrade: websocket  // 3
Sec-WebSocket-Accept: 2mQFj9iUA/Nz8E6OA4c2/MboVUk=  //4

上述字段說明如下：

1. 101 響應(yīng)碼確認(rèn)升級到 WebSocket 協(xié)議
2. Connection：值為 “Upgrade” 來指示這是一個(gè)升級請求
3. Upgrade：表示升級為 WebSocket 協(xié)議
4. Sec-WebSocket-Accept：簽名的鍵值驗(yàn)證協(xié)議支持

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

連接確認(rèn)

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

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

圖片

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

那么時(shí)如何進(jìn)行參數(shù)加密驗(yàn)證和比對確認(rèn)的呢，如下圖！

圖片

具體流程如下：

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

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

數(shù)據(jù)幀

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

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

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

圖片

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

1. FIN 1個(gè)bit位，用來標(biāo)記當(dāng)前數(shù)據(jù)幀是不是最后一個(gè)數(shù)據(jù)幀

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

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

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

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

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

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

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

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

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

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

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

?? 情況1：值設(shè)置在0-125

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

圖片

?? 情況2：值設(shè)置為126

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

圖片

?? 情況3：值設(shè)置為127

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

圖片