webSocket(一) 淺析

時間 2019-12-01

標籤 websocket 淺析简体版

原文原文鏈接

簡介

WebSocket 由多個標準構成: WebSocket API 是 W3C 定義的，而 WebSocket 協議(RFC 6455)及其擴展則由 HyBi Working Group(IETF)定義。javascript

HTML5 開始提供的一種瀏覽器與服務器進行全雙工通信的網絡技術，屬於應用層協議。它基於TCP 傳輸協議，並複用 HTTP 的握手通道。 WebSocket 能夠實現客戶端與服務器間雙向、基於消息的文本或二進制數據傳輸。WebSocket 鏈接遠遠不是一個網絡套接字，由於瀏覽器在這個簡單的 API 以後隱藏了全部的複雜性，並且還提供了更多服務:html

鏈接協商和同源策略;
與既有 HTTP 基礎設施的互操做;
基於消息的通訊和高效消息分幀;
子協議協商及可擴展能力。

特色

爲何已經有了輪詢還要 WebSocket 呢，是由於短輪詢和長輪詢有個缺陷：通訊只能由客戶端發起。 WebSocket 提供了一個文明優雅的全雙工通訊方案。通常適合於對數據的實時性要求比較強的場景，如通訊、股票、直播、共享桌面，特別適合於客戶端與服務頻繁交互的狀況下，如聊天室、實時共享、多人協做等平臺。他的主要特色以下：java

創建在 TCP 協議之上，服務器端的實現比較容易。
與 HTTP 協議有着良好的兼容性。默認端口也是 80 和 443，而且握手階段採用 HTTP 協議，所以握手時不容易屏蔽，能經過各類 HTTP 代理服務器。
數據格式比較輕量，性能開銷小，通訊高效。服務器與客戶端之間交換的標頭信息大概只有 2 字節;
能夠發送文本，也能夠發送二進制數據。
沒有同源限制，客戶端能夠與任意服務器通訊。
協議標識符是 ws（若是加密，則爲 wss），服務器網址就是 URL。ex：ws://example.com:80/some/path
不用頻繁建立及銷燬 TCP 請求，減小網絡帶寬資源的佔用，同時也節省服務器資源;
WebSocket 是純事件驅動的，一旦鏈接創建，經過監聽事件能夠處理到來的數據和改變的鏈接狀態，數據都以幀序列的形式傳輸。服務端發送數據後，消息和事件會異步到達。
無超時處理。

webSocket.readyState

readyState屬性返回實例對象的當前狀態，共有四種。web

CONNECTING：值爲 0，表示正在鏈接。
OPEN：值爲 1，表示鏈接成功，能夠通訊了。
CLOSING：值爲 2，表示鏈接正在關閉。
CLOSED：值爲 3，表示鏈接已經關閉，或者打開鏈接失敗。

webSocket.onopen

實例對象的onopen屬性，用於指定鏈接成功後的回調函數。ajax

ws.onopen = function() {
  ws.send("Hello Server!");
};
// 若是要指定多個回調函數，可使用addEventListener方法。
ws.addEventListener("open", function(event) {
  ws.send("Hello Server!");
});
複製代碼

webSocket.onclose

實例對象的onclose屬性，用於指定鏈接關閉後的回調函數。算法

ws.onclose = function(event) {
  var code = event.code;
  var reason = event.reason;
  var wasClean = event.wasClean;
  // handle close event
};
ws.addEventListener("close", function(event) {
  var code = event.code;
  var reason = event.reason;
  var wasClean = event.wasClean;
  // handle close event
});
複製代碼

webSocket.onmessage()\webSocket.send()

webSocket.onmessage() 實例對象的onmessage屬性，用於指定收到服務器數據後的回調函數。也能夠處理二進制數據。express

ws.onmessage = function(event) {
  var data = event.data;
  // 處理數據
};

ws.addEventListener("message", function(event) {
  var data = event.data;
  // 處理數據
});

// 注意，服務器數據多是文本，也多是二進制數據（`blob對象或Arraybuffer對象`）。
ws.onmessage = function(event) {
  if (typeof event.data === String) {
    console.log("Received data string");
  }

  if (event.data instanceof ArrayBuffer) {
    var buffer = event.data;
    console.log("Received arraybuffer");
  }
};

// 收到的是 blob 數據
ws.binaryType = "blob";
ws.onmessage = function(e) {
  console.log(e.data.size);
};

// 收到的是 ArrayBuffer 數據
ws.binaryType = "arraybuffer";
ws.onmessage = function(e) {
  console.log(e.data.byteLength);
};
複製代碼

webSocket.send() 實例對象的send()方法用於向服務器發送數據。canvas

ws.onmessage = function(event) {
  var data = event.data;
  // 處理數據
};

