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

TCP協議為什么粘包？

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

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

而且這個情況并不能通過讓發送端在時間上均勻發包來避免，因為網絡不穩定情況的存在，即使是時間上均勻發送的數據包，在接收端看來也可能是隨機出現的。

如何規避粘包的負面影響？

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

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