深刻探索WebSockets

WebSockets簡介

在2008年中期，開發人員Michael Carter和Ian Hickson特別敏銳地感覺到Comet在實施任何真正強大的東西時所帶來的痛苦和侷限。 經過在IRC和W3C郵件列表上的合做，他們制定了一項計劃，在網絡上引入現代實時雙向通訊的新標準，所以創造了「WebSocket」這個名稱。

這個想法進入了W3C HTML草案標準，不久以後，Michael Carter寫了一篇文章，將Comet社區介紹給WebSockets。 2010年，谷歌Chrome 4是第一個提供對WebSockets全面支持的瀏覽器，其餘瀏覽器供應商也在接下來的幾年中採用了這種方式。 2011年，RFC 6455 - WebSocket協議 - 發佈到IETF網站。

今天，全部主流瀏覽器都徹底支持WebSockets，甚至包括Internet Explorer 10和11.此外，自2013年以來，iOS和Android上的瀏覽器都支持WebSockets，這意味着總而言之，WebSocket支持的現代環境很是健康。 大多數「物聯網」或IoT也在某些版本的Android上運行，所以從2018年開始，其餘類型設備上的WebSocket支持也至關廣泛。

那麼究竟什麼是WebSockets呢？

簡而言之，WebSockets是一個構建在設備TCP / IP堆棧之上的傳輸層。 目的是爲Web應用程序開發人員提供本質上儘量接近原始的TCP通訊層，同時添加一些抽象來消除某些差別。 它們還知足了這樣一個事實，即網絡具備額外的安全考慮因素，必須將其考慮在內以保護消費者和服務提供者。

您可能據說WebSockets同時被稱爲「傳輸」和「協議」。前者更準確，由於雖然它們是一種協議，由於必須遵照一套嚴格的規則來創建通訊幷包含所傳輸的數據，但該標準並無對如何構建實際數據有效載荷採起任何規定。事實上，規範的一部分包括客戶端和服務器就一個協議達成一致的規範，傳輸的數據將經過該協議進行格式化和解釋。該標準將這些稱爲「子協議」，以免術語中含糊不清的問題。子協議的示例是JSON，XML，MQTT，WAMP等。這些不只能夠確保數據的結構方式，還能夠確保通訊必須開始，繼續並最終終止的方式。只要雙方都瞭解協議所包含的內容，任何事情都會發生。 WebSocket僅提供傳輸層，經過該傳輸層能夠實現該消息傳遞過程，這就是爲何大多數常見的子協議不是基於WebSocket的通訊所獨有的。

關於身份驗證和受權的快速說明

把WebSockets看做是一個創建在TCP / IP之上的薄層，超出基本握手和消息框架規範的任何東西都須要在每一個應用程序或每一個庫的基礎上處理。 引用RFC：

此協議未規定服務器在WebSocket握手期間能夠對客戶端進行身份驗證的任何特定方式。 WebSocket服務器可使用通用HTTP服務器可用的任何客戶端身份驗證機制，例如cookie，HTTP身份驗證或TLS身份驗證。

簡而言之，您仍然可使用的基於HTTP的身份驗證方法，或使用MQTT或WAMP等子協議，這兩種子協議都提供身份驗證和受權方法。

用HTTP作鏈接

定義WebSocket標準時的一個早期考慮因素是確保它「與網絡」很好地協同工做。 這意味着認識到Web一般使用URL而不是IP地址和端口號進行尋址，而且WebSocket鏈接應該可以使用Web請求相同的基於HTTP的任何其餘類型進行初始握手。

這是一個簡單的HTTP GET請求中發生的事情。

假設在http://www.example.com/index....。 若是不深刻到HTTP協議自己，就足以知道請求必須從所謂的Request-Line開始，而後是一系列鍵值對標題行，每一行都告訴服務器一些關於什麼的信息。 指望在隨後的請求有效負載中跟隨頭數據，以及它能夠從客戶端獲得的關於它可以理解的響應類型的內容。

請求中的第一個令牌是HTTP方法，它告訴服務器客戶端針對引用的URL嘗試的操做類型。 當客戶端僅請求服務器向其提供由指定URL引用的資源的副本時，使用GET方法。

根據HTTP RFC格式化的請求標頭的系統示例以下所示：

GET /index.html HTTP/1.1
Host: www.example.com

