如何從零開始定義一個類似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協議的實現具體過程，再用程式碼抽象，定義自己的即時通訊協議：

• 連線握手過程

  • 關於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/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: 佔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物件使用。

第一步 先與服務端建立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整體架構和優化這塊，以後總結好了，也會給大家分享
• 如果有寫得不對的地方，請指出，謝謝。
• 加解密的過程沒有寫上來，這塊也是非常核心。