[轉] TCP粘包問題

粘包問題︰
一、TCP協議簡介
　　TCP是一個面向連接的傳輸層協議，雖然TCP不屬于ISO製定的協議集，但由於其在商業界和工業界的成功應用，它已成為事實上的網路標準，廣泛應用于各種網路主機間的通信。 作為一個面向連接的傳輸層協議，TCP的目標是為用戶提供可靠的端到端連接，保證訊息有序無誤的傳輸。它除了提供基本的數據傳輸功能外，還為保證可靠性採用了數據編號、校驗和計算、數據確認等一系列措施。它對傳送的每個數據位元組都進行編號，並請求接收方回傳確認訊息（ACK）。發送方如果在規定的時間內沒有收到數據確認，就重傳該數據。數據編號使接收方能夠處理數據的失序和重複問題。數據誤碼問題透過在每個傳輸的數據段中增加校驗和予以解決，接收方在接收到數據后檢查校驗和，若校驗和有誤，則丟棄該有誤碼的數據段，並要求發送方重傳。流量控制也是保證可靠性的一個重要措施，若無流控，可能會因接收緩沖區溢出而丟失大量數據，導致許多重傳，造成網路擁塞惡性循環。TCP採用可變窗口進行流量控制，由接收方控制發送方發送的數據量。 TCP為用戶提供了高可靠性的網路傳輸服務，但可靠性保障措施也影響了傳輸效率。因此，在實際工程應用中，只有關鍵數據的傳輸才採用TCP，而普通數據的傳輸一般採用高效率的UDP。

二、粘包問題分析與對策
　　TCP粘包是指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩沖區看，后一包數據的頭緊接著前一包數據的尾。 出現粘包現象的原因是多方面的，它既可能由發送方造成，也可能由接收方造成。發送方引起的粘包是由TCP協議本身造成的，TCP為提升傳輸效率，發送方往往要收集到足夠多的數據后才發送一包數據。若連續幾次發送的數據都很少，通常TCP會根據優化算法把這些數據合成一包后一次發送出去，這樣接收方就收到了粘包數據。接收方引起的粘包是由於接收方用戶進程不及時接收數據，從而導致粘包現象。這是因為接收方先把收到的數據放在系統接收緩沖區，用戶進程從該緩沖區取數據，若下一包數據到達時前一包數據尚未被用戶進程取走，則下一包數據放到系統接收緩沖區時就接到前一包數據之后，而用戶進程根據預先設定的緩沖區大小從系統接收緩沖區取數據，這樣就一次取到了多包數據（圖1所示）。 粘包情況有兩種，一種是粘在一起的包都是完整的數據包（圖1、圖2所示），另一種情況是粘在一起的包有不完整的包（圖3所示），此處假設用戶接收緩沖區長度為m個位元組。 不是所有的粘包現象都需要處理，若傳輸的數據為不帶架構的連續流數據（如文件傳輸），則不必把粘連的包分開（簡稱分包）。但在實際工程應用中，傳輸的數據一般為帶架構的數據，這時就需要做分包處理。 在處理定長架構數據的粘包問題時，分包算法比較簡單；在處理不定長架構數據的粘包問題時，分包算法就比較複雜。特別是如圖3所示的粘包情況，由於一包數據內容被分在了兩個連續的接收包中，處理起來難度較大。實際工程應用中應盡量避免出現粘包現象。 為了避免粘包現象，可採取以下幾種措施。一是對于發送方引起的粘包現象，用戶可透過編程設置來避免，TCP提供了強製數據立即傳送的操作指令push，TCP軟體收到該操作指令后，就立即將本段數據發送出去，而不必等待發送緩沖區滿；二是對于接收方引起的粘包，則可透過優化程式設計、精簡接收進程工作量、提升接收進程優先級等措施，使其及時接收數據，從而盡量避免出現粘包現象；三是由接收方控制，將一包數據按架構字段，人為控制分多次接收，然後合併，透過這種手段來避免粘包。 以上提到的三種措施，都有其不足之處。第一種編程設置方法雖然可以避免發送方引起的粘包，但它關閉了優化算法，降低了網路發送效率，影附應用程式的性能，一般不建議使用。第二種方法只能減少出現粘包的可能性，但並不能完全避免粘包，當發送頻率較高時，或由於網路突發可能使某個時間段數據包到達接收方較快，接收方還是有可能來不及接收，從而導致粘包。第三種方法雖然避免了粘包，但應用程式的效率較低，對實時應用的場合不適合。 一種比較周全的對策是︰接收方創建一預處理線程，對接收到的數據包進行預處理，將粘連的包分開。對這種方法我們進行了實驗，證明是高效可行的。

三、編程與實現
　　 1．實現框架 實驗網路通信程式採用TCP/IP協議的Socket API編程實現。Socket是面向客戶機/伺服器模型的。TCP實現框架如圖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．分包算法 針對三種不同的粘包現象，分包算法分別採取了相應的解決辦法。其基本思路是首先將待處理的接收數據流（長度設為m）強行轉換成預定的架構數據形式，並從中取出架構數據長度字段，即圖5中的n，而后根據n計算得到第一包數據長度。
1)若n=m，則表明數據流內容恰好是一完整架構數據，直接將其存入臨時緩沖區即可。
2)若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），幾乎不影附應用程式的正常工作。

Trackback: http://blog.csdn.net/axes/articles/328543.aspx