[互联网]TCP拥塞控制报告.ppt

TCP拥塞控制 小组成员：罗文文，马志强 孙帅一，何浩 拥塞控制的定义 当网络中存在过多报文时，网络的性能就会下降，这种现象称为拥塞。 分组交换网络的性能(功率、往返时间RTT、吞吐量)与负荷的关系用下图来说明 发送端的发送窗口的上限值应当取为接收端窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个，即应按以下公式确定： 发送窗口的上限值 ? Min [rwnd, cwnd] 当 rwnd cwnd 时，是接收端的接收能力限制发送窗口的最大值。 当 cwnd rwnd 时，则是网络的拥塞限制发送窗口的最大值。 经典的TCP拥塞控制算法 TCP Tahoe TCP Reno TCP NewReno TCP Vegas TCP Reno算法 　针对Tahoe算法的不足，提出了改进算法Reno。改进主要有两方面：一是对于收到连续3个重复的ACK确认，算法不经过慢启动，而直接进入拥塞避免阶段；二是增加了快速重传和快速恢复机制。Reno算法以其简单、有效和鲁棒性成为TCP源算法的主流，被广泛的采用。但它不能有效的处理多个分组从同 一数据窗口丢失的情况。 TCP New Reno TCP New Reno修改了TCP Reno的快速恢复算法，处理一个窗口中的多个报文段同时丢失时出现的“部分确认”(Partial ACKs，它在快速恢复阶段到达并且确认新数据，但它只确认进入快速重传之前发送的一部分数据)。 在这种情况下，TCP Reno会退出快速恢复状态，等待重传定时器溢出或者重复的确认ACK到达，但是TCP New Reno并不退出快速恢复状态，而是(1)重传紧接着那个部分ACK之后的报文段，拥塞窗口等于其减去部分的ACK；(2)对于得到确认的新数据，设置cwnd等于其加上SMSS：(3)对于第一个或每一个Partial ACK，重传定时器复位。 对快速重传机制的改进 TCP Vegas主要在两个方面对快速重传进行了改进，使得探测丢包现象变得更及时，且能进一步减少超时情况的发生。 第一个改进措施是，当TCP Vegas收到重复的确认包时，计算从发送该数据包时刻到当前时刻的时问间隔，比较是否大于RTO，如果是，Vegas就重传该数掘包而不用等到第2、3个重复确认包的到达，如下图所示。而且在TCP Vegas中使用了比TCP Reno更为精确的计时器，可以测得更加准确的RTT以及其他的一些时间数据，对RTT的估计将更加准确，同样也能得到更加精确的超时时间。 第二个改进措施是当检测到超时并重传数据包后，收到第1个或第2个非重复确认包时，检查从重传该数据包到收到非重复确认包的时间间隔，时间间隔若大于超时时间，就认为发生了丢包，并重传该数据包。这样能够不用等到重复的确认包到达，就准确的传送在重传前发生丢包的那些数据，这在发生多个丢包的时候尤为重要，否则发送端会一直等待直到超时，其过程如下图所示: 拥塞避免机制的改进 Reno是把丢包情况作为拥塞发生的信号，而Vegas则是通过计算期望值的吞吐量与实际吞吐量之间的差来估计网络瓶颈处的可用带宽。由于Vegas不需要等到丢包才认为发生了拥塞，所以能更有效的利用带宽。其基本思想是期望的吞吐量与实际的吞吐量相差超过一定值时，就认为网络拥塞程度严重，应该减小发送窗口；另一方面，当两者之间的差距小于一定值时，则认为连接没有完全有效的利用带宽，应该要增大发送窗口。 TCP Vegas在拥塞避免阶段的具体算法为： 1、计算期望的吞吐量与实际吞吐量之间的差值 其中 代表传输延时，也是当缓存中数据包为空时的RTT值(BaseRTT), cwnd代表源端在每个往返时间(RTT)中允许发送窗口的大小，期望的吞吐量为cwnd/T，设r代表实际网络中的RTT，实际的吞吐量为cwnd /r 慢启动阶段的改进 TCP Reno在慢启动阶段的每个RTT内窗口都会增大一倍，TCP Vegas修改为每隔一个RTT才将窗口增大一倍，在这之间，窗口固定不变。这样是为了保证能够正确的比较吞吐量的差值，Vegas还在慢启动中加入了拥塞检测。在初始的慢启动阶段，TCP Vegas通过计算期望的吞吐量估计出可用的网络带宽，当实际的吞吐量变得比期望的吞吐量小于一定门限值y时，窗口将会减小1／8，并且从慢启动阶段进入拥塞避免阶段。为慢启动加入拥塞检测是十分重要的，当网络带宽变大时，其作用尤为明显，改进的慢启动算法对改善丢包情况和超时现象十分有效。 * * 　 网络中的拥塞问题必须依靠TCP层端到端控制和lP层链路控制的共同作用才能有效的解决，其中TCP层的拥塞控制仍然会起主要的、基础的作用。端到端TCP拥塞控制的本质思想是通过调整发送端的发送速率