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

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

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

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

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