黃遠峰,宗 平
南京郵電大學軟件學院,江蘇南京 210003
摘 要:UDP滑動窗口協議是一種適用于現代通信系統中板間通信的應用層協議,它采用滑動窗口技術
來保證數據包無重復、無丟包地按序遞交。文中論述了基于UDP的滑動窗口協議并給出了實現方
法,通過測試分析,該協議有效地解決了TCP的高協議處理開銷和UDP的低可靠性之間的矛盾,而
CPU占用率比單獨采用UDP只增加約3%。
關鍵詞:板間通信;UDP;滑動窗口;協議處理開銷;軟交換
1 引 言
以軟交換為代表的現代通信系統中常見的硬件架構是“松耦合”方式的并行多處理器系統[ 1 ] ,多個
處理器模塊之間通過高速以太網連接在一起,每個處理器板由系統槽位上主控處理器板控制并分配不
同的工作,多個處理器板之間通過以太網完成板間通信和消息數據的轉發[ 2 ] 。
軟交換系統中的板間通信承載著信令和板間消息的轉發工作[ 3 ] 。隨著用戶數量的增加和通信質
量的提高,板間通信的負荷越來越大,隨之而來的就是板間通信的可靠性和效率之間的矛盾。由于通信
系統對可靠性的要求非常嚴格,所以板間通信協議首選TCP, TCP為了保證數據包傳輸的正確性,協議
處理開銷高昂[ 4 ] 。起初,當呼叫能力還是萬或十萬數量級時,這個問題并不明顯,但是當呼叫能力達到
百萬乃至千萬數量級時,僅在TCP協議處理上的CPU占用率就高達約40% ,這必然使上層應用薹?br> 玫匠渥愕腃PU資源。為降低板間通信的協議處理開銷,如果把原先建立在TCP上的通信機制移植
到協議處理開銷較低的UDP上,可以使CPU 占用率大大降低,但通信可靠性也隨之降低,出現上層亂
序包、重復包、丟包和產生誤碼等現象[ 5 ] 。表1給出了分別使用TCP和UDP協議時CPU占用率和誤碼
率的比較。
為解決TCP的效率問題和UDP的通信可靠性問題,我們對UDP協議進行改進,在UDP上建立滑
動窗口機制,用于保證數據包無重復、無丟包地按序提交給應用進程, 并能提供擁塞控制能力, 同時
CPU占用率在同等條件下沒有明顯增加。
2 滑動窗口技術
盡管采取滑動窗口技術的協議給傳輸層或數據鏈路層在決定發送、接收數據包的次序方面更多的
自由,但必須保證數據包的按序傳輸[ 6 ] 。發送窗口中的序列號代表已發送但尚未收到確認的數據包,
發送窗口可持續地維持一系列未經確認的數據包。因為發送方窗口內的數據包可能在傳輸過程中丟失
或損壞,所以發送過程必須把發送窗口中的所有數據包保存起來以備重傳。發送窗口一旦達到最大
值,發送過程就必須停止接收新的數據包,直到有空閑緩沖區。接收窗口對應允許接收的數據包,任何
落在接收窗口外的數據包都要丟棄。當序列號等于接收窗口下限的數據包到達時,把它提交給應用程
序并向發送端發送確認,接收窗口前移動一位。發送窗口和接收窗口上下限無需相同,甚至窗口大小
也無需相同[ 7 ] ,發送窗口的大小既可以固定,也可以隨著數據包的發送或接收而增大或縮小,接收窗
口的大小保持固定。
3 UDP滑動窗口協議的設計與實現
軟交換系統中的通信分3種:板內通信、板間通信和機框間通信。板內通信采用操作系統提供的進
程間通信API,機框間通信采用TCP協議,新設計的UDP滑動窗口協議代替原先的TCP為板間通信服
務。雖然從功能上來看該協議屬于傳輸層協議,但從網絡體系結構的角度看,UDP滑動窗口協議是建
立在UDP上的應用層協議,參見圖1,傳輸層使用的仍是UDP,但在應用層使用滑動窗口技術,并通過
模擬TCP的一些機制以保證UDP的低協議處理開銷和獲得高通信可靠性。由于應用環境僅限于板間
通信,所以可以去掉TCP中為適應不同種類的網絡而存在的復雜設計細節以降低協議處理開銷。下面
給出具體設計方法。
3. 1 鏈路管理
UDP滑動窗口協議定義了3種鏈路狀態:初始態(UDPM _ IN IT) 、同步態(UDPM _ SYN ) 、完成態
(UDPM_F IN) 。在鏈路上傳輸的包有3種類型:同步包(UDPM_SYN) 、數據包(UDPM_DATA) 、應答包
(UDPM_ACK) ,考慮到拆包數據包又分為:起始拆包(UDPM_FRG|UDPM_START) 、中間拆包(UDPM_
FRG) 、結束拆包(UDPM_FRG|UDPM_END) 。同步包、數據包在發送時占一個發送序號,應答包不占
序號。
UDP滑動窗口協議采用3次握手來建立鏈接,通過發送同步包來實現[ 8 ] ,鏈接建立的過程見圖2。
為了保證數據包的正常發送,需要進行鏈路檢測。鏈路上有數據包發送時,發送端超時重發UDP
_MAXRETR IES(6次)后就會對鏈路進行重建。如果鏈路上沒有數據包需要發送,在定時任務中判斷
鏈路空閑SEND_SYN_GAP (2秒)以上,就按預先設定的發送方向發送同步包; 在判斷鏈路空閑大于
MAX_WA IT_SYN (10秒)時,就認為鏈路異常,對鏈
路重建。
3. 2 擁塞控制
UDP滑動窗口協議的擁塞控制采用慢啟動和緊急制動兩種方法[ 9 ] 。本端維護發送窗口( udp _
swindow)以及數據包的應答超時時間( udp _rexmt) 。為簡化流程,本端發送窗口的大小并不通知對端,而
是各端各自負責。鏈路剛建立時,發送窗口大小為1,超時時間為UDP_NORMALRXT(2秒) ;在發送成
功一個沒有重發的數據包后,發送窗口加1,但不能超過最大發送窗口UDP_MAXSW IN (20毫秒) ,超時
時間減去最小超時時間UDP_M INRXT ( 200毫秒) ,但不能低于最小超時時間;如果數據包超時重發,則
發送窗口減半但最小為1,超時時間加倍但不能超過最大超時時間UDP_MAXRXT(4秒) 。
3. 3 數據包的處理
3. 3. 1 發送與接收過程
應用進程發送數據包時,先判斷鏈路狀態是否為完成態,如果等待發送的數據包長度大于MAX_
PACKET_UN IT ( 1400) ,先對數據包進行壓縮處理UdpwComp ress ( ) [ 10 ] ,然后調用函數InsertPacketIn2
toUdpwSendQueue ( )入等待發送隊列,如果經過壓縮處理后包的長度依然大于MAX_PACKET_UN IT,
則入隊列時對包進行拆包處理,最后調用UdpwSend( )把等待發送隊列中的包發送出去。
為減少內存拷貝次數,UdpwComp ress ( )和拆包過程合作,在對原始包內容壓縮完成寫入目標包時,
先計算目標包的長度是MAX_PACKET_UN IT的多少倍,再在每個MAX_PACKET_UN IT的倍數處空出一
段大小為UDP滑動窗口協議頭長度的內存空間,然后由UdpwComp ress ( )在空出的內存空間后面填入
壓縮后的分片數據,拆包過程直接在空出的內存空間處按照UDP滑動窗口協議頭的結構進行賦值。發送
隊列只需記錄內存空間的起始地址以及分割前數據包的長度即可[ 11 ] 。處理后的包結構如圖3所示。
TCP在確定發送窗口的最大值時會對網絡的MTU進行偵測,由于板間通信的網絡質量是相對固定的,這
個值可以事先確定以降低協議處理開銷。經過測試,設置最大發送窗口為20時系統工作較為正常, 100M
網絡2秒內穩定, 10M網絡6秒內穩定。UDP滑動窗口協議在接收到數據包時的處理過程如圖4所示。
3. 3. 2 應答處理與超時處理
對數據包的應答有兩種方式:捎帶確認和直接應答。鏈路接收到應答包時,判斷應答序號udp _
ack是否在等待應答范圍內,如果在范圍內則數據包出隊列、釋放內存,鏈路的等待應答序號udp _ su2
na加1,否則忽略此應答包。由于拆包、組包共用一塊內存,對于拆分過的數據包,只有遇到標志為UD2
PM_END的包才能出隊列、釋放內存。創建定時任務UdpwTimerTask用于包超時處理,
定時周期為100毫秒。定時任務到時時,對各鏈路的等待應答數據包的等待時長減WA ITTIME_UN IT(100
毫秒) ,如果等待時長為0,則重發包并增加包重發計數( rescount) ,當包重發計數大于UDP_MAXRETR IES
(6次) ,認為鏈路異常,對鏈路進行重建。
4 UDP滑動窗口協議的測試
4. 1 測試環境
我們建立了基于西門子HiQ 8000軟交換的硬件測試環境, 配置成雙機框模式, 并將新設計的
UDP滑動窗口協議加載到系統的協議棧中為板間通信服務。未加載UDP滑動窗口協議時,不論是板間通信
還是機框間通信均采用TCP協議,開發人員如果要進行板間通信或機框間通信,可以調用相應的發送
函數tcpSend:STATUS tcpSend (BYTE targetModuleNO, BYTE targetP ID, const char3 buf, int len) ;
其中, targetModuleNO、targetP ID 指明了接收端處理器板的模塊號和進程號。程序根據targetModuleNO
計算出目標處理器板的IP地址,然后使用Socket函數send來發送數據。上層開發人員采用TCP進行
通信時,不必關心此次通信是板間通信還是機框間通信,只需指明對端處理器板的模塊號即可。
在加載了新的UDP滑動窗口協議后,板間通信將由它來完成,為了使UDP滑動窗口協議對上層開發人
員透明,我們修改了發送函數tcpSend,先根據target2 ModuleNO判斷此次發送是否是屬于板間通信,即發送
端和接收端的處理器板是否屬于同一機框,如果是,那么就調用新增的發送函數UdpwSend采用UDP滑動窗
口協議完成發送,反之依然按原步驟進行。
4. 2 測試方法
為測試UDP滑動窗口協議能否在較低CPU占用率的基礎上實現高可靠性通信,測試工作分兩步:
先針對協議本身進行單元測試,然后在軟交換系統中進行呼叫測試,判斷加載了UDP滑動窗口協議后
系統的整體運作是否正常。協議的CPU占用率是重要的測試參數,但在以最小模式加載操作系統時,操作系統自身提供的計算CPU占用率的功能未被加載。我們編寫了專門計算CPU占用率的函數,算法思想為:在系統啟動時對一個全局變量進行自加,算出一秒鐘自加的次數,然后啟動一個優先級最低的任務對此全局變量
進行自加,默認每5秒鐘檢測變量自加的次數以統計最低優先級的任務運行的百分比,就是CPU空閑
的百分比。單元測試時配置操作系統使操作系統啟動完成后只加載TCP / IP協議棧和UDP滑動窗口協議,這
時軟交換系統只能收發數據包。在此基礎上編寫發送進程和接收進程: 發送進程不斷調用修改后的
tcpSend按不同頻率、發送不同長度的板間通信數據包,由接收進程接收,進行校驗、計算誤碼率,并記錄
CPU占用率。相關測試數據見表2。
5 UDP滑動窗口協議的性能優化
在實際測試過程中,我們發現應答包的個數對CPU占用率的影響有一定規律:每發送1 000個應
答包, CPU占用率提高約2. 5% ,每接收處理1 000個應答包, CPU占用率提高約3. 8%。為降低應答
包對CPU占用率的影響,對應答包的發送采用如下方法實施優化[ 12 ] 。
在鏈路上設置兩個變量用于控制應答包的發送:發送應答包閥值udp_ackgap和發送應答包的累
計數udp_needack。在鏈路上每收到一個數據包,把udp_ackgap和udp_needack分別加1,但udp_ackgap
不能超過UDP_MAXACKGAP ( 18) ,在時鐘任務中把udp_ackgap減UDP_M INACKGAP (5) ;在鏈路上
每發送一個數據包,向對端發應答包,把udp _nee2dack清0。當udp _ ackgap < UDP _M INACKGAP 或
udp _ needack > udp _ ackgap 時,在鏈路上發送應答包,同時在定時任務中判斷如果udp_needack不為0
則發送應答包。這樣,在鏈路空閑時(每100ms小于5個包)收到數據包后立即應答;在鏈路忙時提
高udp_ackgap,可100ms發送一個應答包或者每隔udp_ackgap (最大18個包)發送應答包;當鏈路由忙
變為空閑時,由于定時任務為對udp _ackgap減5操作會降低udp_ackgap,可實現逐包回應答。
參見表3,優化后發送端和接收端CPU占用率都有降低,其中數據包長度為4 096,每秒發送1 000
個數據包(這個測試對應最常見的百萬數量級呼叫量)時CPU占用率降低最明顯。
通過分析比較表2和表3的測試數據,可以看出在相同條件下使用UDP滑動窗口協議時的CPU
占用率比使用UDP時增加不超過3% (數據包長度為8 192的測試對應千萬數量級呼叫量,為極限測
試) ,同時保證了數據包無重復、無丟包地按序遞交。
6 結 論
UDP滑動窗口協議是應用于現代通信系統中的板間通信的應用層協議,它在現有的UDP協議的
基礎上采用滑動窗口技術,有效地解決了板間通信中協議處理開銷和通信可靠性之間的矛盾,能夠保
證在較低CPU占用率的基礎上實現原本TCP協議才具有的高通信可靠性。本文給出的基于UDP的
滑動窗口協議的設計和實現方法,通過測試分析驗證了是可行的和有效的。
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
