基于TCP／IP協議棧的數據包分片技術

孫衛佳， 許永康

（長春工業大學 計算機科學與工程學院，吉林 長春 130012）

0 引 言

隨著Internet的飛速發展，在網絡上看電影、電視劇，以及網絡視頻聊天等傳輸音視頻數據非常常見，但是目前的網絡環境并不理想，使得用戶一旦處在網絡環境不太好的時間段或者空間段，音視頻應用的性能急劇降低，讓用戶覺得“很卡”。

為此，文中嘗試開發了一個音視頻聊天系統，使用TCP／IP協議棧的分片技術把數據包進行分片，并在接收端對其進行重組。眾所周知，TCP／IP本身是有內部分片的［1］，但是其大小不能大于65 535字節，并且只能按照默認的1 514字節的大小在以太網中進行傳輸，但是，網絡傳輸時延、路由器處理時延、丟包率等網絡參數均與數據包長度相關［2］，1 514字節的長度在網絡環境良好時，可以使音視頻應用具有良好的效果，這一點在我們的音視頻聊天系統中可以看到，但是一旦網絡環境不好，可用帶寬減小的時候，只依靠IP本身的分片已經難以滿足用戶的需求［3］。

1 相關工作

文中的主要工作是先構建一個音視頻聊天系統，可以讓用戶在系統中進行音視頻聊天，在這個過程中，自然會涉及到音視頻數據的大量傳輸。本系統視頻使用FFMPEG的類庫對視頻從攝像頭進行采集，將其解碼為YUV420P的數據，然后使用H.264編碼，將一幀一幀的視頻數據通過分片傳輸使用Winpcap類庫中的pcap＿sendpacket（）函數構建一個發送隊列［4］，將其發送到客戶端，因為pcap＿sendpacket（）是發送的數據包隊列，該隊列保存在內核級的緩沖區，可以減少I／O上下文的交換，客戶端首先進行重組，將之前自己分片的數據重組為完整的一幀H.264數據，然后將其解碼，將H.264的數據變為YUV數據，然后再將YUV數據通過SDL類庫根據用戶的需要顯示到MFC中的Picture控件中，當然也可以使用SDL本身的窗口進行播放。

音頻方面使用Windows的API，Waveinopen（）打開音頻設備，采集到PCM格式的音頻數據，設置好采樣率、信道、雙工／非雙工，再次使用FFEPEG中的函數編碼為AAC格式的數據，同樣用上文所描述的方法傳輸到客戶端，客戶端進行重組之后，通過回調函數將收到的重組完的AAC數據解碼為PCM數據，同樣通過SDL播放出來。

2 核心技術

核心技術為基于TCP／IP協議棧的分片以及重組。

2.1 分片技術

TCP／IP協議棧本身有一個重要功能，對數據量過大的數據進行分片，IP首部之內有三個字段與分片相關：標識字段，MF位，片偏移。其中標識字段是區分不同的數據包的，具體到系統中就是用來區分一幀與下一幀的視頻數據，其中有P幀、B幀，在分片的時候是一視同仁的，只是大小不同而已。但是在編碼的時候這個比較重要。

MF位代表還再不再分片，我們分片的前幾片，MF位為0X01，表示還有分片，片偏移是一個能被8整除的數，標識距離第一片的偏移位，當然最后一片的片偏移達到最大，MF位為0，表示不再分片。

數據包分片情況如圖1所示。

圖1 數據包分片情況

圖1 為在WIRESHARK中截取到的圖片，通過Winpcap編程將每一片的以太網首部（14字節）、IP首部（一般為20字節）、UDP首部以及UDP偽首部加入到數據前面，封裝為一個完整的數據包，其中以太網首部由Windows API中的函數SENDARP獲得，其中源MAC可以由Winpcap所提供的鏈表由本機IP所獲得，GetAdaptersInfo（pAdapterInfo，＆ulOutBufLen）［5］，由此函數可得所需要的IP以及MAC，因為一個網卡都可能有不同的IP，假如使用Windows的API中的函數通過計算機名稱獲得IP的話，可能存在你所用的IP和鏈表獲得的IP不一致的情況，至于對方的IP地址，是根據用戶需要選擇的，Mac地址則可以通過SENDARP獲得，在以太網首部中，還需要填充IP協議類型，一般為IPV4。

在IP首部中，協議類型中可以指定為UDP，因為UDP相對于TCP可以比較實時地傳輸音視頻數據，TTL為數據包的生存時間，表示允許經過的路由器跳數，片偏移則由數據部分的大小和首部長度共同決定，并且需要計算校驗和［6］。如果校驗不正確，是發送不成功的。在UDP首部中，可以指定IP地址、源端口和目的端口等信息，本系統暫時是提前定好的端口號。IP地址等信息同上方式［7］。

本系統中，由編碼好的H.264視頻數據以及AAC音頻數據傳到分片的方法int fragment（unsigned char＊temp，int size22）中，數據包總大小MTU的限制的算法會在后文中介紹，由此大小可以計算出分片的個數，并為每一片指定一個索引號INDEX，這里分兩種情況：

1）普通情況：數據部分總大小不能被MTU整除。

