socket.io 原理詳解

在上一篇文章中，咱們瞭解到 socket.io 是 基於engine.io 進行封裝的庫。 因此對engine.io不清楚的童鞋能夠點擊進行了解: engine.io 詳解

1.概述

---

socket.io 是基於 Websocket 的Client-Server 實時通訊庫。 socket.io 底層使用engine.io 封裝了一層協議。

二者的依賴關係可參考: package.json

2. WebSocket 簡介

---

Websocket 定義 參考規範 rfc6455

規範解釋 Websocket 是一種提供客戶端(提供不可靠祕鑰)與服務端(校驗經過該祕鑰)進行雙向通訊的協議。

在沒有websocket協議以前，要提供客戶端與服務端實時雙向推送消息，就會使用polling技術，客戶端經過xhr或jsonp 發送消息給服務端，並經過事件回調來接收服務端消息。

這種技術雖然也能保證雙向通訊，可是有一個不可避免的問題，就是性能問題。客戶端不斷向服務端發送請求，若是客戶端併發數過大，無疑致使服務端壓力劇增。所以，websocket就是解決這一痛點而誕生的。

這裏再延伸一些名詞:

• 長輪詢 客戶端向服務端發送xhr請求,服務端接收並hold該請求，直到有新消息push到客戶端，纔會主動斷開該鏈接。而後，客戶端處理該response後再向服務端發起新的請求。以此類推。

HTTP1.1默認使用長鏈接，使用長鏈接的HTTP協議，會在響應頭中加入下面這行信息: Connection:keep-alive

• 短輪詢:

客戶端不論是否收到服務端的response數據，都會定時想服務端發送請求，查詢是否有數據更新。

• 長鏈接 指在一個TCP鏈接上能夠發送多個數據包，在TCP鏈接保持期間，若是沒有數據包發送，則雙方就須要發送心跳包來維持此鏈接。

鏈接過程: 創建鏈接——數據傳輸——...——(發送心跳包，維持鏈接)——...——數據傳輸——關閉鏈接

• 短鏈接 指通訊雙方有數據交互時，創建一個TCP鏈接，數據發送完成以後，則斷開此鏈接。

鏈接過程: 創建鏈接——數據傳輸——斷開鏈接——...——創建鏈接——數據傳輸——斷開鏈接

Tips

這裏有一個誤解，長鏈接和短鏈接的概念本質上指的是傳輸層的TCP鏈接，由於HTTP1.1協議之後，鏈接默認都是長鏈接。沒有短鏈接說法(HTTP1.0默認使用短鏈接)，網上大多數指的長短鏈接實質上說的就是TCP鏈接。 http使用長鏈接的好處: 當咱們請求一個網頁資源的時候，會帶有不少js、css等資源文件，若是使用的時短鏈接的話，就會打開不少tcp鏈接，若是客戶端請求數過大，致使tcp鏈接數量過多，對服務端形成壓力也就可想而知了。

• 單工 數據傳輸的方向惟一，只能由發送方向接收方的單一固定方向傳輸數據。
• 半雙工 即通訊雙方既是接收方也是發送方，不過，在某一時刻只能容許向一個方向傳輸數據。
• 全雙工: 即通訊雙方既是接收方也是發送方，兩端設備能夠同時發送和接收數據。

Tips

單工、半雙工和全雙工 這三者都是創建在 TCP協議(傳輸層上)的概念，不要與應用層進行混淆。

3. 什麼是Websocket

---

Websocket 協議也是基於TCP協議的，是一種雙全工通訊技術、複用HTTP握手通道。

Websocket默認使用請求協議爲:ws://,默認端口:80。對TLS加密請求協議爲:wss://，端口:443。

3.1 特色

• 支持瀏覽器/Nodejs環境
• 支持雙向通訊
• API簡單易用
• 支持二進制傳輸
• 減小傳輸數據量

3.2 創建鏈接過程

Websocket複用了HTTP的握手通道。指的是，客戶端發送HTTP請求，並在請求頭中帶上Connection: Upgrade 、Upgrade: websocket，服務端識別該header以後，進行協議升級，使用Websocket協議進行數據通訊。

參數說明

• Request URL 請求服務端地址
• Request Method 請求方式 (支持get/post/option)
• Status Code 101 Switching Protocols

RFC 7231 規範定義

規範解釋: 當收到101請求狀態碼時，代表服務端理解並贊成客戶端請求，更改Upgrade header字段。服務端也必須在response中，生成對應的Upgrade值。

• Connection 設置upgrade header,通知服務端，該request類型須要進行升級爲websocket。 upgrade_mechanism 規範

• Host 服務端 hostname

• Origin 客戶端 hostname:port

• Sec-WebSocket-Extensions 客戶端向服務端發起請求擴展列表(list)，供服務端選擇並在響應中返回

• Sec-WebSocket-Key 祕鑰的值是經過規範中定義的算法進行計算得出，所以是不安全的，可是能夠阻止一些誤操做的websocket請求。

• Sec-WebSocket-Accept 計算公式: 1. 獲取客戶端請求header的值: Sec-WebSocket-Key 2. 使用魔數magic = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11' 3. 經過SHA1進行加密計算, sha1(Sec-WebSocket-Key + magic) 4. 將值轉換爲base64

• Sec-WebSocket-Protocol 指定有限使用的Websocket協議，能夠是一個協議列表(list)。服務端在response中返回列表中支持的第一個值。

• Sec-WebSocket-Version 指定通訊時使用的Websocket協議版本。最新版本:13,歷史版本

• Upgrade 通知服務端，指定升級協議類型爲websocket

3.3 數據幀格式

