IT
開發
WebSocket 基礎與應用系列（一）—— 抓個 WebSocket 的包
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);
//
/**
* 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:
Masked payload: [
可以看到結果與下圖一致。
原始 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 的抓包分析，敬請期待。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/f96Da8kCluNwv7cxW39gzg