默認情況下, TCP 連接會啟?延遲傳送算法 (Nagle 算法), 在數據發送之前緩存他們. 如果短時間有多個數據發送, 會緩沖到?起作?次發送 (緩沖??? socket.bufferSize ), 這樣可以減少 IO 消耗提?性能.

如果是傳輸?件的話, 那么根本不?處理粘包的問題, 來?個包拼?個包就好了。但是如果是多條消息, 或者是別的?途的數據那么就需要處理粘包.

下面看?個例?, 連續調?兩次 send 分別發送兩段數據 data1 和 data2, 在接收端有以下?種常?的情況:A. 先接收到 data1, 然后接收到 data2 .B. 先接收到 data1 的部分數據, 然后接收到 data1 余下的部分以及 data2 的全部.C. 先接收到了 data1 的全部數據和 data2 的部分數據, 然后接收到了 data2 的余下的數據.D. ?次性接收到了 data1 和 data2 的全部數據.其中的 BCD 就是我們常?的粘包的情況. ?對于處理粘包的問題, 常?的解決?案有:多次發送之前間隔?個等待時間：只需要等上?段時間再進?下?次 send 就好, 適?于交互頻率特別低的場景. 缺點也很明顯, 對于?較頻繁的場景??傳輸效率實在太低，不過?乎不?做什么處理.

關閉 Nagle 算法：關閉 Nagle 算法, 在 Node.js 中你可以通過 socket.setNoDelay() ?法來關閉 Nagle 算法, 讓每?次 send 都不緩沖直接發送。該?法?較適?于每次發送的數據都?較? (但不是?件那么?), 并且頻率不是特別?的場景。如果是每次發送的數據量?較?, 并且頻率特別?的, 關閉 Nagle 純屬?廢武功。另外, 該?法不適?于?絡較差的情況, 因為 Nagle 算法是在服務端進?的包合并情況, 但是如果短時間內客戶端的?絡情況不好, 或者應?層由于某些原因不能及時將 TCP 的數據 recv, 就會造成多個包在客戶端緩沖從?粘包的情況。 (如果是在穩定的機房內部通信那么這個概率是?較?可以選擇忽略的)

進?封包/拆包： 封包/拆包是?前業內常?的解決?案了。即給每個數據包在發送之前, 于其前/后放?些有特征的數據, 然后收到數據的時 候根據特征數據分割出來各個數據包。