一种TCP友好的实时流单播拥塞控制算法摘要：通过分析TCP拥塞控制机制和已有的实时流拥塞控制算法，提出了一种利用RTP/RTCP协议收集QoS信息的基于模型的单播拥塞控制算法――基于拥塞率反传的拥塞控制算法。实验证明，该算法不但具有TCP友好性，而且能在速率恢复阶段减少拥塞再次出现的概率，使实时流速率变化平稳，并且丢包率比参考协议TFRC减小了2/3。关键词：拥塞控制；TCP友好；RTP/RTCP；拥塞率反传中图法分类号：TP393．02文献标识码：A：1001－3695(2007)01－0283－03由于Internet上网络结构的异构性和竭尽全力的服务（BestEffortServices）的特点，使得网络拥塞很容易出现。针对这一问题，VanJacobson最早指出了TCP协议在网络拥塞控制方面的不足，提出了慢启动(SlowStart)和拥塞避免(CongestionAvoidance)的算法[1]。随后TCP协议版本不断完善，引入了快速重传(FastRetransmit)和快速恢复(FastRecovery)等算法。依靠慢启动以及失败重传策略，可以使TCP可靠传输成为可能，但同时也带来了较大的传输延迟，在许多实时性业务中无法直接应用。因此，我们通常采用UDP协议作为流媒体和实时音视频传输的传输层协议。UDP协议虽然可以满足这些应用的实时性要求，但没有采用一定拥塞控制机制，只能保证尽力传输，一旦出现网络拥塞，UDP流不会像TCP流那样调整自身发送速率，而是继续占用有限的带宽资源，这样就造成了UDP流和TCP流竞争的不公平性。??近几年来，根据实时流传输的应用需求，如音视频编码数据的实时传输，人们提出了一些新的拥塞控制算法。这些拥塞控制算法的共同目标就是通过引入仿TCP速率控制机制或者新的速率控制机制，实现实时数据流与TCP流分享可用带宽，也就是所谓的TCP友好性(TCPFriendly)[4]。在众多的TCPFriendly拥塞控制算法中，基于模型（或基于公式）的TFRC[2,3]最具有代表性。??1TFRC拥塞控制算法??基于模型的拥塞控制通常是通过对TCP流量进行数学建模，找到一种非TCP协议也可以进行速率控制的方法。其中，Pathye等人[5]通过分析TCPReno拥塞控制的过程，建立了TCP流量模型，即TCP流吞吐量与下列参数有关：数据包大小s、往返时延迟RTT、丢失事件率p和重传超时值RTO等，式(1)是一个比较精确的TCP的流量模型公式：??Floyd提出的TFRC[2]，将式(1)作为拥塞控制的计算式，可以使得TFRC流与TCP流在同等条件下抢占带宽的能力相同，维持发送速率稳定性的同时还能对网络的拥塞状态作出及时的反应。??TFRC是一种单播拥塞控制算法，对速率的调整是基于源端的。TFRC在启动阶段采用类似TCP慢启动的策略[3]，当拥塞发生后，接收端能够将计算出的丢失事件率p以及用于计算的参数反馈至源端，这样源端可按式(1)计算出源端允许的发送速率R??tcp，并调整速率。??2本文算法描述??本文提出的单播拥塞控制算法――基于拥塞率反传的拥塞控制算法（CongestionRateFeedbackbasedCongestionControl,CRFCC）是根据某实时传输业务需求而提出的，因此采用RTP/RTCP[7]作为采集网络状态参数的协议。算法中设定源端每发送49个RTP包后，周期性地发送一个SR控制包，接收端负责接收源端的所有发包，当收到SR包后，向源端反馈RR控制包，将网络状态参数告知源端。由于RTCP控制包发送频率最少5s一次，对于拥塞造成SR和RR包丢失，致使发送端无法及时得到反馈的情况，在源端设置一定时器，当源端5s内没收到RR包，直接将网络状态判定为重度拥塞状态。??2．1参数计算??2．1．1STT计算??STT的测量采用时间戳法，通过公式RTT=T??now-T??start-T??delay在源端计算得出，其中T??now取自源端系统时钟，T??start来自RR包中最后SR时间戳（LSR），T??delay来自RR包中自最后SR起时延（DLSR）。为了消除网络中的随机抖动，RTT的估计值要采用EWMA(ExponentiallyWeightedMovingAverage)方法进行加权平均，即其中RTT是当次测量值，RTT?C″是上次的估计值，RTT′是当次的估计值。对于第一个RTT值，不作加权平均。在TFRC中q的值是0.95，为了增强算法对延迟的反应，本文选择0.875。??2．1．2平均丢包率p计算??考虑到将采用的TCP流量模型，算法中不采用丢失事件率，而采用平均丢包率p代入TCP流量模型中计算。因为不考虑差错重...