其中fragment為每一片的大小，到最后一片的時候該變量為總大小與分片大小的余數，并且把FLAGM值設為TRUE。

2）整除情況：這種情況發生的比較少，但是由于數據量大，還是會經常發生：

此時，最后一片大小與前幾片一樣。然后加上IP首部、以太網首部、UDP首部，至于添加的方法上文已經提到，不再贅述。下面將IP首部中的重要參數進行實時變化，例如非最后一片的時候，MF位為1，并且指定本分片的實際大小。

將IP首部、以太網首部、UDP首部放到計算校驗和的函數中，得出結果。這是其中的一片，然后用Winpcap的數據包發送函數，pcap＿sendpacket（）或者pcap＿sendqueue＿queue將數據包發送出去，其中第一個函數為簡單的發送單個數據包，比較簡單，但是效率不如下面那個函數，第二個發送數據包隊列的函數，先構建一個發送隊列，然后將其發送，其中隊列保存在內核級緩沖區，減少上下文交換，發送完畢后，將隊列所申請的資源清零［8］。

至此，我們完成了數據包的手動分片，可以將音視頻數據任意分割大小，至于MTU，Maximum Transmission Unit（最大傳輸單元）這個數值的設定，多少合適，文中應用了統計學中的線性回歸的方法，通過大量的測量，將不同長度的數據包在不同的網絡環境下的延遲插入到SQLSERVER數據庫中。

數據包延遲關系如圖2所示。

圖2 數據包延遲關系

測量了將近10萬條數據，然后用線性回歸的方法回歸出一個函數：MTU＝timeout／0.003 5；并且根據此式可以實時地調整數據包的大小。通過VPS算法，每隔一段時間發送一個探測報文，測試延遲，然后通過SETTIMER函數調整數據包的大小，并且定義回調函數來計算MTU的值，數據線性回歸如圖3所示。

圖3 數據線性回歸

圖中：X軸為數據包大小，Y軸為延遲的大小。

2.2 重組技術

文中手動進行了分片，自然就要進行重組，因為IP協議棧并不會幫你完成這件事，由于文中用Winpcap發送，也用Winpcap進行接收，使用Winpcap過濾的時候需要先設定打開數據包的網絡接口為混雜模式，表示接收一切流過網卡的數據包，還有捕獲數據包的字節數，讀取超時時間，這里設定為－1表示不管有沒有數據包都立即返回，設置為0表示不接收到數據包則不會返回，當然，為了符合用戶的不同網絡環境，也可以根據延遲設定此值。然后要進行過濾條件的編譯，Winpcap中的過濾條件是已聲明的謂詞為詞法基礎，他包含了一個過濾表達式，pcap＿compile（）把這個表達式編譯成過濾器，如果沒有給出表達式，那么網絡中所有數據包均會被過濾引擎所認可，關于表達式原語以及編譯表達式的技巧，我們會在另一篇文章中加以說明［9］。然后打開網卡設備，進行過濾，通過非回調的方式獲得網卡的句柄，并且由res＝pcap＿next＿ex（fp1，＆header，＆pkt＿data）這個函數進行捕獲我們之前分片的數據包，獲得正確的數據之后，即可通過MEMCPY進行重組［10］。

3 結果分析

此系統有兩個版本：

1）沒有經過手動分片的，直接用數據包套接字進行收發，通過實驗可知，在網絡較好時，表現不錯。但是網絡不是很好的時候，會有卡的情況，占用的網絡帶寬為1.5Mbps；

2）我們分片重組的版本，不管網絡如何都不會出現卡頓的情況，并且占用的網絡帶寬較小。

4 結 語

分片重組技術在網絡日益重要的今天具有很好的應用前景，可以在一定程度上緩解網絡狀況，使用戶獲得更好的體驗。

［1］ Richard Stevens W.TCP／IP協 議 詳 解 卷 二［J］.2014，110（1）：121－161.

［2］ 陳敏.網絡實時視頻傳輸研究［D］.廣州：華南理工大學，2004.

［3］ Lowerkamp B，Tierney B，Cotterll L，et al.A hierarchy of network performance charcteristics for grid applications and services［J］.Proposed Recommendation，2003，95（2）：1110－1115.

［4］ Wang Y.Error control and concealment for video communicaion：AReview［J］.Proceding of the IEEE，2000，502（2）：1100－1156.

［5］ Monetesino F，Pouzols.Comparative analysis of active bandwidth estimation tools procof passive and active measurement workshop［M］.New York：ACM，2004：175－184.

［6］ 王小凡.復雜網絡及其應用［J］.科學技術哲學，2004（8）：58－70.

［7］ Issberg D S.Rise of the stupid network［J］.Computer Telephony，2009（2）：60－65.

［8］ Downey A B.General aspects of quality of service and network performance indigital networks［J］.Including ISDNs，2007（1）：22－25.

［9］ Paxon V，Almes G，Mahdavi J，et al.Frmework for IP performance［J］.METRICS Ietf.Rfc.，1998（1）：2330－2340.

［10］ ZHANG Y.Duffield N on the constrancy of internet path properties［C］／／Proceedings of the 1st ACM SIGCOMM Workshop on INTERNET Measruement.2010（1）：3045－3056.