收到請求標頭後，服務器而後格式化一個以狀態行開頭的響應標頭，而後是一組鍵值標頭對，爲客戶端提供來自服務器的補充信息，關於服務器的請求。 響應。 「狀態行」告訴客戶端HTTP狀態代碼（若是沒有問題，一般爲200），並提供解釋狀態代碼的簡短「緣由」文本描述。 接下來出現鍵值標題對，而後是請求的實際數據（除非狀態代碼代表因爲某種緣由沒法知足請求）。

HTTP/1.1 200 OK
Date: Wed, 1 Aug 2018 16:03:29 GMT
Content-Length: 291
Content-Type: text/html
(additional headers...)
 
(response payload continues here...)

那麼你可能會問，這與WebSockets有什麼關係呢？

拋棄HTTP以得到更合適的東西

在發出HTTP請求並接收響應時，涉及的實際雙向網絡通訊經過活動的TCP / IP套接字進行。瀏覽器中請求的Web URL經過全局DNS系統映射到IP地址，HTTP請求的默認端口爲80.這意味着雖然Web URL已輸入瀏覽器，但實際通訊是經過TCP進行的/ IP，使用相似於123.11.85.9:80的IP地址和端口組合。

咱們如今知道，WebSockets也創建在TCP堆棧之上，這意味着咱們所須要的只是客戶端和服務器共同贊成保持套接字鏈接打開並從新利用它以進行持續通訊的方式。若是他們這樣作，就能夠發送和接收的二進制數據。

要開始從新調整TCP套接字以進行WebSocket通訊，客戶端能夠包含專門爲此類用例發明的標準請求標頭：

GET /index.html HTTP/1.1
Host: www.example.com
Connection: Upgrade
Upgrade: websocket

Connection標頭告訴服務器客戶端但願協商套接字使用方式的更改。 隨附的值Upgrade表示當前經過TCP使用的傳輸協議應該更改。 如今服務器知道客戶端想要經過活動TCP套接字升級當前正在使用的協議，服務器知道要查找相應的升級頭，這將告訴它客戶端想要使用哪一個傳輸協議的剩餘生命週期 鏈接。 一旦服務器將websocket視爲Upgrade標頭的值，它就知道WebSocket握手過程已經開始。

請注意，若是您想了解本文中介紹的更多詳細信息，請參閱RFC 6455中概述了握手過程（以及其餘全部內容）。

避免有趣的麻煩

除了上面描述的內容以外，WebSocket握手的第一部分涉及證實這其實是一個正確的WebSocket升級握手，而且該過程不是經過客戶端或可能經過某種中間欺騙來規避或模擬的。 位於中間的代理服務器。

啓動升級到WebSocket鏈接時，客戶端必須包含Sec-WebSocket-Key標頭，該標頭具備該客戶端惟一的值。 這是一個例子：

Sec-WebSocket-Key: BOq0IliaPZlnbMHEBYtdjmKIL38=

若是使用現代瀏覽器中提供的WebSocket類，上面的內容將自動處理。 您只需在服務器端查找它並生成響應。

響應時，服務器必須將特殊GUID值258EAFA5-E914-47DA-95CA-C5AB0DC85B11附加到密鑰，生成結果字符串的SHA-1哈希值，而後將其包含爲Sec的base-64編碼值。 它包含在響應中的WebSocket-Accept標頭：

Sec-WebSocket-Accept: 5fXT1W3UfPusBQv/h6c4hnwTJzk=

在Node.js WebSocket服務器中，咱們能夠編寫一個函數來生成這個值，以下所示：

const crypto = require('crypto');
 
function generateAcceptValue (acceptKey) {
  return crypto
    .createHash('sha1')
    .update(acceptKey + '258EAFA5-E914-47DA-95CA-C5AB0DC85B11', 'binary')
    .digest('base64');
}

而後咱們只須要調用這個函數，傳遞Sec-WebSocket-Key頭的值做爲參數，並在發送響應時將函數返回值設置爲Sec-WebSocket-Accept頭的值。

要完成握手，請將適當的HTTP響應頭寫入客戶端套接字。 一個簡單的響應看起來像這樣：

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: m9raz0Lr21hfqAitCxWigVwhppA=

到目前爲止，咱們尚未完成握手 - 還有不少事情要考慮。

子協議 - 統一語言

