如何從零開始定義一個相似websocket的即時通信協議

時間 2019-11-07

標籤如何開始定義一個相似 websocket 即時通信協議简体版

原文原文鏈接

深南大道鎮樓

定義一個本身的通信協議並不難，關鍵在於這個協議的可用性，可拓展性，複雜業務場景的實用性

即時通信應用中，客戶端和服務器端均可以當作一個服務器

一塊兒複習一下`websocket`

WebSocket是一種在單個TCP鏈接上進行全雙工通訊的協議。WebSocket通訊協議於2011年被IETF定爲標準RFC 6455，並由RFC7936補充規範。WebSocket API也被W3C定爲標準。
WebSocket使得客戶端和服務器之間的數據交換變得更加簡單，容許服務端主動向客戶端推送數據,在WebSocket API中，瀏覽器和服務器只須要完成一次握手，二者之間就直接能夠建立持久性的鏈接，並進行雙向數據傳輸。

說說`ws`協議的優勢：

說到優勢，這裏的對比參照物是 HTTP 協議，歸納地說就是：支持雙向通訊，更靈活，更高效，可擴展性更好。
支持雙向通訊，實時性更強。
更好的二進制支持。
較少的控制開銷。鏈接建立後，ws 客戶端、服務端進行數據交換時，協議控制的數據包頭部較小。在不* 包含頭部的狀況下，服務端到客戶端的包頭只有 2~10 字節（取決於數據包長度），客戶端到服務端的的話，須要加上額外的 4 字節的掩碼。而 HTTP 協議每次通訊都須要攜帶完整的頭部。
支持擴展。ws 協議定義了擴展，用戶能夠擴展協議，或者實現自定義的子協議。（好比支持自定義壓縮算法等）

咱們先看看 web socket協議的實現具體過程，再用代碼抽象，定義本身的即時通信協議：

鏈接握手過程node
- 關於WebSocket有一句很常見的話: Websocket複用了HTTP的握手通道, 它具體指的是:
- 客戶端經過HTTP請求與WebSocket服務器協商升級協議, 協議升級完成後, 後續的數據交換則遵守WebSocket協議
- 客戶端: 申請協議升級
- 首先由客戶端換髮起協議升級請求, 根據WebSocket協議規範, 請求頭必須包含以下的內容

GET / HTTP/1.1
    Host: localhost:8080
    Origin: http://127.0.0.1:3000
    Connection: Upgrade
    Upgrade: websocket
    Sec-WebSocket-Version: 13
    Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw

請求頭詳解golang
- 請求行: 請求方法必須是GET, HTTP版本至少是1.1
- 請求必須含有Host
- 若是請求來自瀏覽器客戶端, 必須包含Origin
- 請求必須含有Connection, 其值必須含有"Upgrade"記號
- 請求必須含有Upgrade, 其值必須含有"websocket"關鍵字
- 請求必須含有Sec-Websocket-Version, 其值必須是13
- 請求必須含有Sec-Websocket-Key, 用於提供基本的防禦, 好比無心的鏈接
1.2 服務器: 響應協議升級
服務器返回的響應頭必須包含以下的內容web
- HTTP/1.1 101 Switching Protocols
- Connection:Upgrade
- Upgrade: websocket
- Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=
- 響應行: HTTP/1.1 101 Switching Protocols
- 響應必須含有Upgrade, 其值爲"weboscket"
- 響應必須含有Connection, 其值爲"Upgrade"
- 響應必須含有Sec-Websocket-Accept, 根據請求首部的Sec-Websocket-key計算出來

Sec-WebSocket-Key/Accept的計算

規範提到:
Sec-WebSocket-Key值由一個隨機生成的16字節的隨機數經過base64編碼獲得的
Key能夠避免服務器收到非法的WebSocket鏈接, 好比http請求鏈接到websocket, 此時服務端能夠直接拒絕
Key能夠用來初步確保服務器認識ws協議, 但也不能排除有的http服務器只處理Sec-WebSocket-Key, 並不實現ws協議
Key能夠避免反向代理緩存
在瀏覽器中發起ajax請求, Sec-Websocket-Key以及相關header是被禁止的, 這樣能夠避免客戶端發送ajax請求時, 意外請求協議升級
最終須要強調的是: Sec-WebSocket-Key/Accept並非用來保證數據的安全性, 由於其計算/轉換公式都是公開的, 並且很是簡單, 最主要的做用是預防一些意外的狀況