數據格式定義參考：規範 RFC6455

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 bit 若是該位值爲1，表示這是message的最終片斷(fragment)，若是爲0，表示這是一個message的第一個片斷。
• RSV1, RSV2, RSV3: 各佔1 bit 通常默認值是0，除非協商擴展，爲非零值進行定義，不然收到非零值，而且沒有進行協商擴展定義，則websocket鏈接失敗。
• Opcode: 4 bits 根據操做碼(Opcode),解析有效載荷數據(Payload data).若是接受到未定義操做碼，則應該斷開websocket鏈接。
• Mask: 1 bit 定義是否須要的載荷數據(``Payload data)，進行掩碼操做。若是設置值爲1，那麼在Masking-key中會定義一個掩碼key,並用這個key對載荷數據進行反掩碼(unmask)操做。全部從客戶端發送到服務端的數據幀(frame),mask都被設置爲1.
• Payload length: 7 bits, 7+16 bits, or 7+64 bits 載荷數據的長度。
• Masking-key: 0 or 4 bytes 全部從客戶端傳送到服務端的數據幀，數據載荷都進行了掩碼操做，Mask爲1，且攜帶了4字節的Masking-key。若是Mask爲0，則沒有Masking-key。
• Payload data: (x+y) bytes

3.4 心跳檢測

爲了確保客戶端與服務端的長鏈接正常，有時即便客戶端鏈接中斷，可是服務端未觸發onclose事件，這就有可能致使無效鏈接佔用。因此須要一種機制，確保兩端的鏈接處於正常狀態，心跳檢測就是這種機制。客戶端每隔一段時間，會向服務端發送心跳(數據包)，服務端也會返回response進行反饋鏈接正常。

4. socket.io 簡介

---

socket.io與engine.io的一大區別在於，socket.io並不直接提供鏈接功能，而是在engine.io層提供。

socket.io提供了一個房間(Namespace)概念。當客戶端建立一個新的長鏈接時，就會分配一個新的Namespace進行區分。

根據流程圖，能夠看出:

• 建立長鏈接的方式有三種: websocket、xhr、jsonp。其中，後兩種使用長輪詢的方式進行模擬。
• 所謂的長輪詢是指，客戶端發送一次request，當服務端有消息推送時會push一條response給客戶端。客戶端收到response後，會再次發送request，重複上述過程，直到其中一端主動斷開鏈接爲止。

// lookup 源碼
var parsed = url(uri)
var source = parsed.source
var id = parsed.id
var path = parsed.path
// 查找相同房間
var sameNamespace = cache[id] && path in cache[id].nsps
// 若是房間號已存在，建立新鏈接
var newConnection = sameNamespace
// ...
複製代碼

socket.io也提供支持多路複用(built-in multiplexing)方式，這代表每個數據包(Packet)都始終屬於給定的namespace，並有path進行標識(例如: /xxxx)

socket.io能夠在 open 以前，emit 消息，而且該消息會在 open 以後發出。而engine.io必須等到open 以後，才能 send消息。

socket.io也支持斷網重連(reconnection)功能。

5. socket.io 工做流程

當使用socket.io建立一個長鏈接時，到底發生了什麼呢?下面咱們就來進入本文的正體:

const socket = io('http://localhost', {
  path: '/myownpath'
});
複製代碼

首先，socket.io經過一個http請求,而且該請求頭中帶有升級協議(Connection:Upgrade、Upgrade:websocket)等信息，告訴服務端準備創建鏈接，此時，後端返回的response數據。 數據格式以下:

0{"sid":"ab4507c4-d947-4deb-92e4-8a9e34a9f0b2","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":60000}
複製代碼

• 0: 表明open標識
• sid: session id
• upgrades: 升級協議類型
• pingInterval： ping的間隔時長
• pingTimeout： 判斷鏈接超時時長

當客戶端收到響應以後，scoket.io會根據當前客戶端環境是否支持Websocket。若是支持，則創建一個websocket鏈接，不然使用polling(xhr、jsonp)長輪詢進行雙向數據通訊。

6. socket.io 協議解析

socket.io協議中定義的數據格式稱之爲Pakcet ，每個Packet都含有nsp的對象值。

Packet

編碼包能夠是UTF8或二進制數據，編碼格式以下:

<包類型id>[<data>]

例如:

2probe

包類型id(packet type id)是一個整型，具體含義以下:

• 0 open 當打開一個新傳輸時，服務端檢測併發送
• 1 close 請求關閉傳輸，但不是主動斷開鏈接
• 2 ping 客戶端發出，服務端應該返回包含相同數據的pong packet進行應答
• 3 pong 服務端發出，用以響應客戶端的ping packet
• 4 message 真實數據，客戶端和服務端應該調用回調中的data

// 服務端發送 
send('4HelloWorld')
// 客戶端接收數據並調用回調 
socket.on('message', function (data) { console.log(data); });
// 客戶端發送 
send('4HelloWorld')
// 服務端接收數據並調用回調 
socket.on('message', function (data) { console.log(data); })
複製代碼

• 5 upgrade 在engine.io切換傳輸以前，它會測試服務器和客戶端是否能夠經過此傳輸進行通訊。若是此測試成功，客戶端將發送升級數據包，請求服務器刷新舊傳輸上的緩存並切換到新傳輸。
• 6 noop noop packet。主要用於在收到傳入的websocket鏈接時強制輪詢週期。
  1. 客戶端經過新的傳輸鏈接
  2. 客戶端發送 2send
  3. 服務端接收併發送 3probe
  4. 客戶端結束併發送 5
  5. 服務端刷新並關閉舊的傳輸鏈接並切換到新傳輸鏈接

7. socket.io 全家桶

---

區別

• engine.io-parser engine.io協議編碼的js解析器。engine.io 協議規範

• socket.io

• socket.io-client

• socket.io-parser

• socket.io-adapter

• socket.io-redis

• engine.io

• engine.io-client