ws.addEventListener("message", function(event) {
  var data = event.data;
  // 處理數據
});
// 發送 Blob 對象的例子。
var file = document.querySelector('input[type="file"]').files[0];
ws.send(file);

// 發送 ArrayBuffer 對象的例子。
// Sending canvas ImageData as ArrayBuffer
var img = canvas_context.getImageData(0, 0, 400, 320);
var binary = new Uint8Array(img.data.length);
for (var i = 0; i < img.data.length; i++) {
  binary[i] = img.data[i];
}
ws.send(binary.buffer);
複製代碼

webSocket.bufferedAmount

實例對象的bufferedAmount屬性，表示還有多少字節的二進制數據沒有發送出去。它能夠用來判斷髮送是否結束。segmentfault

var data = new ArrayBuffer(10000000);
socket.send(data);

if (socket.bufferedAmount === 0) {
  // 發送完畢
} else {
  // 發送還沒結束
}
複製代碼

webSocket.onerror

實例對象的onerror屬性，用於指定報錯時的回調函數。瀏覽器

socket.onerror = function(event) {
  // handle error event
};
socket.addEventListener("error", function(event) {
  // handle error event
});
複製代碼

webSocket 學習

對網絡應用層協議的學習來講，最重要的每每就是鏈接創建過程、數據交換教程。固然，數據的格式是逃不掉的，由於它直接決定了協議自己的能力。好的數據格式能讓協議更高效、擴展性更好。大體能夠經過下面的幾個方面來學習:

如何創建鏈接
數據幀格式
數據傳遞
鏈接保持+心跳
Sec-WebSocket-Key/Accept 的做用
數據掩碼的做用

實例

在正式介紹協議細節前，先來看一個簡單的例子，有個直觀感覺。例子包括了WebSocket 服務端、WebSocket 客戶端（網頁端）。完整代碼能夠在這裏找到。這裏服務端用了ws這個庫。相比你們熟悉的socket.io，ws 實現更輕量，更適合學習的目的。

服務端

代碼以下，監聽8080端口。當有新的鏈接請求到達時，打印日誌，同時向客戶端發送消息。當收到到來自客戶端的消息時，一樣打印日誌。

const express = require("express");
const app = express();
const server = require("http").Server(app);
const WebSocket = require("ws");

const wss = new WebSocket.Server({ port: 8080 });
wss.on("connection", function connection(ws) {
  console.log("server: receive connection");
  ws.on("message", function incoming(message) {
    console.log("server: recevied: %s", message);
  });
  ws.send("world");
});

app.get("/", function(req, res) {
  res.sendfile(__dirname + "/index.html");
});
app.listen(3000);
複製代碼

服務端運行結果以下圖所示：

客戶端

代碼以下，向 8080 端口發起 WebSocket 鏈接。鏈接創建後，打印日誌，同時向服務端發送消息。接收到來自服務端的消息後，一樣打印日誌。

const ws = new WebSocket("ws://localhost:8080");
ws.onopen = function() {
  console.log("ws onopen");
  ws.send("from client:hello");
};
ws.onmessage = function(e) {
  console.log("ws onmessage");
  console.log("from server:" + e.data);
};
複製代碼

客戶端運行結果以下圖所示：

如何創建鏈接

前面提到，WebSocket 複用了HTTP 的握手通道。具體指的是，客戶端經過 HTTP 請求與 WebSocket服務端協商升級協議。協議升級完成後，後續的數據交換則遵守WebSocket 的協議。

客戶端：申請協議升級

首先，客戶端發起協議升級請求。能夠看到，採用的是標準的 HTTP 報文格式，且只支持GET 方法。

GET / HTTP/1.1
    Host: localhost:8080
    Origin: http://127.0.0.1:3000
    Connection: Upgrade // 表示要升級協議
    Upgrade: websocket // 表示要升級到websocket協議。
    Sec-WebSocket-Version: 13 // 表示websocket的版本。若是服務端不支持該版本，須要返回一個Sec-WebSocket-Versionheader，裏面包含服務端支持的版本號。
    Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw== // 與後面服務端響應首部的Sec-WebSocket-Accept是配套的，提供基本的防禦，好比惡意的鏈接，或者無心的鏈接。
複製代碼

重點請求首部意義以下：

Connection: Upgrade：表示要升級協議
Upgrade: websocket：表示要升級到 websocket 協議。
Sec-WebSocket-Version: 13：表示 websocket 的版本。若是服務端不支持該版本，須要返回一個 Sec-WebSocket-Versionheader，裏面包含服務端支持的版本號。
Sec-WebSocket-Key：與後面服務端響應首部的 Sec-WebSocket-Accept 是配套的，提供基本的防禦，好比惡意的鏈接，或者無心的鏈接。

