TCP粘包?|?硬核圖解

事情從一個(gè)健身教練說起吧。

李東，自稱亞健康終結(jié)者，嘗試使用互聯(lián)網(wǎng) 的模式拓展自己的業(yè)務(wù)。在某款新開發(fā)的聊天軟件琛琛上發(fā)布廣告。

鍵盤說來就來。瘋狂發(fā)送"李東"，回車發(fā)送！，"亞健康終結(jié)者"，再回車發(fā)送！

還記得四層網(wǎng)絡(luò)協(xié)議長什么樣子嗎？

四層網(wǎng)絡(luò)協(xié)議四層網(wǎng)絡(luò)模型每層各司其職，消息在進(jìn)入每一層時(shí)都會(huì)多加一個(gè)報(bào)頭，每多一個(gè)報(bào)頭可以理解為數(shù)據(jù)報(bào)多戴一頂帽子。這個(gè)報(bào)頭上面記錄著消息從哪來，到哪去，以及消息多長等信息。比如，

mac頭部記錄的是硬件的唯一地址，

IP頭記錄的是從哪來和到哪去，傳輸層頭記錄到是到達(dá)目的主機(jī)后具體去哪個(gè)進(jìn)程。

在從消息發(fā)到網(wǎng)絡(luò)的時(shí)候給消息帶上報(bào)頭，消息和紛繁復(fù)雜的網(wǎng)絡(luò)中通過這些信息在路由器間流轉(zhuǎn)，最后到達(dá)目的機(jī)器上，接受者再通過這些報(bào)頭，一步一步還原出發(fā)送者最原始要發(fā)送的消息。

四層網(wǎng)絡(luò)協(xié)議 (1)

為什么要將數(shù)據(jù)切片

軟件琛琛是屬于應(yīng)用層上的。

而"李東"，"亞健康終結(jié)者"這兩條消息在進(jìn)入傳輸層時(shí)使用的是傳輸層上的 TCP 協(xié)議。消息在進(jìn)入傳輸層（TCP）時(shí)會(huì)被切片為一個(gè)個(gè)數(shù)據(jù)包。這個(gè)數(shù)據(jù)包的長度是

MSS。

可以把網(wǎng)絡(luò)比喻為一個(gè)水管，是有一定的粗細(xì)的，這個(gè)粗細(xì)由網(wǎng)絡(luò)接口層（數(shù)據(jù)鏈路層）提供給網(wǎng)絡(luò)層，一般認(rèn)為是的

MTU（1500），直接傳入整個(gè)消息，會(huì)超過水管的最大承受范圍，那么，就需要進(jìn)行切片，成為一個(gè)個(gè)數(shù)據(jù)包，這樣消息才能正常通過“水管”。

數(shù)據(jù)分片

MTU 和 MSS 有什么區(qū)別

MSS和MTU的區(qū)別

• MTU: Maximum Transmit Unit，最大傳輸單元。?由網(wǎng)絡(luò)接口層（數(shù)據(jù)鏈路層）提供給網(wǎng)絡(luò)層最大一次傳輸數(shù)據(jù)的大小；一般 MTU=1500 Byte。
  假設(shè)IP層有 1500 byte 數(shù)據(jù)需要發(fā)送，需要分片才能完成發(fā)送，分片后的 IP Header ID 相同。

• MSS：Maximum Segment Size。TCP 提交給 IP 層最大分段大小，不包含 TCP Header 和 ?TCP Option，只包含 TCP Payload ，MSS 是 TCP 用來限制應(yīng)用層最大的發(fā)送字節(jié)數(shù)。
  假設(shè) MTU= 1500 byte，那么MSS = 1500- 20(IP Header) -20 (TCP Header) = 1460 byte，如果應(yīng)用層有2000 byte發(fā)送，那么需要兩個(gè)切片才可以完成發(fā)送，第一個(gè) TCP 切片 = 1460，第二個(gè) TCP 切片 = 540。

什么是粘包

