类TCP流媒体拥塞控制算法

赵晓焱，张会芝，毛文涛

（河南师范大学 计算机与信息工程学院，河南 新乡453007）

0 引 言

流媒体业务的涌入使得网络拥塞不断增加［1］，这种业务与传统的基于TCP 的业务如HTTP、FTP 有较大的差异。流媒体业务实时性、连续性强、数据量大，允许有一定的差错和丢失，业务质量对带宽的变化十分敏感，对服务质量Qos也有特殊的需求［2］。因此，需要一种适应其特点的拥塞控制方法以保障网络的性能和传输质量。

基于TCP协议的拥塞控制算法是目前网络中成熟的拥塞控制机制，例如文献 ［3，4］提出了基于TCP协议的加性增乘性减 （AIMD）窗口控制机制，文献 ［5，6］采用不同的TCP Reno慢启动策略进行拥塞控制，文献 ［7－9］提出了TCP友好速率控制（TFRC）策略并研究了多种改进算法。然而，改进的TCP 拥塞控制机制为兼容传统TCP 业务，保证数据的完整性，必须采用快速恢复、超时重传等机制，这些严重影响了流媒体的连续性、实时性从而导致业务质量降低。相对于TCP 协议，RTP／RTCP 协议提供带有实时特性的端对端数据传输服务，不要求重传丢包，更加适用于流媒体业务。但是传统的RTP／RTCP拥塞控制算法［10］反馈速率低无法完全实现流控自同步，同时TCP友好性不足，对其它基于TCP的业务影响较大。针对这些问题，本文提出了一种基于RTP／RTCP 协议的类TCP 流媒体拥塞控制算法，重点研究如何将TCP拥塞控制机制改进并应用于RTP／RTCP协议之上，在有效控制网络拥塞的同时，增强媒体流公平性，降低延迟抖动以保证流媒体业务的传输质量。

1 类TCP算法原理

类TCP算法由接收确认模块、窗口控制模块、发送控制模块、时钟控制模块等组成。窗口控制模块根据接收模块收到的确认帧和超时时钟控制模块的超时情况调整窗口大小，传输控制模块则根据窗口大小发送流媒体数据，时钟控制模块计算确认超时时钟值并处理其它模块的消息，接收确认模块根据收到的数据帧向发送端发送确认帧。

类TCP算法结构模型如图1所示。

图1 类TCP算法结构模型

TCP－RT算法采用TCP的确认机制，接收端在收到反馈速率所规定数量的RTP数据帧后或时钟超时而没有收到规定数量的数据帧时，向发送端发送RTCP 接收报告（SR、RR 帧），确认收到的最后一个数据帧；发送端使用改进的AIMD算法进行窗口控制，调整RTP 数据帧的传输速率，改进原TCP 窗口控制机制 （慢启动、拥塞避免、快速恢复）的转换关系和控制参数，实现较平稳的速率变化，在基于RTP／RTCP的流媒体传输中实现较强的流控自同步；同时彻底摒弃TCP的重传机制，防止重传造成进一步拥塞以及由于等待造成的长时间传输停顿。

2 类TCP算法参数的计算

2.1 平均吞吐量

类TCP算法和标准TCP算法在拥塞时都降低窗口（速率）大小，只是类TCP算法基于RTP／RTCP协议，不重传数据包，因此恢复到拥塞避免稳定状态的时间不同，一般相差几个往返时间（RTT）。类TCP 算法与标准TCP 算法一样，大部分时间都处于拥塞避免、快速恢复机制的控制之下，此时窗口的变化过程也基本相同，如图2所示。

图2 类TCP控制算法窗口大小变化

文献 ［11］中J Padhye等人提出的标准TCP模型表明TCP流的传输速率正比于其丢包率的平方根的倒数，模型所描述的情况与类TCP 算法的传输速率的变化过程相似，处于稳定状态下吞吐量基本由拥塞避免、快速重传机制决定，并受到超时的一定影响。因此，本文以这个模型为基础，参考文献 ［12］提出的吞吐量公式，在较理想的状况下，推导出类TCP算法的吞吐量近似计算公式，如下所示

