解決tcp網路傳輸「粘包」問題
原文出處：http://www.ciw.com.cn/
當前在網路傳輸應用中，廣泛採用的是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所示。
圖42．實驗硬體環境：
伺服器：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所示：
圖55．分包演算法
針對三種不同的粘包現象，分包演算法分別採取了相應的解決辦法。其基本思路是首先將待處理的接收資料流（長度設為m）強行轉換成預定的結構資料形式，並從中取出結構資料長度字段，即圖5中的n，而後根據n計算得到第一包資料長度。
1)若n3)若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），幾乎不影響應用程式的正常工作。
TCP連線時CSocket粘包問題的解決方法
解決tcp網路傳輸 粘包 問題原文出處 當前在網路傳輸應用中，廣泛採用的是tcp ip通訊協議及其標準的socket應用開發程式設計介面 api tcp ip傳輸層有兩個並列的協議 tcp和udp。其中tcp transport control protocol，傳輸控制協議 是面向連線的，提供高可...
TCP連線，傳輸資料時的粘包問題討論
第乙個需要討論的大概就是粘包問題了。因為這個是tcp的個性問題，udp通訊時不存在這個問題的。首先看一下什麼叫粘包 客戶端採取與伺服器的長連線方式建立通訊 open write read write read write read close 即建立連線之後進行多次讀寫操作，最後才關閉。而且不是檔案...
TCP粘包 拆包
tcp粘包 拆包 客戶端發服務端傳送了兩個資料報a和b 粘包 服務端一次性接收到了a和b 拆包 服務端第一次接收了a和b的一部分，第二次接收到了b的剩餘部分 粘包 拆包原因 1 應用程式寫入的位元組大小 socket傳送緩衝區大小 2 tcp分段 tcp data部分的大小 mss max segm...