那么當(dāng)李東在手機(jī)上鍵入"李東""亞健康終結(jié)者"的時(shí)候，在 TCP 中把消息分成 MSS 大小后，消息順著網(wǎng)線順利發(fā)出。

發(fā)送消息到網(wǎng)絡(luò)網(wǎng)絡(luò)穩(wěn)得很，將消息分片傳到了對端手機(jī) B 上。經(jīng)過 TCP 層消息重組。變成"李東亞健康終結(jié)者"這樣的字節(jié)流（stream）。

消息從網(wǎng)絡(luò)接收但由于聊天軟件琛琛是新開發(fā)的，而且開發(fā)者叫小白，完了，是個(gè)臭名昭著的造 bug 工程師。經(jīng)過他的代碼，在處理字節(jié)流的時(shí)候消息從"李東"，"亞健康終結(jié)者"變成了"李東亞"，"健康終結(jié)者"。"李東"作為上一個(gè)包的內(nèi)容與下一個(gè)包里的"亞"粘在了一起被錯(cuò)誤地當(dāng)成了一個(gè)數(shù)據(jù)包解析了出來。這就是所謂的粘包。

消息對比一個(gè)號(hào)稱健康終結(jié)者的健身教練，大概運(yùn)氣也不會(huì)很差吧，就祝他客源滾滾吧。

為什么會(huì)出現(xiàn)粘包

那就要從 TCP 是啥說起。

TCP，Transmission Control Protocol。傳輸控制協(xié)議，是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

TCP是什么其中跟粘包關(guān)系最大的就是基于字節(jié)流這個(gè)特點(diǎn)。

字節(jié)流可以理解為一個(gè)雙向的通道里流淌的數(shù)據(jù)，這個(gè)數(shù)據(jù)其實(shí)就是我們常說的二進(jìn)制數(shù)據(jù)，簡單來說就是一大堆 01 串。這些 01 串之間沒有任何邊界。

二進(jìn)制字節(jié)流應(yīng)用層傳到 TCP 協(xié)議的數(shù)據(jù)，不是以消息報(bào)為單位向目的主機(jī)發(fā)送，而是以字節(jié)流的方式發(fā)送到下游，這些數(shù)據(jù)可能被切割和組裝成各種數(shù)據(jù)包，接收端收到這些數(shù)據(jù)包后沒有正確還原原來的消息，因此出現(xiàn)粘包現(xiàn)象。

為什么要組裝發(fā)送的數(shù)據(jù)

上面提到 TCP切割數(shù)據(jù)包是為了能順利通過網(wǎng)絡(luò)這根水管。相反，還有一個(gè)組裝的情況。如果前后兩次 TCP 發(fā)的數(shù)據(jù)都遠(yuǎn)小于 MSS，比如就幾個(gè)字節(jié)，每次都單獨(dú)發(fā)送這幾個(gè)字節(jié)，就比較浪費(fèi)網(wǎng)絡(luò) io 。

正常發(fā)送數(shù)據(jù)包比如小白爸讓小白出門給買一瓶醬油，小白出去買醬油回來了。小白媽又讓小白出門買一瓶醋回來。小白前后結(jié)結(jié)實(shí)實(shí)跑了兩趟，影響了打游戲的時(shí)間。

優(yōu)化的方法也比較簡單。當(dāng)小白爸讓小白去買醬油的時(shí)候，小白先等待，繼續(xù)打會(huì)游戲，這時(shí)候如果小白媽讓小白買瓶醋回來，小白可以一次性帶著兩個(gè)需求出門，再把東西帶回來。

上面說的其實(shí)就是

TCP的Nagle 算法優(yōu)化，目的是為了避免發(fā)送小的數(shù)據(jù)包。

在 Nagle 算法開啟的狀態(tài)下，數(shù)據(jù)包在以下兩個(gè)情況會(huì)被發(fā)送：

• 如果包長度達(dá)到

  MSS（或含有

  Fin包），立刻發(fā)送，否則等待下一個(gè)包到來；如果下一包到來后兩個(gè)包的總長度超過

  MSS的話，就會(huì)進(jìn)行拆分發(fā)送；