式中：p——丢包率；b——反馈速率；RTT——往返时间；B——传输速率，表示单位时间内发送的帧数，也可以通过与平均帧长度相乘，得出比特数为单位的传输速率；Bmax——最大编码速率。

2.2 平均延迟抖动

设定类TCP算法的延迟抖动为RTP 数据帧到达时间的变化。设Di为第i帧的到达时间，用式（2）表示抖动

类TCP算法传输过程中，定义两次相邻的以r≠b为标志丢包事件之间的时间为TD，其中r为实际接收和丢失帧的总数，b为反馈速率。TD 周期与标准TCP 模型收到重复确认帧的周期的窗口变化相似，设TD 期间正确收到Y 帧，根据标准TCP模型可得Y 的期望值如下

TD 期间最后的窗口大小W 的期望值如下

从图3 所示TD 周期内抖动的变化模型中可以看出，每个TD 周期内传输处于拥塞避免阶段，反馈速率b＝2，可以认为每一帧的延迟为RTT／2，抖动延迟为0。当TD周期结束时，发生丢帧，接收到的帧的平均延迟增大，与标准TCP收到重复确认的情况相似，因此利用标准TCP模型分析可知此时延迟抖动平均为RTT／（2b）；当TD 周期开始的一段时间，可用带宽增加，传输时延又降低到原来的值，因此可以设定TD 开始时第一帧的延迟抖动为RTT／（2b）。

图3 TD 周期内抖动的变化

当网络拥塞时，发生超时现象。实验中发现连续超时发生的概率很低，为了简便计算，本文假设在传输过程中n个连续的TD 周期后发生一次超时。设超时时刻Timeout的平均值为T0，超时等待的时期称为Tout。定义连续的n个TD 和1个Tout组成的周期为TP，整个传输过程可视为由一系列连续TP周期所组成，因此可以用一个TP周期内发送的帧的延迟抖动的期望值作为整个传输过程抖动的期望值。类TCP 算法在一个TP 周期抖动分析模型如图4所示。

图4 类TCP算法抖动分析模型

发生超时后，传输延迟在T0／2～T0 之间。假设传输延迟为T0，则接收端所收到的TP周期的最后一帧的延迟为T0，在此一段时期抖动延迟之和为｜RTT／2－T0｜，因此可以抽象的认为TP 最后一帧的延迟抖动为｜RTT／2－T0｜，其以前的TD、Tout周期内发送的帧的延迟抖动为0；当TP开始的一段时间内时，传输延迟将由T0 逐渐变为RTT／2，也可以抽象地认为TP 第一帧的延迟抖动为｜T0－RTT／2｜，之后进入TD 周期稳定状态中抖动又为0。在发生超时的一段时间内，延迟的具体变化如图5所示。

图5 超时情况下一段时间内延迟的变化

根据上述的模型分析，假设在Tout周期内发送的帧实际最多丢失E（W）个，可以得到平均抖动Jitter的期望值为

整理得

式中：1／E（n）可以理解为TD 周期发生超时的概率，令Q＝1／E（n），则式（6）可表示为

由标准TCP模型可知，当p－＞0时，有

将式（3）、式（4）、式（8）代入式（7）中整理得出Jitter估计值为

当p较小时，式（9）中分母约为1，则估计值可表示为

传统的RTP／RTCP 拥塞控制算法中，由于丢包率较高，导致其延迟抖动较大。类TCP 算法采取与TCP 算法相似的滑动窗口控制机制，对拥塞反应较快丢包率p较小，由式（10）可知从理论上讲类TCP算法整体上抖动较小。

3 类TCP算法的具体实现

3.1 发送控制模块

发送端通过窗口控制机制调整传输速率，保证流媒体业务的质量。当发送端有数据帧需要发送时，编码器将数据发送给发送控制模块。该模块根据当前发送端已发送但尚未收到确认的数据帧数量pipe和当前窗口大小即当前最多可以连续发送的帧数cwnd的关系决定是否发送数据。

（1）如果pipe＜cwnd，则可以发送一个数据帧并令pipe＝pipe＋1；

