黄远峰,宗 平
南京邮电大学软件学院,江苏南京 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空间
腾讯微博
腾讯朋友
收藏
淘帖
顶
踩
