在socket網路程式設計中，都是端到端通訊，由客戶端埠+服務端埠+客戶端IP+服務端IP+傳輸協議組成的五元組可以明確的標識一條連線。在TCP的socket程式設計中，傳送端和接收端都有成對的socket。傳送端為了將多個發往接收端的包，更加高效的的發給接收端，於是採用了優化演算法（Nagle演算法），將多次間隔較小、資料量較小的資料，合併成一個數據量大的資料塊，然後進行封包。那麼這樣一來，接收端就必須使用高效科學的拆包機制來分辨這些資料。

　　TCP粘包就是指傳送方傳送的若干包資料到達接收方時粘成了一包，從接收緩衝區來看，後一包資料的頭緊接著前一包資料的尾，出現粘包的原因是多方面的，可能是來自發送方，也可能是來自接收方。

　　原因

　　（1）傳送方原因

　　TCP預設使用Nagle演算法（主要作用：減少網路中報文段的數量），而Nagle演算法主要做兩件事：只有上一個分組得到確認，才會傳送下一個分組；收集多個小分組，在一個確認到來時一起傳送。Nagle演算法造成了傳送方可能會出現粘包問題

　　（2）接收方原因

　　TCP接收到資料包時，並不會馬上交到應用層進行處理，或者說應用層並不會立即處理。實際上，TCP將接收到的資料包儲存在接收快取裡，然後應用程式主動從快取讀取收到的分組。這樣一來，如果TCP接收資料包到快取的速度大於應用程式從快取中讀取資料包的速度，多個包就會被快取，應用程式就有可能讀取到多個首尾相接粘到一起的包。

　　什麼時候需要處理粘包現象

　　如果傳送方傳送的多組資料本來就是同一塊資料的不同部分，比如說一個檔案被分成多個部分發送，這時當然不需要處理粘包現象

　　如果多個分組毫不相干，甚至是並列關係，那麼這個時候就一定要處理粘包現象了

　　如何處理粘包現象

　　（1）傳送方

　　對於傳送方造成的粘包問題，可以通過關閉Nagle演算法來解決，使用TCP_NODELAY選項來關閉演算法。

　　（2）接收方

　　接收方沒有辦法來處理粘包現象，只能將問題交給應用層來處理。

　　應用層的解決辦法簡單可行，不僅能解決接收方的粘包問題，還可以解決傳送方的粘包問題。

　　解決辦法：迴圈處理，應用程式從接收快取中讀取分組時，讀完一條資料，就應該迴圈讀取下一條資料，直到所有資料都被處理完成，但是如何判斷每條資料的長度呢？

　　格式化資料：每條資料有固定的格式（開始符，結束符），這種方法簡單易行，但是選擇開始符和結束符時一定要確保每條資料的內部不包含開始符和結束符。

　　傳送長度：傳送每條資料時，將資料的長度一併傳送，例如規定資料的前4位是資料的長度，應用層在處理時可以根據長度來判斷每個分組的開始和結束位置。

　　UDP會不會產生粘包問題

　　TCP為了保證可靠傳輸並減少額外的開銷（每次發包都要驗證），採用了基於流的傳輸，基於流的傳輸不認為訊息是一條一條的，是無保護訊息邊界的（保護訊息邊界：指傳輸協議把資料當做一條獨立的訊息在網上傳輸，接收端一次只能接受一條獨立的訊息）。

　　UDP則是面向訊息傳輸的，是有保護訊息邊界的，接收方一次只接受一條獨立的資訊，所以不存在粘包問題。

　　舉個例子：有三個資料包，大小分別為2k、4k、6k，如果採用UDP傳送的話，不管接受方的接收快取有多大，我們必須要進行至少三次以上的傳送才能把資料包傳送完，但是使用TCP協議傳送的話，我們只需要接受方的接收快取有12k的大小，就可以一次把這3個數據包全部發送完畢。