（2）当pipe≥cwnd时，则不发送，此时可以丢弃这个数据帧，也可以按一定规则缓存一段时间再发送，视具体业务的要求而定。

每次发送一个数据帧时，如果确认超时时钟没有开始计，则令其重新开始计时，如果已经开始计时，则超时时钟无需重新计时。

3.2 传输控制机制

窗口模块根据反馈情况进行窗口控制，调节传输速率，是实现拥塞控制的核心。窗口调整算法如下：如果超过了超时时钟值Timeout没有收到确认信息，则认为发生了丢帧，说明网络拥塞引起丢包。此时令pipe＝0，窗口调整阈值ssthreshold＝3／4＊cwnd，cwnd＝cwnd／2，以使传输速率平稳地下降，或较快进入拥塞避免状态。

如在确认时钟超时之前发送端收到确认帧，根据接收端反馈的最后一个数据帧的序号，计算实际接收和丢失帧的总数r。如果r≠b说明发生丢包，则调整窗口大小和阈值，进入 “快速恢复”状态，同时不重传丢失的数据帧，直接发送新的数据，结合网络层的RED 机制，增强了网络拥塞的控制能力。如果r＝b说明没有丢包，根据窗口大小与阈值的关系确定进入慢启动或拥塞避免状态。如果在确认时钟超时前收到确认帧，算法代码实现如下：

4 实验分析

为考察算法的实际应用性能，本文采用集成了类TCP算法的Openphone软件终端，在Windows环境下进行实验。实验环境配置如图6所示。

图6 实验环境配置

4.1 拥塞控制能力

为了测试类TCP算法的带宽利用和拥塞控制能力，设置两个软件终端相互发送最高速率为400Kbps的H261CIF格式的视频流，并与RTP／RTCP算法进行了对比试验。该RTP／RTCP算法以丢包率loss为标志量，接收端每隔8秒左右向发送端反馈一个RTCP帧，接收端根据RTCP 帧中的丢包率，使用传统AIMD 方式调整传输速率。其传输速率的调整算法简单描述如下：

根据上述方式调整传输速率后，将重新计算的传输速率传给编码器，编码器调整压缩过程中的量化参数，按新的速率输出视频码流。

实验过程中使用干扰程序以一定的平均码率同时在测试链路上发包，图7、图8显示出不同码率的干扰码流下，两种算法发送速率的变化。其中横轴为时间轴（s），纵轴表示传输速率（Kbps）。两种算法终端在视频传输过程中，每隔15分钟左右，调整一次干扰程序的平均码率。干扰程序码率的调整过程为：64Kbps－128Kbps－256Kbps－128Kbps－64Kbps。

图7 类TCP算法传输速率变化过程

图8 RTP／RTCP算法传输速率变化过程

从图7、图8中可知类TCP 算法能较快地将传输速率调节到可用带宽，并且在较长的时间内时传输速率保持稳定并充分利用带宽，较好地抑制了拥塞。而传统RTP／RTCP算法整体上传输速率不稳定、震动较大。在网络带宽发生波动时，类TCP算法也能够较快做出反应，比如可用带宽下降时，类TCP算法在20－40s左右可将发送速率降低，码率降低的过程比较平稳，变化曲线呈阶梯状。但是当可用带宽降低较大如图7中500－1000s时，码率的变化还是较快，算法在这一方面还需进一步的改进。

4.2 吞吐量

将1小时传输过程中实际测量的传输速率与式（1）计算的期望速率进行对比，实验结果见表1。从表中可以看出在丢包率和RTT 相同的条件下，吞吐量的实际测量值与使用式（1）计算的标准TCP的传输速率相近，符合TCP友好性的要求。

表1 类TCP算法与标准TCP算法传输速率的比较

4.3 延迟抖动

表2将1 小时传输过程中实际测量的平均抖动与式（10）计算的平均抖动进行了比较，结果表明其绝对误差不到1ms，证明可以用式 （10）估计传输中的抖动；从测量和估计两方面证明类TCP算法有效抑制了抖动，提供了比较平稳的传输速率，有利于提高业务的整体质量。

表2 延迟抖动的测量与估计

5 结束语

