摘要：通信協(xié)議于年被定為標準，并由補充規(guī)范。連接創(chuàng)建后，客戶端服務端進行數(shù)據(jù)交換時，協(xié)議控制的數(shù)據(jù)包頭部較小。包頭是包的開始標記，整個包的大小就是包的結束標。如何自定義協(xié)議發(fā)送時數(shù)據(jù)包是由包頭數(shù)據(jù)組成的其中包頭內容分為包類型包長度。

深南大道鎮(zhèn)樓

即時通訊應用中，客戶端和服務器端都可以看成一個服務器

WebSocket是一種在單個TCP連接上進行全雙工通信的協(xié)議。WebSocket通信協(xié)議于2011年被IETF定為標準RFC 6455，并由RFC7936補充規(guī)范。WebSocket API也被W3C定為標準。

WebSocket使得客戶端和服務器之間的數(shù)據(jù)交換變得更加簡單，允許服務端主動向客戶端推送數(shù)據(jù),在WebSocket API中，瀏覽器和服務器只需要完成一次握手，兩者之間就直接可以創(chuàng)建持久性的連接，并進行雙向數(shù)據(jù)傳輸。

說到優(yōu)點，這里的對比參照物是 HTTP 協(xié)議，概括地說就是：支持雙向通信，更靈活，更高效，可擴展性更好。

支持雙向通信，實時性更強。

更好的二進制支持。

較少的控制開銷。連接創(chuàng)建后，ws 客戶端、服務端進行數(shù)據(jù)交換時，協(xié)議控制的數(shù)據(jù)包頭部較小。在不* 包含頭部的情況下，服務端到客戶端的包頭只有 2~10 字節(jié)（取決于數(shù)據(jù)包長度），客戶端到服務端的的話，需要加上額外的 4 字節(jié)的掩碼。而 HTTP 協(xié)議每次通信都需要攜帶完整的頭部。

支持擴展。ws 協(xié)議定義了擴展，用戶可以擴展協(xié)議，或者實現(xiàn)自定義的子協(xié)議。（比如支持自定義壓縮算法等）

我們先看看web socket協(xié)議的實現(xiàn)具體過程，再用代碼抽象，定義自己的即時通訊協(xié)議：

連接握手過程

關于WebSocket有一句很常見的話: Websocket復用了HTTP的握手通道, 它具體指的是:

客戶端通過HTTP請求與WebSocket服務器協(xié)商升級協(xié)議, 協(xié)議升級完成后, 后續(xù)的數(shù)據(jù)交換則遵照WebSocket協(xié)議

客戶端: 申請協(xié)議升級

首先由客戶端換發(fā)起協(xié)議升級請求, 根據(jù)WebSocket協(xié)議規(guī)范, 請求頭必須包含如下的內容

    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

請求頭詳解

請求行: 請求方法必須是GET, HTTP版本至少是1.1

請求必須含有Host

如果請求來自瀏覽器客戶端, 必須包含Origin

請求必須含有Connection, 其值必須含有"Upgrade"記號

請求必須含有Upgrade, 其值必須含有"websocket"關鍵字

請求必須含有Sec-Websocket-Version, 其值必須是13

請求必須含有Sec-Websocket-Key, 用于提供基本的防護, 比如無意的連接

1.2 服務器: 響應協(xié)議升級

服務器返回的響應頭必須包含如下的內容

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, 根據(jù)請求首部的Sec-Websocket-key計算出來

規(guī)范提到:

Sec-WebSocket-Key值由一個隨機生成的16字節(jié)的隨機數(shù)通過base64編碼得到的

Key可以避免服務器收到非法的WebSocket連接, 比如http請求連接到websocket, 此時服務端可以直接拒絕

Key可以用來初步確保服務器認識ws協(xié)議, 但也不能排除有的http服務器只處理Sec-WebSocket-Key, 并不實現(xiàn)ws協(xié)議

Key可以避免反向代理緩存

在瀏覽器中發(fā)起ajax請求, Sec-Websocket-Key以及相關header是被禁止的, 這樣可以避免客戶端發(fā)送ajax請求時, 意外請求協(xié)議升級

最終需要強調的是: Sec-WebSocket-Key/Accept并不是用來保證數(shù)據(jù)的安全性, 因為其計算/轉換公式都是公開的, 而且非常簡單, 最主要的作用是預防一些意外的情況

