一，粘包問題詳情

1，只有TCP有粘包現象，UDP永遠不會粘包

你的程序實際上無權直接操作網卡的，你操作網卡都是通過操作系統給用戶程序暴露出來的接口，那每次你的程序要給遠程發數據時，其實是先把數據從用戶態copy到內核態，這樣的操作是耗資源和時間的，頻繁的在內核態和用戶態之前交換數據勢必會導致發送效率降低， 因此socket 為提高傳輸效率，發送方往往要收集到足夠多的數據后才發送一次數據給對方。若連續幾次需要send的數據都很少，通常TCP socket 會根據優化算法把這些數據合成一個TCP段后一次發送出去，這樣接收方就收到了粘包數據。

2，首先需要掌握一個socket收發消息的原理

發送端可以是1k，1k的發送數據而接受端的應用程序可以2k，2k的提取數據，當然也有可能是3k或者多k提取數據，也就是說，應用程序是不可見的，因此TCP協議是面來那個流的協議，這也是容易出現粘包的原因而UDP是面向無連接的協議，每個UDP段都是一條消息，應用程序必須以消息為單位提取數據，不能一次提取任一字節的數據，這一點和TCP是很同的。怎樣定義消息呢？認為對方一次性write/send的數據為一個消息，需要命的是當對方send一條信息的時候，無論鼎城怎么樣分段分片，TCP協議層會把構成整條消息的數據段排序完成后才呈現在內核緩沖區。    

例如基于TCP的套接字客戶端往服務器端上傳文件，發送時文件內容是按照一段一段的字節流發送的，在接收方看來更笨不知道文件的字節流從何初開始，在何處結束。

3，粘包的原因

3-1 直接原因

所謂粘包問題主要還是因為接收方不知道消息之間的界限，不知道一次性提取多少字節的數據所造成的

3-2  根本原因

發送方引起的粘包是由TCP協議本身造成的，TCP為提高傳輸效率，發送方往往要收集到足夠多的數據后才發送一個TCP段。若連續幾次需要send的數據都很少，通常TCP會根據 優化算法 把這些數據合成一個TCP段后一次發送出去，這樣接收方就收到了粘包數據。

3-3 總結

 TCP（transport control protocol，傳輸控制協議）是面向連接的，面向流的，提供高可靠性服務。收發兩端（客戶端和服務器端）都要有一一成對的socket，因此，發送端為了將多個發往接收端的包，更有效的發到對方，使用了優化方法（Nagle算法），將多次間隔較小且數據量小的數據，合并成一個大的數據塊，然后進行封包。這樣，接收端，就難于分辨出來了，必須提供科學的拆包機制。 即面向流的通信是無消息保護邊界的。 UDP（user datagram protocol，用戶數據報協議）是無連接的，面向消息的，提供高效率服務。不會使用塊的合并優化算法，, 由于UDP支持的是一對多的模式，所以接收端的skbuff(套接字緩沖區）采用了鏈式結構來記錄每一個到達的UDP包，在每個UDP包中就有了消息頭（消息來源地址，端口等信息），這樣，對于接收端來說，就容易進行區分處理了。  即面向消息的通信是有消息保護邊界的。 tcp是基于數據流的，于是收發的消息不能為空，這就需要在客戶端和服務端都添加空消息的處理機制，防止程序卡住，而udp是基于數據報的，即便是你輸入的是空內容（直接回車），那也不是空消息，udp協議會幫你封裝上消息頭，實驗略