解決TCP網路傳輸“粘包”問題

當前在網路傳輸應用中，廣泛採用的是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