客戶端和服務器一般須要在給定消息內以及從一個消息到下一個消息的一段時間內，就它們如何格式化，解釋和組織數據自己的兼容策略達成一致。 這就是子協議（前面提到過）的用武之地。若是客戶端知道它能夠處理一個或多個特定的應用程序級協議（例如WAMP，MQTT等），它能夠包含它理解的協議列表。 發出初始HTTP請求。 若是它這樣作，則服務器須要選擇其中一個協議並將其包含在響應頭中，不然將使握手失敗並終止鏈接。

子協議請求標頭示例：

Sec-WebSocket-Protocol: mqtt, wamp

服務器在響應中發出的示例倒數標題：

Sec-WebSocket-Protocol: wamp

請注意，服務器必須從客戶端提供的列表中精確選擇一種協議。選擇多個將意味着服務器沒法可靠或一致地解釋後續WebSocket消息中的數據。例如，若是服務器選擇了json-ld和json-schema。二者都是基於JSON標準構建的數據格式，而且會有許多邊緣狀況，其中一個可能被解釋爲另外一個，從而在處理數據時致使意外錯誤。雖然不能否認自己不是消息傳遞協議，但該示例仍然適用。

當客戶端和服務器都實現爲從一開始就使用通用消息傳遞協議時，能夠在初始請求中省略Sec-WebSocket-Protocol標頭，在這種狀況下服務器能夠忽略此步驟。在實現通用服務，基礎結構和工具時，子協議協商是最有用的，在這些服務，基礎結構和工具中，一旦創建了WebSocket鏈接，就沒法保證客戶端和服務器都能相互理解。

通用協議的標準化名稱應在IANA註冊中心註冊，用於WebSocket子協議名稱，在本文撰寫時，已經註冊了36個名稱，包括soap，xmpp，wamp，mqtt等。儘管註冊表是將子協議名稱映射到其解釋的規範來源，但惟一嚴格的要求是客戶端和服務器就其相互選擇的子協議實際意味着什麼達成一致，不管它是否出如今IANA註冊表中。

請注意，若是客戶端請求使用子協議但未提供服務器能夠支持的任何內容，則服務器必須發送失敗響應並關閉鏈接。

WebSocket擴展

還有一個標題用於定義數據有效負載編碼和成幀方式的擴展，但在本文時，只存在一種標準化擴展類型，它提供了一種WebSocket - 等同於消息中的gzip壓縮。 擴展可能發揮做用的另外一個例子是多路複用 - 使用單個套接字來交錯多個併發通訊流。

WebSocket擴展是一個有點高級的主題，而且超出了本文的範圍。 如今，它足以知道它們是什麼，以及它們如何適應圖片。

客戶端 - 在瀏覽器中使用WebSockets

WebSocket API在WHATWG HTML Living Standard中定義，實際上很是簡單易用。 構造WebSocket須要一行代碼：

const ws = new WebSocket('ws://example.org');

注意使用ws，你一般有http方案。 您也能夠選擇使用wss，一般使用https。 這些協議與WebSocket規範一塊兒引入，旨在表示HTTP鏈接，其中包括升級鏈接以使用WebSockets的請求。

建立WebSocket對象自己並無作不少事情。 鏈接是異步創建的，所以您須要在發送任何消息以前偵聽握手的完成，而且還包括從服務器接收的消息的偵聽器：

ws.addEventListener('open', () => {
  // Send a message to the WebSocket server
  ws.send('Hello!');
});
 
ws.addEventListener('message', event => {
  // The `event` object is a typical DOM event object, and the message data sent
  // by the server is stored in the `data` property
  console.log('Received:', event.data);
});

還有錯誤和關閉事件。 鏈接終止時WebSockets不會自動恢復 - 這是您須要本身實現的，而且是存在許多客戶端庫的緣由之一。 雖然WebSocket類簡單易用，但它實際上只是一個基本的構建塊。 必須單獨實現對不一樣子協議或消息傳遞通道等附加功能的支持。

生成和解析WebSocket消息幀

一旦將握手響應發送到客戶端，客戶端和服務器就可使用他們選擇的子協議（若是有的話）開始通訊。

WebSocket消息在名爲「frames」的包中傳遞，這些包以消息頭開頭，並以「payload」結尾 - 此幀的消息數據。 大型消息可能會將數據分紅幾幀，在這種狀況下，您須要跟蹤到目前爲止收到的內容，並在數據所有到達後將數據分組。

翻譯的很亂，希望對你有點幫助

建立了一個程序員交流微信羣，你們進羣交流IT技術

若是已過時，能夠添加博主微信號15706211347，拉你進羣