一、粘包

1、定義

指發(fā)送方發(fā)送的若干數(shù)據(jù)包在接收方接收時粘成一團，從接收緩沖區(qū)看，后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾。

2、產(chǎn)生的原因

（1）發(fā)送方的原因

TCP默認使用 Nagle 算法，而 Nagle 算法主要做如下兩件事情：

• 只有上一個分組得到確認，才發(fā)送下一個分組。
• 收集多個小分組，在一個確認到來時一起發(fā)送。

Nagle 算法造成了發(fā)送方可能存在粘包現(xiàn)象。

（2）接收端的原因

接收端接收到分組時，應(yīng)用層并不會立即處理，接收端將接收到的分組放到接收緩存中，然后應(yīng)用程序主動從接收緩存中讀取分組，當接收端接收分組的速度大于應(yīng)用程序讀取分組的速度時，多個包就會被存至緩存。應(yīng)用程序讀取時，就會讀到多個首尾相連在一起的包。

3、什么時候需要處理 TCP 粘包問題。

• 如果發(fā)送方的多個分組本來就是同一個數(shù)據(jù)的不同部分，比如一個很大的文件分成多個分組發(fā)送，這時不需要處理TCP粘包問題。
• 如果多個分組毫不相干，甚至是并聯(lián)關(guān)系，則一定要處理TCP粘包問題。

二、拆包

1、定義

發(fā)送方將一個數(shù)據(jù)包拆分成了多個數(shù)據(jù)包進行傳送。

2、產(chǎn)生的原因

• 要發(fā)送的數(shù)據(jù)大于 TCP 剩余緩沖區(qū)的大小。
• 要發(fā)送的數(shù)據(jù)大于 MSS 最大報文長度。

三、如何處理TCP粘包和TCP拆包問題

無論是TCP拆包還是TCP粘包本質(zhì)問題都在于無法區(qū)分包的界限，可以采用以下三種方式來區(qū)分包的界限

消息數(shù)據(jù)固定長度，但是浪費存儲和網(wǎng)絡(luò)資源。

使用分割符來區(qū)分包的界限。

數(shù)據(jù)包的頭部中增加數(shù)據(jù)包長度字段。

四、代碼示栗

#pragma pack(1)struct XMNPkgHeader {// 報文的總長度（包頭 + 包體）。unsigned short pkglen;// 消息類型的代碼，用于區(qū)別不同的命令（消息）。unsigned short msgcode;// CRC32 校驗，用于防止接收到的數(shù)據(jù)和 client 發(fā)送的數(shù)據(jù)不符的問題。int crc32; };#pragma pack()

之所以使用 pack(1) ，目的是讓包頭大小更緊湊，節(jié)約流量。 由于包頭的大小（headerlen）是固定的，通過 pkglen 就可以知道包體的大小（bodylen = pkglen - headerlen）。

在已知包頭和包體的長度的情況下，接受數(shù)據(jù)包的時候，首先可以接收?headerlen 大小的數(shù)據(jù)，如果接收的數(shù)據(jù)不夠，則下次接收包頭剩余的數(shù)據(jù)，直至包頭數(shù)據(jù)接收完畢。

包頭數(shù)據(jù)接收完畢之后，再接收 bodylen 大小的數(shù)據(jù)，如果接收的數(shù)據(jù)不足，則接收剩下的包體的數(shù)據(jù)，直至包體的數(shù)據(jù)接收完畢。

五、總結(jié)

TCP 之所以存在拆包和粘包問題，本質(zhì)就是 TCP 是面向字節(jié)流的，而 UDP 是面向報文的！

六、源碼鏈接

https://github.com/xuchanglong/XMoon

?

（SAW：Game Over！）

總結(jié)

以上是生活随笔為你收集整理的TCPIP / 粘包和拆包的定义以及解决办法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。