`WebSocket`通訊的最小單位是幀, 由一個或多個幀組成一條完整的消息, 交換數據的過程當中, 發送端和接收端須要作的事情以下:

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

數據幀格式詳解

FIN: 佔1bit
0表示不是消息的最後一個分片
1表示是消息的最後一個分片

RSV1, RSV2, RSV3: 各佔1bit, 通常狀況下全爲0, 與Websocket拓展有關, 若是出現非零的值且沒有采用WebSocket拓展, 鏈接出錯

Opcode: 佔4bit

%x0: 表示本次數據傳輸採用了數據分片, 當前數據幀爲其中一個數據分片
%x1: 表示這是一個文本幀
%x2: 表示這是一個二進制幀
%x3-7: 保留的操做代碼, 用於後續定義的非控制幀
%x8: 表示鏈接斷開
%x9: 表示這是一個心跳請求(ping)
%xA: 表示這是一個心跳響應(pong)
%xB-F: 保留的操做代碼, 用於後續定義的非控制幀

Mask: 佔1bitajax
- 0表示不對數據載荷進行掩碼異或操做
- 1表示對數據載荷進行掩碼異或操做

Payload length: 佔7或7+16或7+64bit算法
- 0~125: 數據長度等於該值
- 126: 後續的2個字節表明一個16位的無符號整數, 值爲數據的長度
- 127: 後續的8個字節表明一個64位的無符號整數, 值爲數據的長度
Masking-key: 佔0或4bytes數據庫
- 1: 攜帶了4字節的Masking-key
- 0: 沒有Masking-key
- 掩碼的做用並非防止數據泄密,而是爲了防止早期版本協議中存在的代理緩存污染攻擊等問題
payload data: 載荷數據
數據傳遞後端
- WebSocket的每條消息可能被切分紅多個數據幀, 當接收到一個數據幀時,會根據FIN值來判斷, 是否爲最後一個數據幀
- 數據幀傳遞示例:
- FIN=0, Opcode=0x1: 發送文本類型, 消息尚未發送完成,還有後續幀
- FIN=0, Opcode=0x0: 消息沒有發送完成, 還有後續幀, 接在上一條後面
- FIN=1, Opcode=0x0: 消息發送完成, 沒有後續幀, 接在上一條後面組成完整消息

正式開始定義屬於咱們本身的通信協議：

咱們爲何要自定義TCP應用層傳輸協議？
針對特定的用戶羣體，實現通信信息的真正加密，複雜場景下更靈活的通訊
由於在TCP流傳輸的過程當中，可能會出現分包與黏包的現象。咱們爲了解決這些問題，須要咱們自定義通訊協議進行封包與解包。
什麼是分包與黏包？
分包：指接受方沒有接受到一個完整的包，只接受了部分。
黏包：指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩衝區看，後一包數據的頭緊接着前一包數據的尾。
PS:由於TCP是面向字節流的，是沒有邊界的概念的，嚴格意義上來講，是沒有分包和黏包的概念的，可是爲了更好理解，也更好來描述現象，我在這裏就接着採用這兩個名詞來解釋現象了。我以爲你們知道這個概念就好了，沒必要細扣，能解決問題就行。
產生分包與黏包現象的緣由是什麼？
產生分包緣由：
多是IP分片傳輸致使的，也多是傳輸過程當中丟失部分包致使出現的半包，還有可能就是一個包可能被分紅了兩次傳輸，在取數據的時候，先取到了一部分（還可能與接收的緩衝區大小有關係），總之就是一個數據包被分紅了屢次接收。
產生黏包的緣由：
因爲TCP協議自己的機制（面向鏈接的可靠地協議-三次握手機制）客戶端與服務器會維持一個鏈接（Channel），數據在鏈接不斷開的狀況下，能夠持續不斷地將多個數據包發往服務器，可是若是發送的網絡數據包過小，那麼他自己會啓用Nagle算法（可配置是否啓用）對較小的數據包進行合併（基於此，TCP的網絡延遲要UDP的高些）而後再發送（超時或者包大小足夠）。那麼這樣的話，服務器在接收到消息（數據流）的時候就沒法區分哪些數據包是客戶端本身分開發送的，這樣產生了粘包；服務器在接收到數據後，放到緩衝區中，若是消息沒有被及時從緩存區取走，下次在取數據的時候可能就會出現一次取出多個數據包的狀況，形成粘包現象
什麼是封包與解包？
TCP/IP 網絡數據以流的方式傳輸，數據流是由包組成，如何斷定接收方收到的包是不是一個完整的包就要在發送時對包進行處理，這就是封包技術，將包處理成包頭，包體。

