How Javascript works (Javascript工做原理) (五) 深刻理解 WebSockets 和帶有 SSE 機制的HTTP/2 以及正確的使用姿式

時間 2019-11-11

標籤 javascript works 原理深刻理解 websockets 帶有 sse 機制 http 以及正確使用欄目 JavaScript 简体版

原文原文鏈接

我的總結:html

1.長鏈接機制——分清Websocket，http2，SSE:git

1)HTTP/2 引進了 Server Push 技術用來讓服務器主動向客戶端緩存發送數據。然而，它並不容許直接向客戶端程序自己發送數據。服務端推送只能由瀏覽器處理而不可以在程序代碼中進行處理，意即程序代碼沒有 API 能夠用來獲取這些事件的通知。github

2)經過SSE(Server Side Event)來實現服務端向客戶端的單向推送，SSE基於HTTP，是單向通訊。 web

3)WebSocket是在服務端和客戶端創建雙工通訊。基於TCP。ajax

SSE和WebSocket都是HTML5中引入的。（下面圖片截自www.runnoob.com）json

這是 JavaScript 工做原理的第五章。api

如今，咱們將會深刻通訊協議的世界，繪製並討論它們的特色和內部構造。咱們將會給出一份 WebSockets 和 HTTP/2 的快速比較。在文末，咱們將會分享如何正確地選擇網絡協議的一些看法。瀏覽器

簡介

如今，複雜的網頁程序擁有豐富的功能，這得多虧網頁的動態交互能力。而這並不使人感到驚訝－由於自互聯網誕生，它經歷了一段至關長的時間。緩存

起初，互聯網並非用來支持如此動態和複雜的網頁程序的。它原本設想是由大量的 HTML 頁面組成的，每一個頁面連接到其它的頁面，這樣就造成了包含信息的網頁的概念。一切都是極大地圍繞着所謂的 HTTP 請求/響應模式來創建的。客戶端加載一個網頁，直到用戶點擊頁面並導航到下一個網頁。安全

大約在 2005 年，引入了 AJAX，而後不少人開始探索客戶端和服務端雙向通訊的可能性。然而，全部的 HTTP 連接是由客戶端控制的，意即必須由用戶進行操做或者按期輪詢以從服務器加載數據。

讓 HTTP 支持雙向通訊

支持服務器主動向客戶端推送數據的技術已經出現了好一段時間了。好比 "Push" 和 "Comet" 技術。

長輪詢是服務端主動向客戶端發送數據的最多見的 hack 之一。經過長輪詢，客戶端打開了一個到服務端的 HTTP 鏈接直到返回響應數據。當服務端有新數據須要發送時，它會把新數據做爲響應發送給客戶端。

讓咱們看一下簡單的長輪詢代碼片斷：

(function poll(){
   setInterval(function(){
      $.ajax({ 
        url: 'https://api.example.com/endpoint', 
        success: function(data) {
          // 處理 `data`
          // ...

          //遞歸調用下一個輪詢
          poll();
        }, 
        dataType: 'json'
      });
  }, 10000);
})();

這基本上是一個自執行函數，第一次會自動運行。它每隔 10 秒鐘異步請求服務器而且當每次發起對服務器的異步請求以後，會在回調函數裏面再次調用 ajax 函數。

其它技術涉及到 Flash 和 XHR 多方請求以及所謂的 htmlfiles。

全部這些方案都有一個共同的問題：都帶有 HTTP 開銷，這樣就會使得它們沒法知足要求低延遲的程序。試想一下瀏覽器中的第一人稱射擊遊戲或者其它要求實時組件功能的在線遊戲。

WebSockets 的出現

WebSocket 規範定義了一個 API 用以在網頁瀏覽器和服務器創建一個 "socket" 鏈接（TCP協議上）。通俗地講：在客戶端和服務器保有一個持久的鏈接，兩邊能夠在任意時間開始發送數據。

客戶端經過 WebSocket 握手的過程來建立 WebSocket 鏈接。在這一過程當中，首先客戶端向服務器發起一個常規的 HTTP 請求。請求中會包含一個 Upgrade 的請求頭，通知服務器客戶端想要創建一個 WebSocket 鏈接。

