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

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

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

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

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