注意，上面請求省略了部分非重點請求首部。因爲是標準的 HTTP 請求，相似 Host、Origin、Cookie 等請求首部會照常發送。在握手階段，能夠經過相關請求首部進行安全限制、權限校驗等。

服務端：響應協議升級

服務端返回內容以下，狀態代碼101表示協議切換。到此完成協議升級，後續的數據交互都按照新的協議來。

HTTP/1.1 101 Switching Protocols
    Connection:Upgrade
    Upgrade: websocket
    Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=
複製代碼

以下圖所示：

備註：每一個 header 都以\r\n 結尾，而且最後一行加上一個額外的空行\r\n。此外，服務端迴應的 HTTP 狀態碼只能在握手階段使用。過了握手階段後，就只能採用特定的錯誤碼。

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 = "w4v7O6xFTi36lq3RNcgctw==";

let secWebSocketAccept = crypto
  .createHash("sha1")
  .update(secWebSocketKey + magic)
  .digest("base64");

console.log(secWebSocketAccept);
// Oy4NRAQ13jhfONC7bP8dTKb4PTU=
複製代碼

數據幀格式

客戶端、服務端數據的交換，離不開數據幀格式的定義。所以，在實際講解數據交換以前，咱們先來看下 WebSocket 的數據幀格式。 WebSocket 客戶端、服務端通訊的最小單位是幀（frame），由 1 個或多個幀組成一條完整的消息（message）。

發送端：將消息切割成多個幀，併發送給服務端；
接收端：接收消息幀，並將關聯的幀從新組裝成完整的消息；

數據幀的格式。詳細定義可參考 RFC6455 5.2 節。

數據幀格式概覽

下面給出了 WebSocket 數據幀的統一格式。熟悉 TCP/IP 協議的同窗對這樣的圖應該不陌生。

從左到右，單位是比特。好比FIN、RSV1各佔據 1 比特，opcode佔據 4 比特。
內容包括了標識、操做代碼、掩碼、數據、數據長度等。（下一小節會展開）

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：表示鏈接斷開。
%x9：表示這是一個 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，重要的位在前）。

**Masking-key：**或 4 字節（32 位）全部從客戶端傳送到服務端的數據幀，數據載荷都進行了掩碼操做，Mask 爲 1，且攜帶了 4 字節的 Masking-key。若是 Mask 爲 0，則沒有 Masking-key。

備註：載荷數據的長度，不包括 mask key 的長度。

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

數據傳遞

一旦 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!
複製代碼

鏈接保持+心跳

WebSocket 爲了保持客戶端、服務端的實時雙向通訊，須要確保客戶端、服務端之間的 TCP 通道保持鏈接沒有斷開。然而，對於長時間沒有數據往來的鏈接，若是依舊長時間保持着，可能會浪費包括的鏈接資源。但不排除有些場景，客戶端、服務端雖然長時間沒有數據往來，但仍須要保持鏈接。這個時候，能夠採用心跳來實現。

發送方->接收方：ping
接收方->發送方：pong

ping、pong 的操做，對應的是 WebSocket 的兩個控制幀，opcode 分別是 0x九、0xA。

舉例，WebSocket 服務端向客戶端發送 ping，只須要以下代碼（採用 ws 模塊）

ws.ping("", false, true);
複製代碼

Sec-WebSocket-Key/Accept 的做用

前面提到了，Sec-WebSocket-Key/Sec-WebSocket-Accept在主要做用在於提供基礎的防禦，減小惡意鏈接、意外鏈接。

做用大體概括以下：

避免服務端收到非法的 websocket 鏈接（好比 http 客戶端不當心請求鏈接 websocket 服務，此時服務端能夠直接拒絕鏈接）
確保服務端理解 websocket 鏈接。由於 ws 握手階段採用的是 http 協議，所以可能 ws 鏈接是被一個 http 服務器處理並返回的，此時客戶端能夠經過 Sec-WebSocket-Key 來確保服務端認識 ws 協議。（並不是百分百保險，好比老是存在那麼些無聊的 http 服務器，光處理 Sec-WebSocket-Key，但並無實現 ws 協議。。。）
用瀏覽器裏發起 ajax 請求，設置 header 時，Sec-WebSocket-Key 以及其餘相關的 header 是被禁止的。這樣能夠避免客戶端發送 ajax 請求時，意外請求協議升級（websocket upgrade）
能夠防止反向代理（不理解 ws 協議）返回錯誤的數據。好比反向代理先後收到兩次 ws 鏈接的升級請求，反向代理把第一次請求的返回給 cache 住，而後第二次請求到來時直接把 cache 住的請求給返回（無心義的返回）。
Sec-WebSocket-Key 主要目的並非確保數據的安全性，由於 Sec-WebSocket-Key、Sec-WebSocket-Accept 的轉換計算公式是公開的，並且很是簡單，最主要的做用是預防一些常見的意外狀況（非故意的）。