http://www.vckbase.com/index.php/wv/10
http://blog.csdn.net/zlzlei/article/details/7689409
文章一：
當前在網絡傳輸應用中，廣泛采用的是TCP/IP通信協議及其標准的socket應用開發編程接口（API）。TCP/IP傳輸層有兩個並列的協議：TCP和UDP。其中TCP（transport control protocol，傳輸控制協議）是面向連接的，提供高可靠性服務。UDP（user datagram protocol，用戶數據報協議）是無連接的，提供高效率服務。在實際工程應用中，對可靠性和效率的選擇取決於應用的環境和需求。一般情況下，普通數據的網絡傳輸采用高效率的udp，重要數據的網絡傳輸采用高可靠性的TCP。
在應用開發過程中，筆者發現基於TCP網絡傳輸的應用程序有時會出現粘包現象（即發送方發送的若干包數據到接收方接收時粘成一包）。針對這種情況，我們進行了專題研究與實驗。本文重點分析了TCP網絡粘包問題，並結合實驗結果提出了解決該問題的對策和方法，供有關工程技術人員參考。
一、TCP協議簡介
TCP是一個面向連接的傳輸層協議，雖然TCP不屬於iso制定的協議集，但由於其在商業界和工業界的成功應用，它已成為事實上的網絡標准，廣泛應用於各種網絡主機間的通信。
作為一個面向連接的傳輸層協議，TCP的目標是為用戶提供可靠的端到端連接，保證信息有序無誤的傳輸。它除了提供基本的數據傳輸功能外，還為保證可靠性采用了數據編號、校驗和計算、數據確認等一系列措施。它對傳送的每個數據字節都進行編號，並請求接收方回傳確認信息（ack）。發送方如果在規定的時間內沒有收到數據確認，就重傳該數據。數據編號使接收方能夠處理數據的失序和重復問題。數據誤碼問題通過在每個傳輸的數據段中增加校驗和予以解決，接收方在接收到數據后檢查校驗和，若校驗和有誤，則丟棄該有誤碼的數據段，並要求發送方重傳。流量控制也是保證可靠性的一個重要措施，若無流控，可能會因接收緩沖區溢出而丟失大量數據，導致許多重傳，造成網絡擁塞惡性循環。TCP采用可變窗口進行流量控制，由接收方控制發送方發送的數據量。
TCP為用戶提供了高可靠性的網絡傳輸服務，但可靠性保障措施也影響了傳輸效率。因此，在實際工程應用中，只有關鍵數據的傳輸才采用TCP，而普通數據的傳輸一般采用高效率的udp。
二、粘包問題分析與對策
TCP粘包是指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩沖區看，后一包數據的頭緊接着前一包數據的尾。
出現粘包現象的原因是多方面的，它既可能由發送方造成，也可能由接收方造成。發送方引起的粘包是由TCP協議本身造成的，TCP為提高傳輸效率，發送方往往要收集到足夠多的數據后才發送一包數據。若連續幾次發送的數據都很少，通常TCP會根據優化算法把這些數據合成一包后一次發送出去，這樣接收方就收到了粘包數據。接收方引起的粘包是由於接收方用戶進程不及時接收數據，從而導致粘包現象。這是因為接收方先把收到的數據放在系統接收緩沖區，用戶進程從該緩沖區取數據，若下一包數據到達時前一包數據尚未被用戶進程取走，則下一包數據放到系統接收緩沖區時就接到前一包數據之后，而用戶進程根據預先設定的緩沖區大小從系統接收緩沖區取數據，這樣就一次取到了多包數據（圖1所示）。
圖1
圖2
圖3
粘包情況有兩種，一種是粘在一起的包都是完整的數據包（圖1、圖2所示），另一種情況是粘在一起的包有不完整的包（圖3所示），此處假設用戶接收緩沖區長度為m個字節。
不是所有的粘包現象都需要處理，若傳輸的數據為不帶結構的連續流數據（如文件傳輸），則不必把粘連的包分開（簡稱分包）。但在實際工程應用中，傳輸的數據一般為帶結構的數據，這時就需要做分包處理。
在處理定長結構數據的粘包問題時，分包算法比較簡單；在處理不定長結構數據的粘包問題時，分包算法就比較復雜。特別是如圖3所示的粘包情況，由於一包數據內容被分在了兩個連續的接收包中，處理起來難度較大。實際工程應用中應盡量避免出現粘包現象。
為了避免粘包現象，可采取以下幾種措施。一是對於發送方引起的粘包現象，用戶可通過編程設置來避免，TCP提供了強制數據立即傳送的操作指令push，TCP軟件收到該操作指令后，就立即將本段數據發送出去，而不必等待發送緩沖區滿；二是對於接收方引起的粘包，則可通過優化程序設計、精簡接收進程工作量、提高接收進程優先級等措施，使其及時接收數據，從而盡量避免出現粘包現象；三是由接收方控制，將一包數據按結構字段，人為控制分多次接收，然后合並，通過這種手段來避免粘包。
以上提到的三種措施，都有其不足之處。第一種編程設置方法雖然可以避免發送方引起的粘包，但它關閉了優化算法，降低了網絡發送效率，影響應用程序的性能，一般不建議使用。第二種方法只能減少出現粘包的可能性，但並不能完全避免粘包，當發送頻率較高時，或由於網絡突發可能使某個時間段數據包到達接收方較快，接收方還是有可能來不及接收，從而導致粘包。第三種方法雖然避免了粘包，但應用程序的效率較低，對實時應用的場合不適合。
一種比較周全的對策是：接收方創建一預處理線程，對接收到的數據包進行預處理，將粘連的包分開。對這種方法我們進行了實驗，證明是高效可行的。
三、編程與實現
1．實現框架
實驗網絡通信程序采用TCP/IP協議的socket api編程實現。socket是面向客戶機/服務器模型的。TCP實現框架如圖4所示。
圖4
2．實驗硬件環境：
服務器：pentium 350 微機
客戶機：pentium 166微機
網絡平台：由10兆共享式hub連接而成的局域網
3．實驗軟件環境：
操作系統：windows 98
編程語言：visual c++ 5.0
4．主要線程
編程采用多線程方式，服務器端共有兩個線程：發送數據線程、發送統計顯示線程。客戶端共有三個線程：接收數據線程、接收預處理粘包線程、接收統計顯示線程。其中，發送和接收線程優先級設為thread_priority_time_critical（最高優先級），預處理線程優先級為thread_priority_above_normal（高於普通優先級），顯示線程優先級為thread_priority_normal（普通優先級）。
實驗發送數據的數據結構如圖5所示：
圖5
5．分包算法
針對三種不同的粘包現象，分包算法分別采取了相應的解決辦法。其基本思路是首先將待處理的接收數據流（長度設為m）強行轉換成預定的結構數據形式，並從中取出結構數據長度字段，即圖5中的n，而后根據n計算得到第一包數據長度。
1)若n
2)若n=m，則表明數據流內容恰好是一完整結構數據，直接將其存入臨時緩沖區即可。
3)若n>m，則表明數據流內容尚不夠構成一完整結構數據，需留待與下一包數據合並后再行處理。
對分包算法具體內容及軟件實現有興趣者，可與作者聯系。
四、實驗結果分析
實驗結果如下：
1．在上述實驗環境下，當發送方連續發送的若干包數據長度之和小於1500b時，常會出現粘包現象，接收方經預處理線程處理后能正確解開粘在一起的包。若程序中設置了“發送不延遲”：（setsockopt (socket_name，ipproto_tcp，tcp_nodelay，(char *) &on，sizeof on) ，其中on=1），則不存在粘包現象。
2．當發送數據為每包1kb～2kb的不定長數據時，若發送間隔時間小於10ms，偶爾會出現粘包，接收方經預處理線程處理后能正確解開粘在一起的包。
3．為測定處理粘包的時間，發送方依次循環發送長度為1.5kb、1.9kb、1.2kb、1.6kb、1.0kb數據，共計1000包。為制造粘包現象，接收線程每次接收前都等待10ms，接收緩沖區設為5000b，結果接收方收到526包數據，其中長度為5000b的有175包。經預處理線程處理可得到1000包正確數據，粘包處理總時間小於1ms。
實驗結果表明，TCP粘包現象確實存在，但可通過接收方的預處理予以解決，而且處理時間非常短（實驗中1000包數據總共處理時間不到1ms），幾乎不影響應用程序的正常工作。
文章二：
以前老在網上找別人說recv什么時候返回，要么說的很籠統，要么完全覺得不靠譜，最近還是自己做個試驗分析一下吧：
關於PUSH位的應用
PUSH位就是用來通告接收方立即將收到的報文連同TCP接收緩存里的數據遞交應用進程處理。一般會出現在發送方封裝最后一個應用字段的TCP報文中，針對TCP交互式應用，則只要封裝有應用字段的TCP報文，均會將PUSH位置一，當然，應用程序的開發者，可以根據需要，在某個應用功能模塊或某個應用操作時，將所有封裝應用字段的TCP報文PUSH位置一，以提高交互雙方的處理效率，這在理論上應該也是可行的。
測試1.
每次發送大小：1024
每次接收大小：32
結果：pack1
每send發送一個包，包中數據大小1024，帶PUSH標志
每次接收滿32后recv函數返回。
測試2.
每次發送大小：1024
每次接收大小：2048
結果：pack2
每send發送一個包，包中數據大小1024，帶PUSH標志
每次接收滿1024后recv函數返回。
測試3.
每次發送大小：20480
每次接收大小：10240
結果：pack3
每send發送兩個包，包中數據大小為16384（TCP分片大小，建立連接時商定）與4096，僅最后一個包帶PUSH標志
第一次接收滿10240后recv函數返回
第二次接收6144后recv函數返回（6144+10240=16384）
第三次接收4096后recv函數返回
Recv >>> [1]10240:10240
Recv >>> [2]10240:6144
Recv >>> [3]10240:4096
Recv >>> [4]10240:10240
Recv >>> [5]10240:6144
Recv >>> [6]10240:4096
測試4.
每次發送大小：20480
每次接收大小：20480
結果：pack4
每send發送兩個包，包中數據大小為16384（TCP分片大小，建立連接時商定）與4096，僅最后一個包帶PUSH標志
第一次接收16384后recv函數返回
第二次接收4096后recv函數返回
Recv >>> [1]20480:16384
Recv >>> [2]20480:4096
Recv >>> [3]20480:16384
Recv >>> [4]20480:4096
測試5.
每次發送大小：400000
每次接收大小：10240
結果：pack5
發送時除最后一個包不夠意外，數據都是按照16384的包大小發送，發送過程中經常性接收窗口滿。
接收過程初期按照16384包大小接收，后期無規律：
Recv >>> [1]10240:10240
Recv >>> [2]10240:6144 //A//滿16384
Recv >>> [3]10240:10240
Recv >>> [4]10240:6144 //B//滿16384，從開始到此滿32768（滑動窗口總大小）
Recv >>> [5]10240:10240
Recv >>> [6]10240:10240
Recv >>> [7]10240:10240
Recv >>> [8]10240:2048 //C//從開始到此處滿65536（兩個滑動窗口總大小）
Recv >>> [9]10240:10240
Recv >>> [10]10240:6144 //D//滿16384
Recv >>> [11]10240:10240
Recv >>> [12]10240:6144 //E//滿16384
Recv >>> [13]10240:10240 //F//從此往后均能收滿整個buffer
Recv >>> [14]10240:10240
。。。。。。都是10240:10240
Recv >>> [40]10240:10240
Recv >>> [41]10240:8192 //E//
Recv >>> [42]10240:6784
測試6.
每次發送大小：400000
每次接收大小：10000
結果：pack6
發送時除最后一個包不夠以外，數據都是按照16384的包大小發送，發送過程中經常性接收窗口滿。
接收過程初期按照16384包大小接收，后期無規律：
Recv >>> [1]10000:10000
Recv >>> [2]10000:6384
Recv >>> [3]10000:10000
Recv >>> [4]10000:6384
Recv >>> [5]10000:10000
Recv >>> [6]10000:10000
Recv >>> [7]10000:10000
Recv >>> [8]10000:2768
Recv >>> [9]10000:10000
Recv >>> [10]10000:6384
Recv >>> [11]10000:10000
Recv >>> [12]10000:6384
Recv >>> [13]10000:10000
。。。。。。都是10000:10000
Recv >>> [41]10000:10000
Recv >>> [42]10000:4912
Recv >>> [43]10000:6784
測試7.
每次發送大小：32，發10000次
每次接收大小：102400
結果：pack7
發送過程中大部分包都以32大小發送，但也有部分包被合在了一起發送，發送的每個包都帶PUSH標志
接收過程中大部分包都以32大小接收，但也有接收大於32的時候，並且與發送大於32的包並無任何關系。
Recv >>> [1]102400:32
Recv >>> [2]102400:32
Recv >>> [3]102400:32
。。。。。。都是102400:32
Recv >>> [92]102400:32
Recv >>> [93]102400:49184
Recv >>> [94]102400:32
。。。。。。都是102400:32
Recv >>> [151]102400:32
Recv >>> [152]102400:32
Recv >>> [153]102400:22720
Recv >>> [154]102400:32
。。。。。。都是102400:32
Recv >>> [268]102400:32
Recv >>> [271]102400:47840
Recv >>> [272]102400:32
。。。。。。都是102400:32
Recv >>> [397]102400:32
Recv >>> [398]102400:32
Recv >>> [399]102400:59776
Recv >>> [400]102400:32
。。。。。。都是102400:32
Recv >>> [523]102400:32
Recv >>> [526]102400:54208
Recv >>> [527]102400:32
。。。。。。都是102400:32
Recv >>> [630]102400:32
Recv >>> [631]102400:32
Recv >>> [632]102400:65568
。。。。。。都是102400:32
Recv >>> [652]102400:32
Recv >>> [653]102400:32
分析：用戶從接收緩存區讀取內容與kernel向接收緩存區填充內容這兩個過程是互斥的，
recv只從接收緩存區中獲取一次內容，並且也只關心自己獲取時接收緩存區有多少內容：
a、如果當時緩存區中沒有數據，則recv進入阻塞狀態，等待kernel向緩存區被填入數據后重新激活。
b、如果當時緩存區中的數據比用戶接收使用的buffer大，則填滿buffer后recv函數返回。
c、如果當時緩存區中的數據比用戶接收使用的buffer小，則取走緩存區中的所有數據后recv函數返回。
kernel向接收緩存區填充則是收到數據包后到自己的時間片並且緩存區不在被讀，則將拿到的包內容全部放入緩存區中。
這里有個參數，決定了是否可讀，當緩沖區中的數據長度大於等於SO_RCVLOWAT時，recv函數才認為皇后從去中有數據，也就是socke可讀，然后recv將數據從kernel 拷貝到應用層。
Socket可讀/寫的常見情況分析：
select()返回sockfd可讀：
1、Receive緩沖區的數據大於或等於low-water mark的值。low-water mark的值可通過SO_RCVLOWAT選項控制，默認是1。 (即讀緩沖區中有數據)
2、TCP連接接收到FIN，即Read half of the connections is closed。此時對sockfd的讀操作將返回0，即EOF。
3、如果sockfd是一個監聽套接字，則表明有新連接，可調用accept()函數建立新連接。
4、Socket出錯，此時對sockfd的讀操作將返回-1。
select()返回sockfd可寫：
1、Send緩沖區的數據大於或等於low-water mark的值。low-water mark的值可通過SO_SNDLOWAT選項控制，默認是2048。 (即緩沖區有數據)
2、Write half of the connection is closed，對sockfd的寫操作將產生SIGPIPE信號。
3、對非阻塞的sockfd調用connect()，connect()完成或失敗。
4、Socket出錯，此時對sockfd的寫操作將返回-1。
這樣就可以解釋測試5中的現象了：
a、kernel第一二次都只收到了一個16384大小的包，所以接收的A處與B處都收到了整個數據包
b、慢慢的包陸陸續續的到來kernel第三次收到了兩個16384大小的包，填滿了整個緩存區，所以接收的C處，
在用戶的時間片內用戶收走了緩存區的全部數據。
c、接下來數據蜂擁而至，導致緩存區一直處於滿的狀態，所以后來的接收都能收滿用戶buffer。
d、接收的E處接收完整個緩存區，隨后接收收尾的包
為了驗證以上推斷，進行了測試6。
測試7驗證了快速發送時的發送接收情況，證明了send發送與recv接收過程完全沒關系，
即使發送的包帶有PUSH標記，也只能保證每一個包被單獨放入接收緩存區中，無法使recv接收每收到一個包返回。
整個接收過程遵循上面的規則，何時返回，返回多少數據均要看當時緩存區內的數據多少。
像測試7中大部分包每個包都返回只是因為接收比較快導致kernel每次只來得及向接收緩存區中放一個包而已。
結論：
a、不要期待利用TCP協議一方send一次，另一方recv一次的邏輯，這種邏輯是不可靠，也沒有理論依據的
b、在本機進行消息邏輯控制，或者說信令級傳輸，建議還是使用UDP
c、若必須要使用TCP消息傳輸時一定要加同步頭，例如一個固定的值，用來分割數據包或者驗證是否包亂序或越界
三、send行為
默認情況下，send的功能是拷貝指定長度的數據到發送緩沖區，只有當數據被全部拷貝完成后函數才會正確返回，否則進入阻塞狀態或等待超時。如果你想修改這種默認行為，將數據直接發送到目標機器，可以將發送緩沖區大小設為0（或通過TCP_NODELAY禁用Nagle算法），這樣當send返回時，就表示數據已經正確的、完整的到達了目標機器。注意，這里只表示數據到達目標機器網絡緩沖區，並不表示數據已經被對方應用層接收了。
協議層在數據發送過程中，根據對方的滑動窗口，再結合MSS值共同確定TCP報文中數據段的長度，以確保對方接收緩沖區不會溢出。當本方發送緩沖區尚有數據沒有發送，而對方滑動窗口已經為0時，協議層將啟動探測機制，即每隔一段時間向對方發送一個字節的數據，時間間隔會從剛開始的30s調整為1分鍾，最后穩定在2分鍾。這個探測機制不僅可以檢測到對方滑動窗口是否變化，同時也可以發現對方是否有異常退出的情況。
push標志指示接收端應盡快將數據提交給應用層。如果send函數提交的待發送數據量較小，例如小於1460B（參照MSS值確定），那么協議層會將該報文中的TCP頭部的push字段置為1；如果待發送的數據量較大，需要拆成多個數據段發送時，協議層只會將最后一個分段報文的TCP頭部的push字段置1。
四、recv行為
默認情況下，recv的功能是從接收緩沖區讀取(其實就是拷貝)指定長度的數據。如果將接收緩沖區大小設為0，recv將直接從協議緩沖區(滑動窗口區)讀取數據，避免了數據從協議緩沖區到接收緩沖區的拷貝。recv返回的條件有兩種：
1. recv函數傳入的應用層接收緩沖區已經讀滿
2. 協議層接收到push字段為1的TCP報文，此時recv返回值為實際接收的數據長度
協議層收到TCP數據包后(保存在滑動窗口區)，本方的滑動窗口合攏（窗口值減小）；當協議層將數據拷貝到接收緩沖區(滑動窗口區—>接收緩沖區)，或者應用層調用recv接收數據(接收緩沖區—>應用層緩沖區，滑動窗口區—>應用層緩沖區)后，本方的滑動窗口張開(窗口值增大)。收到數據更新window后，協議層向對方發送ACK確認。
協議層的數據接收動作完全由發送動作驅動，是一個被動行為。在應用層沒有任何干涉行為的情況下（比如recv操作等），協議層能夠接收並保存的最大數據大小是窗口大小與接收緩沖區大小之和。Windows系統的窗口大小默認是64K，接收緩沖區默認為8K，所以默認情況下協議層最多能夠被動接收並保存72K的數據。