包頭是包的開始標記，整個包的大小就是包的結束標。api

如何自定義協議？
發送時數據包是由包頭+數據組成的：其中包頭內容分爲包類型+包長度。
接收時，只須要先保證將數據包的包頭讀完整，經過收到的數據包包頭裏的數據長度和數據包類型，判斷出咱們將要收到一個帶有什麼樣類型的多少長度的數據。而後循環接收直到接收的數據大小等於數據長度中止，此時咱們完成接收一個完整數據包。

用代碼書寫一個常見的解密後的包：

{
header:{
cmdid:oxa212,
msgid:xxxxxx,
sessionid:xxxx
....
},
body:{
sessiontype:1,
datalength:100,
formid:xxx,
told:xxxx,
msgid:xxxxxxx，
content:'dear'
}
}

今天爲了下降難度，沒有使用prob格式傳輸哦。
固然還有心跳的發包和回包，與上面相似，只是內容不一致。

今天只書寫客戶端 node.js的部分代碼，服務端的代碼，打算後期使用 golang書寫。

上面說到了，WebSocket通訊的最小單位是幀, 由一個或多個幀組成一條完整的消息, 交換數據的過程當中, 發送端和接收端須要作的事情以下:
發送端: 將消息切割成多個幀, 併發送給服務端
接收端: 接受消息幀, 並將關聯的幀從新組裝成完整的消息
出現黏包和分包的問題，通俗易懂的說就是，建立buffer緩衝區，把二進制的數據一點一點點切出來，而後變成特定的js對象使用。

第一步先與服務端創建`tcp`連接

const {Socket} = require('net') 
const tcp = new Socket()
tcp.setKeepAlive(true);
tcp.setNoDelay(true);
//保持底層tcp連接不斷，長鏈接

第二步，指定對應域名端口號連接

tcp.connect(80,142.122.0.0)

第三步創建成功連接後發送心跳包，而且服務端回覆心跳包

每一個人定製的心跳發包回包都不同，具體格式能夠參考上面，自行定製心跳包的內容和檢測時間，多長時間檢測不到心跳的處理機制。

第四步，收到服務端數據，拆包，根據不一樣的數據類型給予不一樣的處理機制，決定哪些渲染到頁面上，哪些放入數據庫，作持久性存儲等。

這裏寫一點拆包代碼

根據後端傳送的數據類型 使用對應不一樣的解析
readUInt8 readUInt16LE readUInt32LE readIntLE等處理後獲得myBuf 

const myBuf = buffer.slice(start);//從對應的指針開始的位置截取buffer
const header = myBuf.slice(headstart,headend)//截取對應的頭部buffer
const body = JSON.parse(myBuf.slice(headend-headstart,bodylength).tostring()) 
//精確截取body的buffer,而且轉化成js對象

怎麼拆包，長度是多少，要看你們各自的定義方式，參考 websocket的定義格式：

`Node.js`目前支持的字符編碼包括：

ascii - 僅支持 7 位 ASCII 數據。若是設置去掉高位的話，這種編碼是很是快的。
utf8 - 多字節編碼的 Unicode 字符。許多網頁和其餘文檔格式都使用 UTF-8 。
utf16le - 2 或 4 個字節，小字節序編碼的 Unicode 字符。支持代理對（U+10000 至 U+10FFFF）。
ucs2 - utf16le 的別名。
base64 - Base64 編碼。
latin1 - 一種把 Buffer 編碼成一字節編碼的字符串的方式。
binary - latin1 的別名。
hex - 將每一個字節編碼爲兩個十六進制字符。

組包