讓咱們看下如何在客戶端建立 WebSocket 鏈接：

// 建立新的加密 WebSocket 鏈接
var socket = new WebSocket('ws://websocket.example.com');

WebSocket 地址使用了 ws 方案。wss 是一個等同於 HTTPS 的安全的 WebSocket 鏈接。

該方案是打開到 websocket.example.com 的 WebSocket 鏈接的開始。

下面是初始化請求頭的簡化例子。

GET ws://websocket.example.com/ HTTP/1.1
Origin: http://example.com
Connection: Upgrade
Host: websocket.example.com
Upgrade: websocket

若是服務器支持 WebSocket 協議，它將會贊成升級請求，而後經過在響應裏面返回 Upgrade 頭來進行通訊。

讓咱們看下 Node.js 的實現：

// 咱們將會使用 https://github.com/theturtle32/WebSocket-Node 來實現 WebSocket
var WebSocketServer = require('websocket').server;
var http = require('http');

var server = http.createServer(function(request, response) {
  // 處理 HTTP 請求
});
server.listen(1337, function() { });

// 建立服務器
wsServer = new WebSocketServer({
  httpServer: server
});

// WebSocket 服務器
wsServer.on('request', function(request) {
  var connection = request.accept(null, request.origin);

  // 這是最重要的回調，在這裏處理全部用戶返回的信息
  connection.on('message', function(message) {
      // 處理 WebSocket 信息
  });

  connection.on('close', function(connection) {
    // 關閉鏈接
  });
});

鏈接創建以後，服務器使用升級來做爲回覆：

HTTP/1.1 101 Switching Protocols
Date: Wed, 25 Oct 2017 10:07:34 GMT
Connection: Upgrade
Upgrade: WebSocket

一旦鏈接創建，會觸發客戶端 WebSocket 實例的 open 事件。

var socket = new WebSocket('ws://websocket.example.com');

// WebSocket 鏈接打開的時候，打印出 WebSocket 已鏈接的信息
socket.onopen = function(event) {
  console.log('WebSocket is connected.');
};

如今，握手結束了，最初的 HTTP 鏈接被替換爲 WebSocket 鏈接，該鏈接底層使用一樣的 TCP/IP 鏈接。如今兩邊均可以開始發送數據了。

經過 WebSocket，你能夠隨意發送數據而不用擔憂傳統 HTTP 請求所帶來的相關開銷。數據是以消息的形式經過 WebSocket 進行傳輸的，每條信息是由包含你所傳輸的數據(有效載荷)的一個或多個幀所組成的。爲了保證當消息到達客戶端的時候被正確地從新組裝出來，每一幀都會前置關於有效載荷的 4-12 字節的數據。使用這種基於幀的信息系統能夠幫助減小非有效載荷數據的傳輸，從而顯著地減小信息延遲。

**注意：**這裏須要注意的是隻有當全部的消息幀都被接收到並且原始的信息有效載荷被從新組裝的時候，客戶端纔會接收到新消息的通知。

WebSocket 地址

前面咱們簡要地談到 WebSockets 引進了一個新的地址協議。實際上，WebSocket 引進了兩種新協議：ws:// 和 wss://。

URL 地址含有指定方案的語法。WebSocket 地址特別之處在於，它不支持錨(sample_anchor)。

WebSocket 和 HTTP 風格的地址使用相同的地址規則。ws 是未加密且默認是 80 端口，而 wss 要求 TSL 加密且默認 443 端口。

幀協議

讓咱們深刻了解下幀協議。這是 RFC 提供的：

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 ...                |
     +---------------------------------------------------------------+

因爲 WebSocket 版本是由 RFC 所規定的，因此每一個包前面只有一個頭部信息。然而，這個頭部信息至關的複雜。這是其組成模塊的說明：

fin(1 位)：指示是不是組成信息的最後一幀。大多數時候，信息只有一幀因此該位一般有值。測試代表火狐的第二幀數據在 32K 以後。
rsv1，rsv2，rsv3(每一個一位)：必須是 0 除非使用協商擴展來定義非 0 值的含義。若是收到一個非 0 值且沒有協商擴展來定義非零值的含義，接收端會中斷鏈接。
opcode(4 位)：表示第幾幀。目前可用的值：