• 等待超時(shí)（一般為

  200ms），第一個(gè)包沒到

  MSS長度，但是又遲遲等不到第二個(gè)包的到來，則立即發(fā)送。

Nagle2

• 由于啟動(dòng)了Nagle算法，msg1 小于 mss ，此時(shí)等待

  200ms內(nèi)來了一個(gè) msg2，msg1 msg2 > MSS，因此把 msg2 分為 msg2(1) 和 msg2(2)，msg1 msg2(1) 包的大小為

  MSS。此時(shí)發(fā)送出去。

• 剩余的 msg2(2) 也等到了 msg3，同樣 msg2(2) msg3 > MSS，因此把 msg3分為msg3(1) 和 msg3(2)，msg2(2) msg3(1) 作為一個(gè)包發(fā)送。

• 剩余的 msg3(2) 長度不足

  mss，同時(shí)在

  200ms內(nèi)沒有等到下一個(gè)包，等待超時(shí)，直接發(fā)送。

• 此時(shí)三個(gè)包雖然在圖里顏色不同，但是實(shí)際場景中，他們都是一整個(gè) 01 串，如果處理開發(fā)者把第一個(gè)收到的 msg1 msg2(1) 就當(dāng)做是一個(gè)完整消息進(jìn)行處理，就會(huì)看上去就像是兩個(gè)包粘在一起，就會(huì)導(dǎo)致粘包問題。

關(guān)掉Nagle算法就不會(huì)粘包了嗎？

Nagle算法其實(shí)是個(gè)有些年代的東西了，誕生于 1984 年。對于應(yīng)用程序一次發(fā)送一字節(jié)數(shù)據(jù)的場景，如果沒有 Nagle 的優(yōu)化，這樣的包立馬就發(fā)出去了，會(huì)導(dǎo)致網(wǎng)絡(luò)由于太多的包而過載。

但是今天網(wǎng)絡(luò)環(huán)境比以前好太多，Nagle 的優(yōu)化幫助就沒那么大了。而且它的延遲發(fā)送，有時(shí)候還可能導(dǎo)致調(diào)用延時(shí)變大，比如打游戲的時(shí)候，你操作如此絲滑，但卻因?yàn)?Nagle 算法延遲發(fā)送導(dǎo)致慢了一拍，就問你難受不難受。

所以現(xiàn)在一般也會(huì)把它關(guān)掉。

看起來，Nagle 算法的優(yōu)化作用貌似不大，還會(huì)導(dǎo)致粘包"問題"。那么是不是關(guān)掉這個(gè)算法就可以解決掉這個(gè)粘包"問題"呢？

TCP_NODELAY?=?1
關(guān)閉Nagle就不會(huì)粘包了嗎

• 接受端應(yīng)用層在收到msg1時(shí)立馬就取走了，那此時(shí)msg1沒粘包問題

• **msg2 **到了后，應(yīng)用層在忙，沒來得及取走，就呆在TCP Recv Buffer中了

• **msg3 **此時(shí)也到了，跟msg2和msg3一起放在了TCP Recv Buffer中

• 這時(shí)候應(yīng)用層忙完了，來取數(shù)據(jù)，圖里是兩個(gè)顏色作區(qū)分，但實(shí)際場景中都是 01 串，此時(shí)一起取走，發(fā)現(xiàn)還是粘包。

因此，就算關(guān)閉 Nagle 算法，接收數(shù)據(jù)端的應(yīng)用層沒有及時(shí)讀取 TCP Recv Buffer 中的數(shù)據(jù)，還是會(huì)發(fā)生粘包。

怎么處理粘包

粘包出現(xiàn)的根本原因是不確定消息的邊界。接收端在面對"無邊無際"的二進(jìn)制流的時(shí)候，根本不知道收了多少 01 才算一個(gè)消息。一不小心拿多了就說是粘包。其實(shí)粘包根本不是 TCP 的問題，是使用者對于 TCP 的理解有誤導(dǎo)致的一個(gè)問題。

