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

深南大道鎮樓

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

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

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

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

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

更好的二進制支持。

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

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

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

連接握手過程

關于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

請求頭詳解

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

請求必須含有Host

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

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

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

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

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

1.2 服務器: 響應協議升級

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

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值由一個隨機生成的16字節的隨機數通過base64編碼得到的

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

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

Key可以避免反向代理緩存

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

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

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

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

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: 占1bit

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 網絡數據以流的方式傳輸，數據流是由包組成，如何判定接收方收到的包是否是一個完整的包就要在發送時對包進行處理，這就是封包技術，將包處理成包頭，包體。

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

如何自定義協議？

發送時數據包是由包頭+數據 組成的：其中包頭內容分為包類型+包長度。

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

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

{
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對象使用。

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的定義格式：

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

方法參考手冊

以下列出了 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);

// 輸出: 
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);

// 輸出: 
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整體架構和優化這塊，以后總結好了，也會給大家分享

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

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