發(fā)送端: 將消息切割成多個幀, 并發(fā)送給服務端

接收端: 接受消息幀, 并將關聯(lián)的幀重新組裝成完整的消息

FIN: 占1bit

0表示不是消息的最后一個分片

1表示是消息的最后一個分片

RSV1, RSV2, RSV3: 各占1bit, 一般情況下全為0, 與Websocket拓展有關, 如果出現(xiàn)非零的值且沒有采用WebSocket拓展, 連接出錯

Opcode: 占4bit

%x0: 表示本次數(shù)據(jù)傳輸采用了數(shù)據(jù)分片, 當前數(shù)據(jù)幀為其中一個數(shù)據(jù)分片
%x1: 表示這是一個文本幀
%x2: 表示這是一個二進制幀
%x3-7: 保留的操作代碼, 用于后續(xù)定義的非控制幀
%x8: 表示連接斷開
%x9: 表示這是一個心跳請求(ping)
%xA: 表示這是一個心跳響應(pong)
%xB-F: 保留的操作代碼, 用于后續(xù)定義的非控制幀

Mask: 占1bit

0表示不對數(shù)據(jù)載荷進行掩碼異或操作

1表示對數(shù)據(jù)載荷進行掩碼異或操作

Payload length: 占7或7+16或7+64bit

0~125: 數(shù)據(jù)長度等于該值

126: 后續(xù)的2個字節(jié)代表一個16位的無符號整數(shù), 值為數(shù)據(jù)的長度

127: 后續(xù)的8個字節(jié)代表一個64位的無符號整數(shù), 值為數(shù)據(jù)的長度

Masking-key: 占0或4bytes

1: 攜帶了4字節(jié)的Masking-key

0: 沒有Masking-key

掩碼的作用并不是防止數(shù)據(jù)泄密,而是為了防止早期版本協(xié)議中存在的代理緩存污染攻擊等問題

payload data: 載荷數(shù)據(jù)

數(shù)據(jù)傳遞

WebSocket的每條消息可能被切分成多個數(shù)據(jù)幀, 當接收到一個數(shù)據(jù)幀時,會根據(jù)FIN值來判斷, 是否為最后一個數(shù)據(jù)幀

數(shù)據(jù)幀傳遞示例:

FIN=0, Opcode=0x1: 發(fā)送文本類型, 消息還沒有發(fā)送完成,還有后續(xù)幀

FIN=0, Opcode=0x0: 消息沒有發(fā)送完成, 還有后續(xù)幀, 接在上一條后面

FIN=1, Opcode=0x0: 消息發(fā)送完成, 沒有后續(xù)幀, 接在上一條后面組成完整消息

正式開始定義屬于我們自己的通訊協(xié)議：

我們?yōu)槭裁匆远xTCP應用層傳輸協(xié)議？

針對特定的用戶群體，實現(xiàn)通訊信息的真正加密，復雜場景下更靈活的通信

因為在TCP流傳輸?shù)倪^程中，可能會出現(xiàn)分包與黏包的現(xiàn)象。我們?yōu)榱私鉀Q這些問題，需要我們自定義通信協(xié)議進行封包與解包。

什么是分包與黏包？

分包：指接受方沒有接受到一個完整的包，只接受了部分。

黏包：指發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時粘成一包，從接收緩沖區(qū)看，后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾。

PS:因為TCP是面向字節(jié)流的，是沒有邊界的概念的，嚴格意義上來說，是沒有分包和黏包的概念的，但是為了更好理解，也更好來描述現(xiàn)象，我在這里就接著采用這兩個名詞來解釋現(xiàn)象了。我覺得大家知道這個概念就行了，不必細扣，能解決問題就行。

產生分包與黏包現(xiàn)象的原因是什么？

產生分包原因：

可能是IP分片傳輸導致的，也可能是傳輸過程中丟失部分包導致出現(xiàn)的半包，還有可能就是一個包可能被分成了兩次傳輸，在取數(shù)據(jù)的時候，先取到了一部分（還可能與接收的緩沖區(qū)大小有關系），總之就是一個數(shù)據(jù)包被分成了多次接收。

產生黏包的原因：