建立 Buffer 類瀏覽器
- Buffer 提供瞭如下 API 來建立 Buffer 類：
- Buffer.alloc(size[, fill[, encoding]])：返回一個指定大小的 Buffer 實例，若是沒有設置 fill，則默認填滿 0
- Buffer.allocUnsafe(size)：返回一個指定大小的 Buffer 實例，可是它不會被初始化，因此它可能包含敏感的數據
- Buffer.allocUnsafeSlow(size)
- Buffer.from(array)：返回一個被 array 的值初始化的新的 Buffer 實例（傳入的 array 的元素只能是數字，否則就會自動被 0 覆蓋）
- Buffer.from(arrayBuffer[, byteOffset[, length]])：返回一個新建的與給定的 ArrayBuffer 共享同一內存的 Buffer。
- Buffer.from(buffer)：複製傳入的 Buffer 實例的數據，並返回一個新的 Buffer 實例
- Buffer.from(string[, encoding])：返回一個被 string 的值初始化的新的 Buffer 實例

所謂組包，就是把對應的 js對象，變成二進制數據，而後推送給服務端

這裏寫一個簡單的組包

const obj = {
        header:{
            datalength:123,
            sessiontype:1,
            cmdid:xxx,},
         body:{
            content:"hello",
            sessionid:xxx,
            fromid:xxx,
            toid:xxx
                }
            }
    將上面的js對象轉化成buf後，推送給服務端 
    tcp.write(buf,cb)
    
    cb是一個異步回掉，當數據推送完後纔會調用。

下面給出經常使用的`buffer`操做`api`

方法參考手冊
如下列出了 Node.js Buffer 模塊經常使用的方法（注意有些方法在舊版本是沒有的）：
序號方法 & 描述
1 new Buffer(size)緩存
- 分配一個新的 size 大小單位爲8位字節的 buffer。注意, size 必須小於 kMaxLength，不然，將會拋出異常 RangeError。廢棄的: 使用 Buffer.alloc() 代替（或 Buffer.allocUnsafe()）。
2 new Buffer(buffer)
- 拷貝參數 buffer 的數據到 Buffer 實例。廢棄的: 使用 Buffer.from(buffer) 代替。
3 new Buffer(str[, encoding])

分配一個新的 buffer ，其中包含着傳入的 str 字符串。 encoding 編碼方式默認爲 'utf8'。廢棄的: 使用 Buffer.from(string[, encoding]) 代替。

4 buf.length
- 返回這個 buffer 的 bytes 數。注意這未必是 buffer 裏面內容的大小。length 是 buffer 對象所分配的內存數，它不會隨着這個 buffer 對象內容的改變而改變。
5 buf.write(string[, offset[, length]][, encoding])
- 根據參數 offset 偏移量和指定的 encoding 編碼方式，將參數 string 數據寫入buffer。 offset 偏移量默認值是 0, encoding 編碼方式默認是 utf8。 length 長度是將要寫入的字符串的 bytes 大小。返回 number 類型，表示寫入了多少 8 位字節流。若是 buffer 沒有足夠的空間來放整個 string，它將只會只寫入部分字符串。 length 默認是 buffer.length - offset。這個方法不會出現寫入部分字符。
6 buf.writeUIntLE(value, offset, byteLength[, noAssert])

將 value 寫入到 buffer 裏，它由 offset 和 byteLength 決定，最高支持 48 位無符號整數，小端對齊，例如：

const buf = Buffer.allocUnsafe(6);

buf.writeUIntLE(0x1234567890ab, 0, 6);

// 輸出: <Buffer ab 90 78 56 34 12>
console.log(buf);
noAssert 值爲 true 時，再也不驗證 value 和 offset 的有效性。 默認是 false。

7 buf.writeUIntBE(value, offset, byteLength[, noAssert])
- 將 value 寫入到 buffer 裏，它由 offset 和 byteLength 決定，最高支持 48 位無符號整數，大端對齊。noAssert 值爲 true 時，再也不驗證 value 和 offset 的有效性。默認是 false。

const buf = Buffer.allocUnsafe(6);

buf.writeUIntBE(0x1234567890ab, 0, 6);

// 輸出: <Buffer 12 34 56 78 90 ab>
console.log(buf);