0x00：該幀接續前面一幀的有效載荷。

0x01：該幀包含文本數據。

0x02：該幀包含二進制數據。

0x08：該幀中斷鏈接。

0x09：該幀是一個 ping。

0x0a：該幀是一個pong。

(正如你所看到的，有至關一部分值未被使用；它們是保留以備將來使用的)。
mask(1 位)：指示該鏈接是否被遮罩。正其所表示的意義，每一條從客戶端發往服務器的信息都必須被遮罩，而後若是信息未遮罩，根據規範會中斷該鏈接。
payload_len(7 位)：有效載荷的長度。WebSocket 幀有如下幾類長度：

0-125 表示有效載荷的長度。126 意味着接下來兩個字節表示有效載荷長度，127 意味着接下來的 8 個字節表示有效載荷長度。因此有效載荷的長度大概有 7 位，16 位和 64 位這三類。
masking-key (32 位)：全部從客戶端發往服務器的幀都由幀內的一個 32 位值所遮罩。
payload：通常狀況下都會被遮罩的實際數據。其長度取決於 payload_len 的長度。

爲何 WebSocket 是基於幀而不是基於流的呢？我和你同樣一臉懵逼，我也想多學點，若是你有任何想法，歡迎在下面的評論區添加評論和資源。另外，HackerNews 上面有關於這方面的討論。

幀數據

正如以前提到的，數據能夠被拆分爲多個幀。第一幀所傳輸的數據裏面含有一個操做碼錶示數據的傳輸順序。這是必須的，由於當規範完成的時候，JavaScript 並不能很好地支持二進制數據的傳輸。0x01 表示 utf-8 編碼的文本數據，0x02 表示二進制數據。大多數人在傳輸 JSON 數據的時候都會選擇文本操做碼。當你傳輸二進制數據的時候，它會以瀏覽器指定的 Blob來表示。

經過 WebSocket 來傳輸數據的 API 是很是簡單的：

var socket = new WebSocket('ws://websocket.example.com');
socket.onopen = function(event) {
  socket.send('Some message'); // 向服務器發送數據
};

當 WebSocket 正在接收數據的時候（客戶端），會觸發 message 事件。該事件會帶有一個 data 屬性，裏面包含了消息的內容。

// 處理服務器返回的消息
socket.onmessage = function(event) {
  var message = event.data;
  console.log(message);
};

你能夠很容易地利用 Chrome 開發者工具的網絡選項卡來檢查 WebSocket 鏈接中的每一幀的數據。

數據分片

有效載荷數據能夠被分紅多個獨立的幀。接收端會緩衝這些幀直到 fin 位有值。因此你能夠把字符串『Hello World』拆分爲 11 個包，每一個包由 6(頭長度) + 1 字節組成。數據分片不能用來控制包。然而，規範想要你有能力去處理交錯控制幀。這是爲了預防 TCP 包無序到達客戶端。

鏈接幀的大概邏輯以下：

接收第一幀
記住操做碼
鏈接幀有效載荷直到 fin 位有值
斷言每一個包的操做碼都爲 0

數據分片的主要目的在於容許開始時傳輸不明大小的信息。經過數據分片，服務器可能須要設置一個合理的緩衝區大小，而後當緩衝區滿，返回一個數據分片。數據分片的第二個用途即多路複用，邏輯通道上的大量數據佔據整個輸出通道是不合理的，因此利用多路複用技術把信息拆分紅更小的數據分片以更好地共享輸出通道。

心跳包

握手以後的任意時刻，客戶端和服務器能夠隨意地 ping 對方。當接收到 ping 的時候，接收方必須儘快回覆一個 pong。此即心跳包。你能夠用它來確保客戶端是否保持鏈接。

ping 或者 pong 雖然只是一個普通幀，但倒是一個控制幀。Ping 包含 0x9 操做碼，而 Pong 包含 0xA 操做碼。當你接收到 ping 的時候，返回一個和 ping 攜帶一樣有效載荷數據的 pong(ping 和 pong 最大有效載荷長度都爲 125)。你可能接收到一個 pong 而不用發送一個 ping。忽略它若是有發生這樣的狀況。