只要在發(fā)送端每次發(fā)送消息的時(shí)候給消息帶上識(shí)別消息邊界的信息，接收端就可以根據(jù)這些信息識(shí)別出消息的邊界，從而區(qū)分出每個(gè)消息。

常見的方法有

• 加入特殊標(biāo)志
  消息邊界頭尾標(biāo)志可以通過特殊的標(biāo)志作為頭尾，比如當(dāng)收到了

  0xfffffe或者回車符，則認(rèn)為收到了新消息的頭，此時(shí)繼續(xù)取數(shù)據(jù)，直到收到下一個(gè)頭標(biāo)志

  0xfffffe或者尾部標(biāo)記，才認(rèn)為是一個(gè)完整消息。類似的像 HTTP 協(xié)議里當(dāng)使用chunked 編碼傳輸時(shí)，使用若干個(gè) chunk 組成消息，最后由一個(gè)標(biāo)明長度為 0 的 chunk 結(jié)束。

• 加入消息長度信息

消息邊界長度標(biāo)志這個(gè)一般配合上面的特殊標(biāo)志一起使用，在收到頭標(biāo)志時(shí)，里面還可以帶上消息長度，以此表明在這之后多少 byte 都是屬于這個(gè)消息的。如果在這之后正好有符合長度的 byte，則取走，作為一個(gè)完整消息給應(yīng)用層使用。在實(shí)際場景中，HTTP 中的

Content-Length就起了類似的作用，當(dāng)接收端收到的消息長度小于 Content-Length 時(shí)，說明還有些消息沒收到。那接收端會(huì)一直等，直到拿夠了消息或超時(shí)。

可能這時(shí)候會(huì)有朋友會(huì)問，采用

0xfffffe標(biāo)志位，用來標(biāo)志一個(gè)數(shù)據(jù)包的開頭，你就不怕你發(fā)的某個(gè)數(shù)據(jù)里正好有這個(gè)內(nèi)容嗎？

是的，怕，所以一般除了這個(gè)標(biāo)志位，發(fā)送端在發(fā)送時(shí)還會(huì)加入各種校驗(yàn)字段（

校驗(yàn)和或者對整段完整數(shù)據(jù)進(jìn)行

CRC之后獲得的數(shù)據(jù)）放在標(biāo)志位后面，在接收端拿到整段數(shù)據(jù)后校驗(yàn)下確保它就是發(fā)送端發(fā)來的完整數(shù)據(jù)。

消息邊界頭尾加校驗(yàn)標(biāo)志

UDP 會(huì)粘包嗎

跟

TCP同為傳輸層的另一個(gè)協(xié)議，UDP，User Datagram Protocol。用戶數(shù)據(jù)包協(xié)議，是面向無連接，不可靠的，基于數(shù)據(jù)報(bào)的傳輸層通信協(xié)議。

UDP是什么基于數(shù)據(jù)報(bào)是指無論應(yīng)用層交給 UDP 多長的報(bào)文，UDP 都照樣發(fā)送，即一次發(fā)送一個(gè)報(bào)文。至于如果數(shù)據(jù)包太長，需要分片，那也是IP層的事情，大不了效率低一些。UDP 對應(yīng)用層交下來的報(bào)文，既不合并，也不拆分，而是保留這些報(bào)文的邊界。而接收方在接收數(shù)據(jù)報(bào)的時(shí)候，也不會(huì)像面對 TCP 無窮無盡的二進(jìn)制流那樣不清楚啥時(shí)候能結(jié)束。正因?yàn)榛跀?shù)據(jù)報(bào)和基于字節(jié)流的差異，TCP 發(fā)送端發(fā) 10 次字節(jié)流數(shù)據(jù)，而這時(shí)候接收端可以分 100 次去取數(shù)據(jù)，每次取數(shù)據(jù)的長度可以根據(jù)處理能力作調(diào)整；但 UDP 發(fā)送端發(fā)了 10 次數(shù)據(jù)報(bào)，那接收端就要在 10 次收完，且發(fā)了多少，就取多少，確保每次都是一個(gè)完整的數(shù)據(jù)報(bào)。

