1 為什么需要 WebSocket
WebSocket 是為了滿足基於 Web 的日益增長的實時通信需求而產生的。
在傳統的 Web 中，要實現實時通信，通用的方式是采用 HTTP 協議不斷發送請求，即輪詢（Polling）。
但這種方式既浪費帶寬（HTTP HEAD 是比較大的），又導致服務器 CPU 占用（沒有信息也要接受請求）。
而使用 WebSocket 技術，則能大幅優化上面提到的問題：
2 WebSocket 簡介
WebSocket 協議在 2008 年誕生，2011 年成為國際標准。所有瀏覽器都已經支持了。
它是從 HTML5 開始提供的一種瀏覽器與服務器進行全雙工通訊的網絡技術，屬於應用層協議。它基於 TCP 傳輸協議，並復用 HTTP 的握手通道。
它的最大特點就是，服務器可以主動向客戶端推送信息，客戶端也可以主動向服務器發送信息，是真正的雙向平等對話，屬於服務器推送技術的一種。
其他特點包括：
-
建立在 TCP 協議之上，服務器端的實現比較容易。
-
與 HTTP 協議有着良好的兼容性。默認端口也是 80 和 443，並且握手階段采用 HTTP 協議，因此握手時不容易屏蔽，能通過各種 HTTP 代理服務器。
-
較少的控制開銷。連接創建后，ws 客戶端、服務端進行數據交換時，協議控制的數據包頭部較小。在不包含頭部的情況下，服務端到客戶端的包頭只有 2~10 字節（取決於數據包長度），客戶端到服務端的的話，需要加上額外的 4 字節的掩碼。而 HTTP 協議每次通信都需要攜帶完整的頭部。
-
可以發送文本，也可以發送二進制數據。
-
沒有同源限制，客戶端可以與任意服務器通信。
-
協議標識符是 ws（如果加密，則為 wss），服務器網址就是 URL。
-
支持擴展。ws 協議定義了擴展，用戶可以擴展協議，或者實現自定義的子協議。（比如支持自定義壓縮算法等）
2.1 WebSocket、HTTP、TCP 之間的關系
在下圖中，我們只需要知道，HTTP、WebSocket 等協議都是處於 OSI 模型的最高層：應用層。而 IP 協議工作在網絡層（第 3 層），TCP 協議工作在傳輸層（第 4 層）。
HTTP、WebSocket 等應用層協議，都是基於 TCP 協議來傳輸數據的。我們可以把這些高級協議理解成對 TCP 的封裝。既然大家都使用 TCP 協議，那么大家的連接和斷開，都要遵循 TCP 協議中的三次握手和四次揮手 ，只是在連接之后發送的內容不同，或者是斷開的時間不同。
2.2 HTML5 與 WebSocket
WebSocket API 是 HTML5 標准的一部分， 但這並不代表 WebSocket 一定要用在 HTML 中，或者只能在基於瀏覽器的應用程序中使用。
實際上，許多語言、框架和服務器都提供了 WebSocket 支持，例如：
-
基於 C 的 libwebsocket.org
-
基於 Node.js 的 Socket.io
-
基於 Python 的 ws4py
-
基於 C++ 的 WebSocket++
-
Apache 對 WebSocket 的支持：Apache Module mod_proxy_wstunnel
-
Nginx 對 WebSockets 的支持：NGINX as a WebSockets Proxy 、 NGINX Announces Support for WebSocket Protocol 、WebSocket proxying
-
lighttpd 對 WebSocket 的支持：mod_websocket
3 例子與抓包分析
3.1 入門例子
先來看一個簡單的例子，有個直觀感受。例子包括了 WebSocket 服務端（ Node.js ）、WebSocket 客戶端。
服務端
// 導入WebSocket模塊:
const WebSocket = require('ws');
// 引用Server類:
const WebSocketServer = WebSocket.Server;
// 實例化:
const wss = new WebSocketServer({
port: 3000
});
wss.on('connection', function (ws) {
console.log(`[SERVER] connection()`);
ws.on('message', function (message) {
console.log(`[SERVER] Received: ${message}`);
ws.send(`message from server: ${message}`, (err) => {
if (err) {
console.log(`[SERVER] error: ${err}`);
}
});
})
});
客戶端
const WebSocket = require('ws');
const ws = new WebSocket('ws://localhost:3000/');
ws.on('open', function open() {
console.log('[CLIENT]: open')
ws.send('something');
});
ws.on('close', function close(){
console.log('[CLIENT]: close');
});
ws.on('message', function incoming(data) {
console.log('[CLIENT]: Received:',data);
});
ws.on('ping', function(){
console.log('[CLIENT]: ping')
})
運行結果
服務端輸出
[SERVER] connection()
[SERVER] Received: something
客戶端輸出
[CLIENT]: open
[CLIENT]: Received: message from server: something
3.2 從抓包看如何建立連接
工具准備
-
安裝 Wireshark 抓包軟件；
-
在 Capture 中選擇本機回環網絡；
-
在 filter 中寫入過濾條件 tcp.port == 3000 (ws 服務端口)。
這樣就可以抓到你想要的包啦：
為了更好的對比 WebSocket 的連接及數據傳輸與 TCP 和 HTTP 有什么區別，我們再抓一下 TCP 和 HTTP 的包。
TCP 抓包
服務端代碼
const net = require('net');
const server = net.createServer();
server.on('connection', (socket) => {
socket.on('data', (data) => {
console.log('Receive from client:', data.toString('utf8'));
});
socket.write('Hello, I am from server.');
});
server.listen(3000, () => {
console.log('Server is listenning on 3000');
});
客戶端代碼
const net = require('net');
const client = new net.Socket();
client.setEncoding('utf8');
client.connect(3000, () => {
console.log('Connected to server.');
client.write('Hello, I am from client.');
client.on('data', (data) => {
console.log('Receive from server:', data);
});
});
抓包結果
簡單理解一下 TCP FLAGS：
在 TCP 層，有個 FLAGS 字段，這個字段有以下幾個標識：SYN (synchronous 建立聯機)、ACK (acknowledgement 確認)、PSH (push 傳送)、FIN (finish 結束)、RST (reset 重置)、URG (urgent 緊急)。
其中，對於我們日常的分析有用的就是前面的五個字段。
它們的含義分別是：
-
SYN 表示建立連接；
-
FIN 表示關閉連接；
-
ACK 表示響應；
-
PSH 表示有 DATA 數據傳輸；
-
RST 表示連接重置。
用一張圖清楚表示一下 TCP 3 次握手及 4 次揮手的過程。
HTTP 抓包
服務端代碼
const http = require('http');
const server = http.createServer();
server.on('request', (req, res) => {
console.log('request ...');
req.on('data', (data) => {
console.log('data from client ', data.toString('utf-8'));
});
res.write('Hello, I am Server');
res.end();
});
server.listen(3000);
客戶端代碼
const request = require('request');
request('http://127.0.0.1:3000?param=1', (err, response, body) => {
console.log('Response:', body);
});
可以看到連接和斷開連接和 TCP 都是一樣的，中間的數據傳輸換成了 HTTP 協議數據：
3.2 再回來看 WebSocket 的抓包：如何建立連接
WebSocket 復用了 HTTP 的握手通道。具體指的是，客戶端通過 HTTP 請求與 WebSocket 服務端協商升級協議。協議升級完成后，后續的數據交換則遵照 WebSocket 的協議。
客戶端：申請協議升級
首先，客戶端發起協議升級請求。可以看到，采用的是標准的 HTTP 報文格式，且只支持 GET 方法。
Connection: Upgrade：表示要升級協議。
Upgrade: websocket：表示要升級到 websocket 協議。
Sec-WebSocket-Version: 13：表示 websocket 的版本。如果服務端不支持該版本，需要返回一個。
Sec-WebSocket-Key：與后面服務端響應首部的 Sec-WebSocket-Accept 是配套的，提供基本的防護，比如惡意的連接，或者無意的連接。
服務端：響應協議升級
服務端返回內容如下，狀態代碼 101 表示協議切換：
到此完成協議升級，后續的數據交互都按照新的協議來。
Sec-WebSocket-Accept 的計算
Sec-WebSocket-Accept 根據客戶端請求首部的 Sec-WebSocket-Key 計算出來。
計算公式為：
將 Sec-WebSocket-Key 跟 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 拼接。通過 SHA1 計算出摘要，並轉成 base64 字符串。偽代碼如下：
toBase64( sha1( Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 ) )
驗證下前面的返回結果：
const crypto = require('crypto');
const magic = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
const secWebSocketKey = '8cyP/EvUjJHSMbkOIHFU/w==';
const secWebSocketAccept = crypto.createHash('sha1')
.update(secWebSocketKey + magic)
.digest('base64');
console.log(secWebSocketAccept);
// EiaKGKO0E/pC8vnArob263aS3XY=3.3 數據幀格式
客戶端、服務端數據的交換，離不開數據幀格式的定義。因此，在實際講解數據交換之前，我們先來看下 WebSocket 的數據幀格式。
WebSocket 客戶端、服務端通信的最小單位是幀（frame），由 1 個或多個幀組成一條完整的消息（message）。
發送端：將消息切割成多個幀，並發送給服務端；接收端：接收消息幀，並將關聯的幀重新組裝成完整的消息。
數據幀格式概覽
下面給出了 WebSocket 數據幀的統一格式 從左到右，單位是比特。比如 FIN、RSV1 各占據 1 比特，opcode 占據 4 比特。內容包括了標識、操作代碼、掩碼、數據、數據長度等。
Frame format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+抓包例子:
數據幀格式詳解
FIN：1 個比特。
如果是 1，表示這是消息（message）的最后一個分片（fragment），如果是 0，表示不是是消息（message）的最后一個分片（fragment）。
RSV1, RSV2, RSV3：各占 1 個比特。
一般情況下全為 0。當客戶端、服務端協商采用 WebSocket 擴展時，這三個標志位可以非 0，且值的含義由擴展進行定義。如果出現非零的值，且並沒有采用 WebSocket 擴展，連接出錯。
Opcode: 4 個比特。
操作代碼，Opcode 的值決定了應該如何解析后續的數據載荷（data payload）。如果操作代碼是不認識的，那么接收端應該斷開連接（fail the connection）。可選的操作代碼如下：
-
% x0：表示一個延續幀。當 Opcode 為 0 時，表示本次數據傳輸采用了數據分片，當前收到的數據幀為其中一個數據分片。
-
% x1：表示這是一個文本幀。（frame）
-
% x2：表示這是一個二進制幀。（frame）
-
% x3-7：保留的操作代碼，用於后續定義的非控制幀。
-
% x8：表示連接斷開。
-
% x8：表示這是一個 ping 操作。
-
% xA：表示這是一個 pong 操作。
-
% xB-F：保留的操作代碼，用於后續定義的控制幀。
Mask: 1 個比特。
表示是否要對數據載荷進行掩碼操作。從客戶端向服務端發送數據時，需要對數據進行掩碼操作；從服務端向客戶端發送數據時，不需要對數據進行掩碼操作。
如果服務端接收到的數據沒有進行過掩碼操作，服務端需要斷開連接。
如果 Mask 是 1，那么在 Masking-key 中會定義一個掩碼鍵（masking key），並用這個掩碼鍵來對數據載荷進行反掩碼。所有客戶端發送到服務端的數據幀，Mask 都是 1。
Payload length：數據載荷的長度，單位是字節。為 7 位，或 7+16 位，或 1+64 位。
假設數 Payload length === x，如果：
-
x 為 0~126：數據的長度為 x 字節。
-
x 為 126：后續 2 個字節代表一個 16 位的無符號整數，該無符號整數的值為數據的長度。
-
x 為 127：后續 8 個字節代表一個 64 位的無符號整數（最高位為 0），該無符號整數的值為數據的長度。此外，如果 payload length 占用了多個字節的話，payload length 的二進制表達采用網絡序（big endian，重要的位在前）。
// 來自 ws庫 sender.js frame函數
let payloadLength = data.length;
if (data.length >= 65536) {
offset += 8;
payloadLength = 127;
} elseif (data.length > 125) {
offset += 2;
payloadLength = 126;
}
Masking-key：0 或 4 字節。（32 位）
所有從客戶端傳送到服務端的數據幀，數據載荷都進行了掩碼操作，Mask 為 1，且攜帶了 4 字節的 Masking-key。如果 Mask 為 0，則沒有 Masking-key。
備注：載荷數據的長度，不包括 mask key 的長度。
//mask key的生成
//每個數據幀都會生成一次
const mask = Buffer.alloc(4);
randomFillSync(mask, 0, 4);
Payload data：(x+y) 字節。
載荷數據：包括了擴展數據、應用數據。其中，擴展數據 x 字節，應用數據 y 字節。
擴展數據：如果沒有協商使用擴展的話，擴展數據數據為 0 字節。所有的擴展都必須聲明擴展數據的長度，或者可以如何計算出擴展數據的長度。此外，擴展如何使用必須在握手階段就協商好。如果擴展數據存在，那么載荷數據長度必須將擴展數據的長度包含在內。
應用數據：任意的應用數據，在擴展數據之后（如果存在擴展數據），占據了數據幀剩余的位置。載荷數據長度 減去 擴展數據長度，就得到應用數據的長度。
掩碼算法
掩碼鍵（Masking-key）是由客戶端挑選出來的 32 位的隨機數。掩碼操作不會影響數據載荷的長度。掩碼、反掩碼操作都采用如下算法：
首先，假設：
-
original-octet-i：為原始數據的第 i 字節。
-
transformed-octet-i：為轉換后的數據的第 i 字節。
-
j：為 i mod 4 的結果。
-
masking-key-octet-j：為 mask key 第 j 字節。
算法描述為：original-octet-i 與 masking-key-octet-j 異或后，得到 transformed-octet-i。
j = i MOD 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j
ws 庫中的 mask 和 unmask 函數：
// mask 的生成
// const mask = crypto.randomBytes(4);
// <Buffer 54 63 0c 77>
/**
* Masks a buffer using the given mask.
*
* @param {Buffer} source The buffer to mask
* @param {Buffer} mask The mask to use
* @param {Buffer} output The buffer where to store the result
* @param {Number} offset The offset at which to start writing
* @param {Number} length The number of bytes to mask.
* @public
*/
function _mask(source, mask, output, offset, length) {
for (var i = 0; i < length; i++) {
output[offset + i] = source[i] ^ mask[i & 3];
}
}
/**
* Unmasks a buffer using the given mask.
*
* @param {Buffer} buffer The buffer to unmask
* @param {Buffer} mask The mask to use
* @public
*/
function _unmask(buffer, mask) {
// Required until https://github.com/nodejs/node/issues/9006 is resolved.
const length = buffer.length;
for (var i = 0; i < length; i++) {
buffer[i] ^= mask[i & 3];
}
}
/**
* Frames a piece of data according to the HyBi WebSocket protocol.
*
* @param {Buffer} data The data to frame
* @param {Object} options Options object
* @param {Number} options.opcode The opcode
* @param {Boolean} options.readOnly Specifies whether `data` can be modified
* @param {Boolean} options.fin Specifies whether or not to set the FIN bit
* @param {Boolean} options.mask Specifies whether or not to mask `data`
* @param {Boolean} options.rsv1 Specifies whether or not to set the RSV1 bit
* @return {Buffer[]} The framed data as a list of `Buffer` instances
* @public
*/
function frame(data, options) {
const merge = data.length < 1024 || (options.mask && options.readOnly);
let offset = options.mask ? 6 : 2;
let payloadLength = data.length;
if (data.length >= 65536) {
offset += 8;
payloadLength = 127;
} elseif (data.length > 125) {
offset += 2;
payloadLength = 126;
}
const target = Buffer.allocUnsafe(merge ? data.length + offset : offset);
target[0] = options.fin ? options.opcode | 0x80 : options.opcode;
if (options.rsv1) target[0] |= 0x40;
if (payloadLength === 126) {
target.writeUInt16BE(data.length, 2);
} elseif (payloadLength === 127) {
target.writeUInt32BE(0, 2);
target.writeUInt32BE(data.length, 6);
}
if (!options.mask) {
target[1] = payloadLength;
if (merge) {
data.copy(target, offset);
return [target];
}
return [target, data];
}
//驗證一下
// const mask = crypto.randomBytes(4);
const mask = Buffer.from('32fd435f', 'hex'); //為了還原例子，這里直接指定mask
target[1] = payloadLength | 0x80;
target[offset - 4] = mask[0];
target[offset - 3] = mask[1];
target[offset - 2] = mask[2];
target[offset - 1] = mask[3];
if (merge) {
_mask(data, mask, target, offset, data.length);
return [target];
}
_mask(data, mask, data, 0, data.length);
return [target, data];
}
const str = 'something';
const source = Buffer.from(str);
const target = frame(source, {
fin: true, rsv1: false, opcode: 1, mask: true, readOnly: false,
});
console.log('Payload:', source);
console.log('Masked payload:', target);
Payload: <Buffer 73 6f 6d 65 74 68 69 6e 67>
Masked payload: [ <Buffer 81 89 32 fd 43 5f 41 92 2e 3a 46 95 2a 31 55> ]
可以看到結果與下圖一致。
原始 payload:
masked payload:
3.4 數據傳遞
一旦 WebSocket 客戶端、服務端建立連接后，后續的操作都是基於數據幀的傳遞。
WebSocket 根據 opcode 來區分操作的類型。比如 0x8 表示斷開連接，0x0-0x2 表示數據交互。
斷開連接：
數據分片
WebSocket 的每條消息可能被切分成多個數據幀。當 WebSocket 的接收方收到一個數據幀時，會根據 FIN 的值來判斷，是否已經收到消息的最后一個數據幀。
FIN=1 表示當前數據幀為消息的最后一個數據幀，此時接收方已經收到完整的消息，可以對消息進行處理。FIN=0，則接收方還需要繼續監聽接收其余的數據幀。
此外，opcode 在數據交換的場景下，表示的是數據的類型。0x01 表示文本，0x02 表示二進制。而 0x00 比較特殊，表示延續幀（continuation frame），顧名思義，就是完整消息對應的數據幀還沒接收完。
數據分片例子
下面例子來自 MDN，可以很好地演示數據的分片。客戶端向服務端兩次發送消息，服務端收到消息后回應客戶端，這里主要看客戶端往服務端發送的消息。
第一條消息
FIN=1, 表示是當前消息的最后一個數據幀。服務端收到當前數據幀后，可以處理消息。opcode=0x1，表示客戶端發送的是文本類型。
第二條消息
-
FIN=0，opcode=0x1，表示發送的是文本類型，且消息還沒發送完成，還有后續的數據幀。
-
FIN=0，opcode=0x0，表示消息還沒發送完成，還有后續的數據幀，當前的數據幀需要接在上一條數據幀之后。
-
FIN=1，opcode=0x0，表示消息已經發送完成，沒有后續的數據幀，當前的數據幀需要接在上一條數據幀之后。服務端可以將關聯的數據幀組裝成完整的消息。
Client: FIN=1, opcode=0x1, msg="hello"
Server: (process complete message immediately) Hi.
Client: FIN=0, opcode=0x1, msg="and a"
Server: (listening, new message containing text started)
Client: FIN=0, opcode=0x0, msg="happy new"
Server: (listening, payload concatenated to previous message)
Client: FIN=1, opcode=0x0, msg="year!"
Server: (process complete message) Happy new year to you too!
3.5 連接保持 + 心跳
WebSocket 為了保持客戶端、服務端的實時雙向通信，需要確保客戶端、服務端之間的 TCP 通道保持連接沒有斷開。然而，對於長時間沒有數據往來的連接，如果依舊長時間保持着，可能會浪費包括的連接資源。
但不排除有些場景，客戶端、服務端雖然長時間沒有數據往來，但仍需要保持連接。這個時候，可以采用心跳來實現。
發送方 -> 接收方：ping 。
接收方 -> 發送方：pong 。
ping 、pong 的操作，對應的是 WebSocket 的兩個控制幀，opcode 分別是 0x9、0xA。
舉例，WebSocket 服務端向客戶端發送 ping，只需要如下代碼：（采用 ws 模塊）
ws.ping('', false, true);
后續
今天的 WebSocket 抓包分析就先到這，后續會繼續分析基於 WebSocket 之上的 Engine.io 以及 Socket.io 的抓包分析，敬請期待。
轉自https://mp.weixin.qq.com/s/f96Da8kCluNwv7cxW39gzg