由于TCP協(xié)議本身的機制（面向連接的可靠地協(xié)議-三次握手機制）客戶端與服務器會維持一個連接（Channel），數(shù)據(jù)在連接不斷開的情況下，可以持續(xù)不斷地將多個數(shù)據(jù)包發(fā)往服務器，但是如果發(fā)送的網絡數(shù)據(jù)包太小，那么他本身會啟用Nagle算法（可配置是否啟用）對較小的數(shù)據(jù)包進行合并（基于此，TCP的網絡延遲要UDP的高些）然后再發(fā)送（超時或者包大小足夠）。那么這樣的話，服務器在接收到消息（數(shù)據(jù)流）的時候就無法區(qū)分哪些數(shù)據(jù)包是客戶端自己分開發(fā)送的，這樣產生了粘包；服務器在接收到數(shù)據(jù)后，放到緩沖區(qū)中，如果消息沒有被及時從緩存區(qū)取走，下次在取數(shù)據(jù)的時候可能就會出現(xiàn)一次取出多個數(shù)據(jù)包的情況，造成粘包現(xiàn)象

什么是封包與解包？

TCP/IP 網絡數(shù)據(jù)以流的方式傳輸，數(shù)據(jù)流是由包組成，如何判定接收方收到的包是否是一個完整的包就要在發(fā)送時對包進行處理，這就是封包技術，將包處理成包頭，包體。

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

如何自定義協(xié)議？

發(fā)送時數(shù)據(jù)包是由包頭+數(shù)據(jù) 組成的：其中包頭內容分為包類型+包長度。

接收時，只需要先保證將數(shù)據(jù)包的包頭讀完整，通過收到的數(shù)據(jù)包包頭里的數(shù)據(jù)長度和數(shù)據(jù)包類型，判斷出我們將要收到一個帶有什么樣類型的多少長度的數(shù)據(jù)。然后循環(huán)接收直到接收的數(shù)據(jù)大小等于數(shù)據(jù)長度停止，此時我們完成接收一個完整數(shù)據(jù)包。

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

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

今天為了降低難度，沒有使用prob格式傳輸哦。

當然還有心跳的發(fā)包和回包，與上面類似，只是內容不一致。

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

上面說到了，WebSocket通信的最小單位是幀, 由一個或多個幀組成一條完整的消息, 交換數(shù)據(jù)的過程中, 發(fā)送端和接收端需要做的事情如下:

發(fā)送端: 將消息切割成多個幀, 并發(fā)送給服務端

接收端: 接受消息幀, 并將關聯(lián)的幀重新組裝成完整的消息

出現(xiàn)黏包和分包的問題，通俗易懂的說就是，創(chuàng)建buffer緩沖區(qū)，把二進制的數(shù)據(jù)一點一點點切出來，然后變成特定的js對象使用。

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

tcp.connect(80,142.122.0.0)

每個人定制的心跳發(fā)包回包都不一樣，具體格式可以參考上面，自行定制心跳包的內容和檢測時間，多長時間檢測不到心跳的處理機制。

這里寫一點拆包代碼

根據(jù)后端傳送的數(shù)據(jù)類型 使用對應不同的解析
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的定義格式：

ascii - 僅支持 7 位 ASCII 數(shù)據(jù)。如果設置去掉高位的話，這種編碼是非常快的。

utf8 - 多字節(jié)編碼的 Unicode 字符。許多網頁和其他文檔格式都使用 UTF-8 。

utf16le - 2 或 4 個字節(jié)，小字節(jié)序編碼的 Unicode 字符。支持代理對（U+10000 至 U+10FFFF）。

ucs2 - utf16le 的別名。

base64 - Base64 編碼。

latin1 - 一種把 Buffer 編碼成一字節(jié)編碼的字符串的方式。

binary - latin1 的別名。

hex - 將每個字節(jié)編碼為兩個十六進制字符。

創(chuàng)建 Buffer 類

Buffer 提供了以下 API 來創(chuàng)建 Buffer 類：

Buffer.alloc(size[, fill[, encoding]])： 返回一個指定大小的 Buffer 實例，如果沒有設置 fill，則默認填滿 0

Buffer.allocUnsafe(size)： 返回一個指定大小的 Buffer 實例，但是它不會被初始化，所以它可能包含敏感的數(shù)據(jù)