本文提出的类TCP 拥塞控制算法，平均丢包率低于1%，与一般的RTP／RTCP 算法统计的平均丢包率2%－10%相比，不仅大大降低了丢包率，而且能够及时地对网络带宽的变化做出反应，较好地抑制拥塞、抖动，提供比较平稳的传输速率。然而，无线网络将在今后的网络发展中占有重要地位，流媒体业务无法回避无线网络提出的挑战，类TCP算法是在有线网络条件下研究和实验的，研究过程中没有考虑无线网络的特点，下一步工作中将深入研究无线网络中流媒体拥塞控制策略。

［1］MAO Yanfei，HUANG Zhongdong.Research and design of Web DVR system based on real－time streaming protocol［J］.Computer Engineering and Design，2011，32 （7）：2523－2525（in Chinese）.［茅炎菲，黄忠东.基于RTSP协议网络监控系统的研究与实现 ［J］.计算机工程与设计，2011，32 （7）：2523－2525.］

［2］MA Haiyuan，MENG Xiangru，MA Zhiqiang，et al.High speed multicast congestion control based on population ecology［J］.Journal of Computer Applications，2011，31 （12）：3195－3199 （in Chinese）.［麻海圆，孟相如，马志强，等.基于种群生态的组播拥塞控制机制 ［J］.计算机应用，2011，31（12）：3195－3199.］

［3］Hayder Natiq Jasem，Zuriati Ahmad Zukamain，Mohamed Othman，et a1.The TCP－based new AIMD congestion control algorithm ［J］.International Journal of Computer Science and Network Security，2008，8 （10）：331－338.

［4］Wu Yuanban，Liu Zhensheng，Zhang Wenliang.Congestion control mechanism of study based expanded AIMD ［J］.Computer Engineering，2008，34 （9）：232－234.

［5］LIU Jun，TONG Xuehong.TCP congestion control algorithm［J］.Computer Engineering and Design，2011，32 （7）：2309－2313 （in Chinese）.［刘俊，童学红.TCP拥塞控制算法 ［J］.计算机工程与设计，2011，32 （7）：2309－2313.］

［6］Attiya，Gamal.New strategy for congestion control based on dynamic adjustment of congestion window ［J］.International Journal of Computer Science Issues，2012，9 （2）：368－377.

［7］XIAO Fu，WANG Ruchuan，SUN Lijuan，et al.Wireless network based TCP－friendly congestion control mechanism ［J］.Computer Science，2010，37 （7）：50053 （in Chinese）. ［肖甫，王汝传，孙力娟，等.基于TCP 友好的无线网络拥塞控制机制研究 ［J］.计算机科学，2010，37 （7）：50－53.］

［8］Wan Shanshan，Ren Zhifeng.Research on full－proxy based TCP congestion control strategy ［J］.Advances in Intelligent and Soft Computing，2012，133 （20）：371－378.

［9］Shiang Hsien－Po1，Van Der Schaar Mihaelal.A quality－centric TCP－friendly congestion control for multimedia transmission［J］.IEEE Transactions on Multimedia，2012，14 （3）：896－909.

［10］KUANG Quan，LI Xiaoyong，BAI Yingcai.The research on congestion control algorithm for layered multicast based on RTP／RTCP ［J］.Computer Applications and Software，2006，23 （2）：80－82 （in Chinese）. ［匡全，李晓勇，白英彩.基于RTP／RTCP的分层多播拥塞控制算法的研究 ［J］.计算机应用与软件，2006，23 （2）：80－82.］

［11］Handley M，Padhye J，Floyd S.An extension of the TCP steady－state throughput equation for parallel flows and its application in MulTFRC ［J］.IEEE／ACM Transaction on Networking，2011，19 （6）：1676－1689.

［12］HU Zhongsheng，CHEN Yuanyan，HUANG Jingxian.Improve TFRC mechanism with intermediate node ［J］.Computer Engineering and Design，2012，33 （7）：2570－2574 （in Chinese）. ［胡忠胜，陈元琰，黄精籼.结合中间节点的TFRC改进协议 ［J］.计算机工程与设计，2012，33 （7）：2570－2574.］