心跳包很是有用。利用服務（好比負載均衡器）來中斷空閒的鏈接。另外，接收端不可能知道服務端是否已經中斷鏈接。只有在發送下一幀的時候，你纔會意識到發生了錯誤。

錯誤處理

你能夠經過監聽 error 事件來處理錯誤。

像這樣：

var socket = new WebSocket('ws://websocket.example.com');

// 處理錯誤
socket.onerror = function(error) {
  console.log('WebSocket Error: ' + error);
};

關閉鏈接

客戶端或服務器能夠發送一個包含 0x8 操做碼數據的控制幀來關閉鏈接。當接收到控制幀的時候，另外一個節點會返回一個關閉幀。以後第一個節點會關閉鏈接。關閉鏈接以後，以後接收的任何數據都會被遺棄。

這是初始化關閉客戶端的 WebSocket 鏈接的代碼：

// 若是鏈接打開着則關閉
if (socket.readyState === WebSocket.OPEN) {
    socket.close();
}

一樣地，爲了在完成關閉鏈接後運行任意的清理工做，你能夠爲 close 事件添加事件監聽函數：

// 運行必要的清理工做
socket.onclose = function(event) {
  console.log('Disconnected from WebSocket.');
};

服務器不得不監聽 close 事件以便在須要的時候處理：

connection.on('close', function(reasonCode, description) {
    // 關閉鏈接
});

WebSockets 和 HTTP/2 對比

雖然 HTTP/2 提供了不少的功能，可是它並不能徹底取代當前的 push/streaming 技術。

關於 HTTP/2 須要注意的最重要的事即它並不能徹底取代 HTTP。詞彙，狀態碼以及大部分的頭部信息都會保持和如今同樣。HTTP/2 只是提高了線路上的數據傳輸效率。

如今，若是咱們對比 WebSocket 和 HTTP/2，將會發現不少相似的地方：

正如以上所顯示的那樣，HTTP/2 引進了 Server Push 技術用來讓服務器主動向客戶端緩存發送數據。然而，它並不容許直接向客戶端程序自己發送數據。服務端推送只能由瀏覽器處理而不可以在程序代碼中進行處理，意即程序代碼沒有 API 能夠用來獲取這些事件的通知。

這時候服務端推送事件（SSE）就派上用場了。SSE 是這樣的機制一旦客戶端－服務器鏈接創建，它容許服務器異步推送數據給客戶端。以後，每當服務器產生新數據的時候，就推送數據給客戶端。這能夠當作是單向的發佈－訂閱模型。它也提供了一個被稱爲 EventSource 的標準 JavaScript 客戶端 API，該 API 做爲 W3C 組織發佈的 HTML5 標準的一部分已經在大多數的現代瀏覽器中實現。請注意不支持原生 EventSource API 的瀏覽器能夠經過墊片實現。

因爲 SSE 是基於 HTTP 的，因此它自然兼容於 HTTP/2 而且能夠混合使用以利用各自的優點： HTTP/2 處理一個基於多路複用流的高效傳輸層而 SSE 爲程序提供了 API 用來支持服務端推送。

爲了徹底理解流和多路複用技術，先讓咱們來了解一下 IETF 的定義：『流』便是在一個 HTTP/2 鏈接中，在客戶端和服務端間進行交換傳輸的一個獨立的雙向幀序列。它的主要特色之一即單個的 HTTP/2 鏈接能夠包含多個併發打開的流，在每一終端交錯傳輸來自多個流的幀。

必須記住的是 SSE 是基於 HTTP 的。這意味着，經過使用 HTTP/2，不只僅能夠把多個 SSE 流交叉合併成單一的 TCP 鏈接，還能夠把多個 SSE 流（服務端向客戶端推送）和多個客戶端請求（客戶端到服務端）合併成單一的 TCP 鏈接。多虧了 HTTP/2 和 SSE，如今咱們有了一個純粹的 HTTP 雙向鏈接，該鏈接帶有一個簡單的 API 容許程序代碼註冊監聽服務端的數據推送。缺少雙向通訊能力一直被認爲是 SSE 對比 WebSocket 的主要缺點。多虧了 HTTP/2，這再也不是缺點。這就讓你有機會堅持使用基於 HTTP 的通訊系統而非 WebSockets。