Buffer.allocUnsafeSlow(size)

Buffer.from(array)： 返回一個被 array 的值初始化的新的 Buffer 實例（傳入的 array 的元素只能是數(shù)字，不然就會自動被 0 覆蓋）

Buffer.from(arrayBuffer[, byteOffset[, length]])： 返回一個新建的與給定的 ArrayBuffer 共享同一內存的 Buffer。

Buffer.from(buffer)： 復制傳入的 Buffer 實例的數(shù)據(jù)，并返回一個新的 Buffer 實例

Buffer.from(string[, encoding])： 返回一個被 string 的值初始化的新的 Buffer 實例

所謂組包，就是把對應的js對象，變成二進制數(shù)據(jù)，然后推送給服務端

這里寫一個簡單的組包

    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是一個異步回掉，當數(shù)據(jù)推送完后才會調用。

方法參考手冊

以下列出了 Node.js Buffer 模塊常用的方法（注意有些方法在舊版本是沒有的）：

序號 方法 & 描述

1 new Buffer(size)

分配一個新的 size 大小單位為8位字節(jié)的 buffer。 注意, size 必須小于 kMaxLength，否則，將會拋出異常 RangeError。廢棄的: 使用 Buffer.alloc() 代替（或 Buffer.allocUnsafe()）。

2 new Buffer(buffer)

拷貝參數(shù) buffer 的數(shù)據(jù)到 Buffer 實例。廢棄的: 使用 Buffer.from(buffer) 代替。

3 new Buffer(str[, encoding])

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

4 buf.length

返回這個 buffer 的 bytes 數(shù)。注意這未必是 buffer 里面內容的大小。length 是 buffer 對象所分配的內存數(shù)，它不會隨著這個 buffer 對象內容的改變而改變。

5 buf.write(string[, offset[, length]][, encoding])

根據(jù)參數(shù) offset 偏移量和指定的 encoding 編碼方式，將參數(shù) string 數(shù)據(jù)寫入buffer。 offset 偏移量默認值是 0, encoding 編碼方式默認是 utf8。 length 長度是將要寫入的字符串的 bytes 大小。 返回 number 類型，表示寫入了多少 8 位字節(jié)流。如果 buffer 沒有足夠的空間來放整個 string，它將只會只寫入部分字符串。 length 默認是 buffer.length - offset。 這個方法不會出現(xiàn)寫入部分字符。

6 buf.writeUIntLE(value, offset, byteLength[, noAssert])

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

const buf = Buffer.allocUnsafe(6);

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

// 輸出: 
console.log(buf);
noAssert 值為 true 時，不再驗證 value 和 offset 的有效性。 默認是 false。

7 buf.writeUIntBE(value, offset, byteLength[, noAssert])

將 value 寫入到 buffer 里， 它由 offset 和 byteLength 決定，最高支持 48 位無符號整數(shù)，大端對齊。noAssert 值為 true 時，不再驗證 value 和 offset 的有效性。 默認是 false。

const buf = Buffer.allocUnsafe(6);

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

// 輸出: 
console.log(buf);

8 buf.writeIntLE(value, offset, byteLength[, noAssert])

將value 寫入到 buffer 里， 它由offset 和 byteLength 決定，最高支持48位有符號整數(shù)，小端對齊。noAssert 值為 true 時，不再驗證 value 和 offset 的有效性。 默認是 false。

9 buf.writeIntBE(value, offset, byteLength[, noAssert])

將value 寫入到 buffer 里， 它由offset 和 byteLength 決定，最高支持48位有符號整數(shù)，大端對齊。noAssert 值為 true 時，不再驗證 value 和 offset 的有效性。 默認是 false。

10 buf.readUIntLE(offset, byteLength[, noAssert])

支持讀取 48 位以下的無符號數(shù)字，小端對齊。noAssert 值為 true 時， offset 不再驗證是否超過 buffer 的長度，默認為 false。

11 buf.readUIntBE(offset, byteLength[, noAssert])

支持讀取 48 位以下的無符號數(shù)字，大端對齊。noAssert 值為 true 時， offset 不再驗證是否超過 buffer 的長度，默認為 false。

12 buf.readIntLE(offset, byteLength[, noAssert])

