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