8 buf.writeIntLE(value, offset, byteLength[, noAssert])
- 將value 寫入到 buffer 裏，它由offset 和 byteLength 決定，最高支持48位有符號整數，小端對齊。noAssert 值爲 true 時，再也不驗證 value 和 offset 的有效性。默認是 false。
9 buf.writeIntBE(value, offset, byteLength[, noAssert])
- 將value 寫入到 buffer 裏，它由offset 和 byteLength 決定，最高支持48位有符號整數，大端對齊。noAssert 值爲 true 時，再也不驗證 value 和 offset 的有效性。默認是 false。
10 buf.readUIntLE(offset, byteLength[, noAssert])
- 支持讀取 48 位如下的無符號數字，小端對齊。noAssert 值爲 true 時， offset 再也不驗證是否超過 buffer 的長度，默認爲 false。
11 buf.readUIntBE(offset, byteLength[, noAssert])
- 支持讀取 48 位如下的無符號數字，大端對齊。noAssert 值爲 true 時， offset 再也不驗證是否超過 buffer 的長度，默認爲 false。
12 buf.readIntLE(offset, byteLength[, noAssert])
- 支持讀取 48 位如下的有符號數字，小端對齊。noAssert 值爲 true 時， offset 再也不驗證是否超過 buffer 的長度，默認爲 false。
13 buf.readIntBE(offset, byteLength[, noAssert])
- 支持讀取 48 位如下的有符號數字，大端對齊。noAssert 值爲 true 時， offset 再也不驗證是否超過 buffer 的長度，默認爲 false。
14 buf.toString([encoding[, start[, end]]])
- 根據 encoding 參數（默認是 'utf8'）返回一個解碼過的 string 類型。還會根據傳入的參數 start (默認是 0) 和 end (默認是 buffer.length)做爲取值範圍。
15 buf.toJSON()
- 將 Buffer 實例轉換爲 JSON 對象。
16 buf[index]
- 獲取或設置指定的字節。返回值表明一個字節，因此返回值的合法範圍是十六進制0x00到0xFF 或者十進制0至 255。
17 buf.equals(otherBuffer)
- 比較兩個緩衝區是否相等，若是是返回 true，不然返回 false。
18 buf.compare(otherBuffer)
- 比較兩個 Buffer 對象，返回一個數字，表示 buf 在 otherBuffer 以前，以後或相同。
19 buf.copy(targetBuffer[, targetStart[, sourceStart[, sourceEnd]]])
- buffer 拷貝，源和目標能夠相同。 targetStart 目標開始偏移和 sourceStart 源開始偏移默認都是 0。 sourceEnd 源結束位置偏移默認是源的長度 buffer.length 。
20 buf.slice([start[, end]])
- 剪切 Buffer 對象，根據 start(默認是 0 ) 和 end (默認是 buffer.length ) 偏移和裁剪了索引。負的索引是從 buffer 尾部開始計算的。
21 buf.readUInt8(offset[, noAssert])
- 根據指定的偏移量，讀取一個無符號 8 位整數。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。若是這樣 offset 可能會超出buffer 的末尾。默認是 false。
22 buf.readUInt16LE(offset[, noAssert])
- 根據指定的偏移量，使用特殊的 endian 字節序格式讀取一個無符號 16 位整數。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出 buffer 的末尾。默認是 false。
23 buf.readUInt16BE(offset[, noAssert])
- 根據指定的偏移量，使用特殊的 endian 字節序格式讀取一個無符號 16 位整數，大端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出 buffer 的末尾。默認是 false。
24 buf.readUInt32LE(offset[, noAssert])
- 根據指定的偏移量，使用指定的 endian 字節序格式讀取一個無符號 32 位整數，小端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出buffer 的末尾。默認是 false。
25 buf.readUInt32BE(offset[, noAssert])
- 根據指定的偏移量，使用指定的 endian 字節序格式讀取一個無符號 32 位整數，大端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出buffer 的末尾。默認是 false。
26 buf.readInt8(offset[, noAssert])
- 根據指定的偏移量，讀取一個有符號 8 位整數。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出 buffer 的末尾。默認是 false。
27 buf.readInt16LE(offset[, noAssert])
- 根據指定的偏移量，使用特殊的 endian 格式讀取一個有符號 16 位整數，小端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出 buffer 的末尾。默認是 false。
28 buf.readInt16BE(offset[, noAssert])

根據指定的偏移量，使用特殊的 endian 格式讀取一個有符號 16 位整數，大端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出 buffer 的末尾。默認是 false。

