轉載：

粘包產生原因：

先說TCP：由於TCP協議本身的機制（面向連線的可靠地協議-三次握手機制）客戶端與伺服器會維持一個連線（Channel），資料在連線不斷開的情況下，可以持續不斷地將多個數據包發往伺服器，但是如果傳送的網路資料包太小，那麼他本身會啟用Nagle演算法（可配置是否啟用）對較小的資料包進行合併（基於此，TCP的網路延遲要UDP的高些）然後再發送（超時或者包大小足夠）。那麼這樣的話，伺服器在接收到訊息（資料流）的時候就無法區分哪些資料包是客戶端自己分開發送的，這樣產生了粘包；伺服器在接收到資料庫後，放到緩衝區中，如果訊息沒有被及時從快取區取走，下次在取資料的時候可能就會出現一次取出多個數據包的情況，造成粘包現象（確切來講，對於基於TCP協議的應用，不應用包來描述，而應 用 流來描述），個人認為伺服器接收端產生的粘包應該與linux核心處理socket的方式 select輪詢機制的線性掃描頻度無關。 再說UDP：本身作為無連線的不可靠的傳輸協議（適合頻繁傳送較小的資料包），他不會對資料包進行合併傳送（也就沒有Nagle演算法之說了），他直接是一端傳送什麼資料，直接就發出去了，既然他不會對資料合併，每一個數據包都是完整的（資料+UDP頭+IP頭等等發一次資料封裝一次）也就沒有粘包一說了。 分包產生的原因就簡單的多：可能是IP分片傳輸導致的，也可能是傳輸過程中丟失部分包導致出現的半包，還有可能就是一個包可能被分成了兩次傳輸，在取資料的時候，先取到了一部分（還可能與接收的緩衝區大小有關係），總之就是一個數據包被分成了多次接收。 解決辦法： 粘包與分包的處理方法： 我根據現有的一些開源資料做了如下總結（常用的解決方案）： 一個是採用分隔符的方式，即我們在封裝要傳輸的資料包的時候，採用固定的符號作為結尾符（資料中不能含結尾符），這樣我們接收到資料後，如果出現結尾標識，即人為的將粘包分開，如果一個包中沒有出現結尾符，認為出現了分包，則等待下個包中出現後 組合成一個完整的資料包，這種方式適合於文字傳輸的資料，如採用/r/n之類的分隔符； 另一種是採用在資料包中新增長度的方式，即在資料包中的固定位置封裝資料包的長度資訊（或可計算資料包總長度的資訊），伺服器接收到資料後，先是解析包長度，然後根據包長度擷取資料包（此種方式常出現於自定義協議中），但是有個小問題就是如果客戶端第一個資料包資料長度封裝的有錯誤，那麼很可能就會導致後面接收到的所有資料包都解析出錯（由於TCP建立連線後流式傳輸機制），只有客戶端關閉連線後重新開啟才可以消除此問題，我在處理這個問題的時候對資料長度做了校驗，會適時的對接收到的有問題的包進行人為的丟棄處理（客戶端有自動重發機制，故而在應用層不會導致資料的不完整性）； 另一種不建議的方式是TCP採用短連線處理粘包（這個得根據需要來，所以不建議）； /***********************************************************************************************************************************************/

TCP粘包是指傳送方傳送的若干包資料到接收方接收時粘成一包，從接收緩衝區看，後一包資料的頭緊接著前一包資料的尾。粘包可能由傳送方造成，也可能由接收方造成。TCP為提高傳輸效率，傳送方往往要收集到足夠多的資料後才傳送一包資料，造成多個數據包的粘連。如果接收程序不及時接收資料，已收到的資料就放在系統接收緩衝區，使用者程序讀取資料時就可能同時讀到多個數據包。因為系統傳輸的資料是帶結構的資料，需要做分包處理。

為了適應高速複雜網路條件，我們設計實現了粘包處理模組，由接收方通過預處理過程，對接收到的資料包進行預處理，將粘連的包分開。為了方便粘包處理，提高處理效率，在接收環節使用了環形緩衝區來儲存接收到的資料。其結構如表1所示。

                                                            表1 環形緩衝結構

欄位名	型別	含義
CS	CRITICAL_SECTION	保護環形緩衝的臨界區
pRingBuf	UINT8*	緩衝區起始位置
pRead	UINT8*	當前未處理資料的起始位置
pWrite	UINT8*	當前未處理資料的結束位置
pLastWrite	UINT8*	當前緩衝區的結束位置

環形緩衝跟每個TCP套接字繫結。在每個TCP的SOCKET_OBJ建立時，同時建立一個PRINGBUFFER結構並初始化。這時候，pRingBuf指向環形緩衝區的記憶體首地址，pRead、pWrite指標也指向它。pLastWrite指標在這時候沒有實際意義。初始化之後的結構如圖1所示。

圖1 初始化後的環形緩衝區

在每次投遞一個TCP的接收操作時，從RINGBUFFER獲取記憶體作接收緩衝區，一般規定一個最大值L1作為可以寫入的最大資料量。這時把pWrite的值賦給BUFFER_OBJ的buf欄位，把L1賦給bufLen欄位。這樣每次接收到的資料就從pWrite開始寫入緩衝區，最多寫入L1位元組，如圖 2。

圖2分配緩衝後的環形緩衝

如果某次分配過程中，pWrite到緩衝區結束的位置pEnd長度不夠最小分配長度L1，為了提高接收效率，直接廢棄最後一段記憶體，標記pLastWrite為pWrite。然後從pRingBuf開始分配記憶體，如圖 3。

圖3 使用到結尾的環形緩衝

特殊情況下，如果處理包速度太慢，或者接收太快，可能導致未處理包占用大部分緩衝區，沒有足夠的緩衝區分配給新的接收操作，如圖4。這時候直接報告錯誤即可。

圖4沒有足夠接收緩衝的環形緩衝

當收到一個長度為L資料包時，需要修改緩衝區的指標。這時候已經寫入資料的位置變為（pWrite+L），如圖 5。

圖5收到長度為L的資料的環形緩衝

分析上述環形緩衝的使用過程，收到資料後的情況可以簡單歸納為兩種：pWrite>pRead，接收但未處理的資料位於pRead到pWrite之間的緩衝區；pWrite<pRead，這時候，資料位於pRead到pLastWrite和pRingbuf到pWrite之間。這兩種情況分別對應圖6、圖 7。

首先分析圖6。此時，pRead是一個包的起始位置，如果L1足夠一個包頭長度，就獲取該包的長度資訊，記為L。假如L1>L，就說明一個數據包接收完成，根據包型別處理包，然後修改pRead指標，指向下一個包的起始位置（pRead+L）。這時候仍然類似於之前的狀態，於是解包繼續，直到L1不足一個包的長度，或者不足包頭長度。這時退出解包過程，等待後續的資料到來。

圖6有未處理資料的環形緩衝（1）

圖7有未處理資料的環形緩衝（2）

圖 8稍微複雜。首先按照上述過程處理L1部分。存在一種情況，經過若干個包處理之後，L1不足一個包，或者不足一個包頭。如果這時（L1+L2）足夠一個包的長度，就需要繼續處理。另外申請一個最大包長度的記憶體區pTemp，把L1部分和L2的一部分複製到pTemp，然後執行解包過程。

經過上述解包之後，pRead就轉向pRingBuf到pWrite之間的某個位置，從而回歸情況圖 6，繼續按照圖 6部分執行解包。