我們先看下IP報(bào)頭

ip報(bào)頭注意這里面是有一個(gè) 16 位的總長度的，意味著 IP 報(bào)頭里記錄了整個(gè) IP 包的總長度。接著我們再看下UDP 的報(bào)頭。

UDP報(bào)頭在報(bào)頭中有

16bit用于指示UDP 數(shù)據(jù)報(bào)文的長度，假設(shè)這個(gè)長度是 n ，以此作為數(shù)據(jù)邊界。因此在接收端的應(yīng)用層能清晰地將不同的數(shù)據(jù)報(bào)文區(qū)分開，從報(bào)頭開始取 n 位，就是一個(gè)完整的數(shù)據(jù)報(bào)，從而避免粘包和拆包的問題。

當(dāng)然，就算沒有這個(gè)位（16位 UDP 長度），因?yàn)?IP 的頭部已經(jīng)包含了數(shù)據(jù)的總長度信息，此時(shí)如果 IP 包（網(wǎng)絡(luò)層）里放的數(shù)據(jù)使用的協(xié)議是 UDP（傳輸層），那么這個(gè)總長度其實(shí)就包含了 UDP 的頭部和 UDP 的數(shù)據(jù)。

因?yàn)?UDP 的頭部長度固定為 8 字節(jié)（ 1 字節(jié)= 8 位，8 字節(jié)= 64 位，上圖中除了

數(shù)據(jù)和選項(xiàng)以外的部分），那么這樣就很容易的算出 UDP 的數(shù)據(jù)的長度了。因此說 UDP 的長度信息其實(shí)是冗余的。

UDP數(shù)據(jù)長度

UDP?Data?的長度?=?IP?總長度?-?IP?Header?長度?-?UDP?Header?長度
可以再來看下TCP 的報(bào)頭

tcp報(bào)頭2TCP首部里是沒有長度這個(gè)信息的，跟UDP類似，同樣可以通過下面的公式獲得當(dāng)前包的TCP數(shù)據(jù)長度。

TCP Data 的長度?= IP 總長度?- IP Header 長度?- TCP Header 長度。
TCP數(shù)據(jù)長度跟 UDP 不同在于，TCP 發(fā)送端在發(fā)的時(shí)候就不保證發(fā)的是一個(gè)完整的數(shù)據(jù)報(bào)，僅僅看成一連串無結(jié)構(gòu)的字節(jié)流，這串字節(jié)流在接收端收到時(shí)哪怕知道長度也沒用，因?yàn)樗芸赡苤皇悄硞€(gè)完整消息的一部分。

為什么長度字段冗余還要加到 UDP 首部中

關(guān)于這一點(diǎn)，查了很多資料，

《 TCP-IP 詳解（卷2）》里說可能是因?yàn)橐糜谟?jì)算校驗(yàn)和。也有的說是因?yàn)閁DP底層使用的可以不是IP協(xié)議，畢竟 IP 頭里帶了總長度，正好可以用于計(jì)算 UDP 數(shù)據(jù)的長度，萬一 UDP 的底層不是IP層協(xié)議，而是其他網(wǎng)絡(luò)層協(xié)議，就不能繼續(xù)這么計(jì)算了。

但我覺得，最重要的原因是，IP 層是網(wǎng)絡(luò)層的，而 UDP 是傳輸層的，到了傳輸層，數(shù)據(jù)包就已經(jīng)不存在IP頭信息了，那么此時(shí)的UDP數(shù)據(jù)會(huì)被放在 UDP 的 ?

Socket Buffer中。當(dāng)應(yīng)用層來不及取這個(gè) UDP 數(shù)據(jù)報(bào)，那么兩個(gè)數(shù)據(jù)報(bào)在數(shù)據(jù)層面其實(shí)都是一堆 01 串。此時(shí)讀取第一個(gè)數(shù)據(jù)報(bào)的時(shí)候，會(huì)先讀取到 UDP 頭部，如果這時(shí)候 UDP 頭不含 UDP 長度信息，那么應(yīng)用層應(yīng)該取多少數(shù)據(jù)才算完整的一個(gè)數(shù)據(jù)報(bào)呢？