支持讀取 48 位以下的有符號數(shù)字，小端對齊。noAssert 值為 true 時， offset 不再驗證是否超過 buffer 的長度，默認為 false。

13 buf.readIntBE(offset, byteLength[, noAssert])

支持讀取 48 位以下的有符號數(shù)字，大端對齊。noAssert 值為 true 時， offset 不再驗證是否超過 buffer 的長度，默認為 false。

14 buf.toString([encoding[, start[, end]]])

根據(jù) encoding 參數(shù)（默認是 "utf8"）返回一個解碼過的 string 類型。還會根據(jù)傳入的參數(shù) start (默認是 0) 和 end (默認是 buffer.length)作為取值范圍。

15 buf.toJSON()

將 Buffer 實例轉換為 JSON 對象。

16 buf[index]

獲取或設置指定的字節(jié)。返回值代表一個字節(jié)，所以返回值的合法范圍是十六進制0x00到0xFF 或者十進制0至 255。

17 buf.equals(otherBuffer)

比較兩個緩沖區(qū)是否相等，如果是返回 true，否則返回 false。

18 buf.compare(otherBuffer)

比較兩個 Buffer 對象，返回一個數(shù)字，表示 buf 在 otherBuffer 之前，之后或相同。

19 buf.copy(targetBuffer[, targetStart[, sourceStart[, sourceEnd]]])

buffer 拷貝，源和目標可以相同。 targetStart 目標開始偏移和 sourceStart 源開始偏移默認都是 0。 sourceEnd 源結束位置偏移默認是源的長度 buffer.length 。

20 buf.slice([start[, end]])

剪切 Buffer 對象，根據(jù) start(默認是 0 ) 和 end (默認是 buffer.length ) 偏移和裁剪了索引。 負的索引是從 buffer 尾部開始計算的。

21 buf.readUInt8(offset[, noAssert])

根據(jù)指定的偏移量，讀取一個無符號 8 位整數(shù)。若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 如果這樣 offset 可能會超出buffer 的末尾。默認是 false。

22 buf.readUInt16LE(offset[, noAssert])

根據(jù)指定的偏移量，使用特殊的 endian 字節(jié)序格式讀取一個無符號 16 位整數(shù)。若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出 buffer 的末尾。默認是 false。

23 buf.readUInt16BE(offset[, noAssert])

根據(jù)指定的偏移量，使用特殊的 endian 字節(jié)序格式讀取一個無符號 16 位整數(shù)，大端對齊。若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出 buffer 的末尾。默認是 false。

24 buf.readUInt32LE(offset[, noAssert])

根據(jù)指定的偏移量，使用指定的 endian 字節(jié)序格式讀取一個無符號 32 位整數(shù)，小端對齊。 若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出buffer 的末尾。默認是 false。

25 buf.readUInt32BE(offset[, noAssert])

根據(jù)指定的偏移量，使用指定的 endian 字節(jié)序格式讀取一個無符號 32 位整數(shù)，大端對齊。 若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出buffer 的末尾。默認是 false。

26 buf.readInt8(offset[, noAssert])

根據(jù)指定的偏移量，讀取一個有符號 8 位整數(shù)。 若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出 buffer 的末尾。默認是 false。

27 buf.readInt16LE(offset[, noAssert])

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

28 buf.readInt16BE(offset[, noAssert])

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

29 buf.readInt32LE(offset[, noAssert])

根據(jù)指定的偏移量，使用指定的 endian 字節(jié)序格式讀取一個有符號 32 位整數(shù)，小端對齊。 若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出buffer 的末尾。默認是 false。

30 buf.readInt32BE(offset[, noAssert])

根據(jù)指定的偏移量，使用指定的 endian 字節(jié)序格式讀取一個有符號 32 位整數(shù)，大端對齊。 若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出buffer 的末尾。默認是 false。

31 buf.readFloatLE(offset[, noAssert])

根據(jù)指定的偏移量，使用指定的 endian 字節(jié)序格式讀取一個 32 位雙浮點數(shù)，小端對齊。 若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出buffer的末尾。默認是 false。

32 buf.readFloatBE(offset[, noAssert])

根據(jù)指定的偏移量，使用指定的 endian 字節(jié)序格式讀取一個 32 位雙浮點數(shù)，大端對齊。 若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出buffer的末尾。默認是 false。

