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