因此 UDP 頭的這個(gè)長度其實(shí)跟 TCP 為了防止粘包而在消息體里加入的邊界信息是起一樣的作用的。

為什么UDP要冗余一個(gè)長度字段面試的時(shí)候咱就把這些全說出去，顯得咱好像經(jīng)過了深深的思考一樣，面試官可能會(huì)覺得咱特別愛思考，加分加分。

IP 層有粘包問題嗎

IP 層會(huì)對大包進(jìn)行切片，是不是也有粘包問題？

先說結(jié)論，不會(huì)。首先前文提到了，粘包其實(shí)是由于使用者無法正確區(qū)分消息邊界導(dǎo)致的一個(gè)問題。

先看看 IP 層的切片分包是怎么回事。

P分包與重組

• 如果消息過長，

  IP層會(huì)按MTU 長度把消息分成N 個(gè)切片，每個(gè)切片帶有自身在包里的位置（offset）和同樣的IP頭信息。

• 各個(gè)切片在網(wǎng)絡(luò)中進(jìn)行傳輸。每個(gè)數(shù)據(jù)包切片可以在不同的路由中流轉(zhuǎn)，然后在最后的終點(diǎn)匯合后再組裝。

• 在接收端收到第一個(gè)切片包時(shí)會(huì)申請一塊新內(nèi)存，創(chuàng)建IP包的數(shù)據(jù)結(jié)構(gòu)，等待其他切片分包數(shù)據(jù)到位。

• 等消息全部到位后就把整個(gè)消息包給到上層（傳輸層）進(jìn)行處理。

可以看出整個(gè)過程，

IP 層從按長度切片到把切片組裝成一個(gè)數(shù)據(jù)包的過程中，都只管運(yùn)輸，都不需要在意消息的邊界和內(nèi)容，都不在意消息內(nèi)容了，那就不會(huì)有粘包一說了。

IP 層表示：我只管把發(fā)送端給我的數(shù)據(jù)傳到接收端就完了，我也不了解里頭放了啥東西。

聽起來就像 “我不管產(chǎn)品的需求傻不傻X，我實(shí)現(xiàn)了就行，我不問，也懶得爭了”，這思路值得每一位優(yōu)秀的劃水程序員學(xué)習(xí)，respect。

總結(jié)

粘包這個(gè)問題的根因是由于開發(fā)人員沒有正確理解 TCP 面向字節(jié)流的數(shù)據(jù)傳輸方式，本身并不是 TCP 的問題，是開發(fā)者的問題。

• TCP 不管發(fā)送端要發(fā)什么，都基于字節(jié)流把數(shù)據(jù)發(fā)到接收端。這個(gè)字節(jié)流里可能包含上一次想要發(fā)的數(shù)據(jù)的部分信息。接收端根據(jù)需要在消息里加上識(shí)別消息邊界的信息。不加就可能出現(xiàn)粘包問題。

• TCP 粘包跟Nagle算法有關(guān)系，但關(guān)閉 Nagle 算法并不解決粘包問題。

• UDP 是基于數(shù)據(jù)報(bào)的傳輸協(xié)議，不會(huì)有粘包問題。

• IP 層也切片，但是因?yàn)椴魂P(guān)心消息里有啥，因此有不會(huì)有粘包問題。

• TCP發(fā)送端可以發(fā)

  10 次字節(jié)流數(shù)據(jù)，接收端可以分

  100 次去取；

  UDP發(fā)送端發(fā)了

  10 次數(shù)據(jù)報(bào)，那接收端就要在

  10 次收完。

數(shù)據(jù)包也只是按著 TCP 的方式進(jìn)行組裝和拆分，如果數(shù)據(jù)包有錯(cuò)，那數(shù)據(jù)包也只是犯了每個(gè)數(shù)據(jù)包都會(huì)犯的錯(cuò)而已。

最后，李東工作沒了，而小白表示

- EOF -