33 buf.readDoubleLE(offset[, noAssert])

根據(jù)指定的偏移量，使用指定的 endian字節(jié)序格式讀取一個 64 位雙精度數(shù)，小端對齊。 若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出buffer 的末尾。默認是 false。

34 buf.readDoubleBE(offset[, noAssert])

根據(jù)指定的偏移量，使用指定的 endian字節(jié)序格式讀取一個 64 位雙精度數(shù)，大端對齊。 若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 offset 可能會超出buffer 的末尾。默認是 false。

35 buf.writeUInt8(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量將 value 寫入 buffer。注意：value 必須是一個合法的無符號 8 位整數(shù)。 若參數(shù) noAssert 為 true 將不會驗證 offset 偏移量參數(shù)。 這意味著 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則不要使用。默認是 false。

36 buf.writeUInt16LE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的無符號 16 位整數(shù)，小端對齊。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value 可能過大，或者 offset 可能會超出buffer的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false。

37 buf.writeUInt16BE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的無符號 16 位整數(shù)，大端對齊。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value 可能過大，或者 offset 可能會超出buffer的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false。

38 buf.writeUInt32LE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式(LITTLE-ENDIAN:小字節(jié)序)將 value 寫入buffer。注意：value 必須是一個合法的無符號 32 位整數(shù)，小端對齊。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著value 可能過大，或者offset可能會超出buffer的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false。

39 buf.writeUInt32BE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式(Big-Endian:大字節(jié)序)將 value 寫入buffer。注意：value 必須是一個合法的有符號 32 位整數(shù)。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value 可能過大，或者offset可能會超出buffer的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false。

40 buf.writeInt8(value, offset[, noAssert])

41 buf.writeInt16LE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的 signed 16 位整數(shù)。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false 。

42 buf.writeInt16BE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的 signed 16 位整數(shù)。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false 。

43 buf.writeInt32LE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的 signed 32 位整數(shù)。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false。

44 buf.writeInt32BE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個合法的 signed 32 位整數(shù)。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false。

45 buf.writeFloatLE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer 。注意：當 value 不是一個 32 位浮點數(shù)類型的值時，結果將是不確定的。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value可能過大，或者 offset 可能會超出 buffer 的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false。

46 buf.writeFloatBE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer 。注意：當 value 不是一個 32 位浮點數(shù)類型的值時，結果將是不確定的。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value可能過大，或者 offset 可能會超出 buffer 的末尾從而造成 value 被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false。

47 buf.writeDoubleLE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個有效的 64 位double 類型的值。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而造成value被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false。

48 buf.writeDoubleBE(value, offset[, noAssert])

根據(jù)傳入的 offset 偏移量和指定的 endian 格式將 value 寫入 buffer。注意：value 必須是一個有效的 64 位double 類型的值。 若參數(shù) noAssert 為 true 將不會驗證 value 和 offset 偏移量參數(shù)。 這意味著 value 可能過大，或者 offset 可能會超出 buffer 的末尾從而造成value被丟棄。 除非你對這個參數(shù)非常有把握，否則盡量不要使用。默認是 false。

49 buf.fill(value, offset)

使用指定的 value 來填充這個 buffer。如果沒有指定 offset (默認是 0) 并且 end (默認是 buffer.length) ，將會填充整個buffer。

最后的總結：

實時通訊，特別是三端加密和消息同步這塊，是非常復雜的，本人大概只寫到了10分之1

組包和拆包，具體要根據(jù)你特定的業(yè)務場景還有公司定制的協(xié)議去具體操作，這里只是一個大概闡述

后臺的代碼以后我會盡力用golang和node.js各寫一份。

海量高并發(fā)場景，機房部署，整體架構這里都沒有寫，因為確實太多了，一旦并發(fā)量上來了，無論前后端要做的事情都非常多

有幸公司昨天在深圳萬象城請到了Bilibili的架構師毛劍先生給我們培訓，他讓我對后端的認識又深刻了不少，特別是IM整體架構和優(yōu)化這塊，以后總結好了，也會給大家分享

如果有寫得不對的地方，請指出，謝謝。

加解密的過程沒有寫上來，這塊也是非常核心。