我們在涉及TCP協(xié)議的應用中，經常會出現(xiàn)粘包的問題。所謂粘包，簡單地講，就是我有兩條消息，明明發(fā)送端的代碼是分兩次發(fā)送的，但是在接收端卻一次性就接收到了兩條消息。這個情況不管是在嵌入式行業(yè)還是在互聯(lián)網(wǎng)行業(yè)，都非常的普遍。

TCP協(xié)議為什么粘包？

那就需要先了解 TCP 的定義。TCP（Transmission Control Protocol）傳輸控制協(xié)議，是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。其中跟粘包關系最大的就是基于字節(jié)流這個特點。字節(jié)流可以理解為一個雙向的通道里流淌的數(shù)據(jù)，這個數(shù)據(jù)其實就是我們常說的二進制數(shù)據(jù)，簡單來說就是一大堆 01 串。這些 01 串之間沒有任何邊界。應用層傳到 TCP 協(xié)議的數(shù)據(jù)，不是以消息報為單位向目的主機發(fā)送，而是以字節(jié)流的方式發(fā)送到下游，這些數(shù)據(jù)可能被切割和組裝成各種數(shù)據(jù)包，接收端接收到這些數(shù)據(jù)包后沒有正確還原之前的消息，因此出現(xiàn)粘包現(xiàn)象。那為什么會出現(xiàn)不能正確還原的情況呢？主要有兩個方面的原因：

1. 發(fā)送端的原因發(fā)送端在組裝消息的時候，就把幾個小包合成一包了，這樣接收端自然無法解析出小包。這對應的就是Nagle 算法。因為TCP和Nagle 算法都是上個世紀的產物了，在早期的網(wǎng)絡中這樣做，可以顯著地減小網(wǎng)絡的壓力。否則頻繁地發(fā)送僅有幾個字節(jié)的小包，會嚴重浪費網(wǎng)絡IO性能。但是在現(xiàn)代互聯(lián)網(wǎng)中，網(wǎng)絡性能已經有了大幅提升，似乎Nagle 算法提升的那么一點IO性能就不是那么重要了，反而由于等待數(shù)據(jù)來合并的操作，會導致傳輸延遲變大，在網(wǎng)絡游戲應用時，就會非常影響體驗。所以現(xiàn)在一般都會關掉它。2. 接收端的原因接收端接收到消息以后，應用層總是不能立即取走數(shù)據(jù)，總是會有接收緩沖區(qū)的存在。如果兩條獨立的消息進入緩沖區(qū)的間隔太小，應用層不能在兩次消息中間取走上一條消息，那么下次讀取的時候，就勢必會把兩包消息同時讀出來，這也會導致粘包。

而且這個情況并不能通過讓發(fā)送端在時間上均勻發(fā)包來避免，因為網(wǎng)絡不穩(wěn)定情況的存在，即使是時間上均勻發(fā)送的數(shù)據(jù)包，在接收端看來也可能是隨機出現(xiàn)的。

如何規(guī)避粘包的負面影響？

根據(jù)以上分析，我們不難發(fā)現(xiàn)，想要杜絕粘包的問題出現(xiàn)，基本上是不可能的。即使發(fā)送端和接收端都能自己控制，但是網(wǎng)絡傳輸?shù)倪^程也是很難控制的。
但是即使粘包的問題存在，也不影響我們大規(guī)模的使用TCP協(xié)議。因為這個問題在應用層非常好處理。大致有兩種思路：1. 在信息中加入特殊的標志作為分隔符

這樣，當應用層檢測到特殊的分隔符后，便知道這是一包得到開始和結束，就可以進行分片等操作，問題便迎刃而解。不過這樣存在一些弊端。比如定義分隔符為“12345678”，那如果消息內容里面出現(xiàn)“12345678”的字符串呢？這樣就會導致消息被異常的切片，導致接收到的消息錯誤。但假如自己能夠控制消息的內容，保證里面不會出現(xiàn)“12345678”的內容，則此方法較為靈活。2. 加入信息的長度根據(jù)約定好的長度的字段，讀取消息長度的信息，再根據(jù)消息長度信息讀取消息內容。這也是一種非常常用的方法，在很多協(xié)議中都有體現(xiàn)。
3. 添加包首部發(fā)送端給每個數(shù)據(jù)包添加包首部，首部中應該至少包含數(shù)據(jù)包的長度，這樣接收端在接收到數(shù)據(jù)后，就可以通過讀取包首部的長度字段，知道每一個數(shù)據(jù)包的實際長度。以上就是本期關于解決TCP粘包問題的內容，小編碼字不易，求個點贊、分享、在看三連支持！我們下期見~~