29 buf.readInt32LE(offset[, noAssert])
- 根據指定的偏移量，使用指定的 endian 字節序格式讀取一個有符號 32 位整數，小端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出buffer 的末尾。默認是 false。
30 buf.readInt32BE(offset[, noAssert])
- 根據指定的偏移量，使用指定的 endian 字節序格式讀取一個有符號 32 位整數，大端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出buffer 的末尾。默認是 false。
31 buf.readFloatLE(offset[, noAssert])
- 根據指定的偏移量，使用指定的 endian 字節序格式讀取一個 32 位雙浮點數，小端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出buffer的末尾。默認是 false。
32 buf.readFloatBE(offset[, noAssert])
- 根據指定的偏移量，使用指定的 endian 字節序格式讀取一個 32 位雙浮點數，大端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出buffer的末尾。默認是 false。
33 buf.readDoubleLE(offset[, noAssert])
- 根據指定的偏移量，使用指定的 endian字節序格式讀取一個 64 位雙精度數，小端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出buffer 的末尾。默認是 false。
34 buf.readDoubleBE(offset[, noAssert])
- 根據指定的偏移量，使用指定的 endian字節序格式讀取一個 64 位雙精度數，大端對齊。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 offset 可能會超出buffer 的末尾。默認是 false。
35 buf.writeUInt8(value, offset[, noAssert])
- 根據傳入的 offset 偏移量將 value 寫入 buffer。注意：value 必須是一個合法的無符號 8 位整數。若參數 noAssert 爲 true 將不會驗證 offset 偏移量參數。這意味着 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然不要使用。默認是 false。
36 buf.writeUInt16LE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的無符號 16 位整數，小端對齊。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value 可能過大，或者 offset 可能會超出buffer的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false。
37 buf.writeUInt16BE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的無符號 16 位整數，大端對齊。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value 可能過大，或者 offset 可能會超出buffer的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false。
38 buf.writeUInt32LE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式(LITTLE-ENDIAN:小字節序)將 value 寫入buffer。注意：value 必須是一個合法的無符號 32 位整數，小端對齊。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着value 可能過大，或者offset可能會超出buffer的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false。
39 buf.writeUInt32BE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式(Big-Endian:大字節序)將 value 寫入buffer。注意：value 必須是一個合法的有符號 32 位整數。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value 可能過大，或者offset可能會超出buffer的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false。
40 buf.writeInt8(value, offset[, noAssert])
41 buf.writeInt16LE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的 signed 16 位整數。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false 。
42 buf.writeInt16BE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的 signed 16 位整數。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false 。
43 buf.writeInt32LE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的 signed 32 位整數。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false。
44 buf.writeInt32BE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的 signed 32 位整數。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false。
45 buf.writeFloatLE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer 。注意：當 value 不是一個 32 位浮點數類型的值時，結果將是不肯定的。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value可能過大，或者 offset 可能會超出 buffer 的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false。
46 buf.writeFloatBE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer 。注意：當 value 不是一個 32 位浮點數類型的值時，結果將是不肯定的。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value可能過大，或者 offset 可能會超出 buffer 的末尾從而形成 value 被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false。
47 buf.writeDoubleLE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個有效的 64 位double 類型的值。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而形成value被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false。
48 buf.writeDoubleBE(value, offset[, noAssert])
- 根據傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個有效的 64 位double 類型的值。若參數 noAssert 爲 true 將不會驗證 value 和 offset 偏移量參數。這意味着 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而形成value被丟棄。除非你對這個參數很是有把握，不然儘可能不要使用。默認是 false。
49 buf.fill(value, offset)
- 使用指定的 value 來填充這個 buffer。若是沒有指定 offset (默認是 0) 而且 end (默認是 buffer.length) ，將會填充整個buffer。

最後的總結：

實時通信，特別是三端加密和消息同步這塊，是很是複雜的，本人大概只寫到了10分之1
組包和拆包，具體要根據你特定的業務場景還有公司定製的協議去具體操做，這裏只是一個大概闡述
後臺的代碼之後我會盡力用golang和node.js各寫一份。
海量高併發場景，機房部署，總體架構這裏都沒有寫，由於確實太多了，一旦併發量上來了，不管先後端要作的事情都很是多
有幸公司昨天在深圳萬象城請到了Bilibili的架構師毛劍先生給咱們培訓，他讓我對後端的認識又深入了很多，特別是IM總體架構和優化這塊，之後總結好了，也會給你們分享
若是有寫得不對的地方，請指出，謝謝。
加解密的過程沒有寫上來，這塊也是很是核心。