TCP拥塞控制分析

TCP 拥塞控制分析摘要：随着计算机网络的飞速发展，网络用户数量急剧增加，Internet 在各个领域也发挥越来越重要的作用，但随着其流量的急剧增加，由此引发的网络拥塞已经成为制约网络发展和应用的瓶颈问题。

拥塞容易造成传输延迟和吞吐量等性能指标的下降，严重影响带宽、缓存等网络资源的利用率。

TCP 作为应用最广泛的传输协议，它的拥塞控制已经成为其成功的关键。

本文针对这一现象对TCP 性能及拥塞控制进行研究，我们将简单探讨网络拥塞出现的原因，着重介绍TCP 拥塞控制的原理并分析四个TCP 拥塞控制算法，最后论述TCP 拥塞控制所面临的问题，根据此提出进一步的研究方向。

关键词：TCP 拥塞、拥塞控制、TCP Tahoe 、TCP Reno 、TCP SACK 、TCP Vegas1. 拥塞产生的原因拥塞是一种持续过载的网络状态，此时用户对网络资源（包括链路带宽，存储空间和处理器的处理能力等）的需求超过了其固有的容量。

拥塞导致的直接结果就是分组丢失率增加，端到端延时加大，甚至有可能使整个系统发生崩溃。

网络产生拥塞的根本原因在于用户或端系统提供给网络的负载大于网络资源容量和处理能力，即网络提供的资源不足以满足用户的需求，这些资源包括缓存空间、链路带宽容量和中间结点的处理能力等，使其产生数据包时延增加、丢弃概率增大、上层应用系统性能显著下降等典型现象。

拥塞产生的直接原因有三点：（1）存储空间不足。

缓存的容量不够大，当缓存已经装满，没有空闲的空间时就只能将新到达的分组丢弃。

（2）带宽容量不足，低速链路对高速数据流的输入也会产生拥塞。

任何信道带宽最大值为()N +B =S C 1log 2(N 为信道噪声平均功率，S 为信源平均功率，B 为信道带宽) [1]。

要求所有信源发送的速率R 必须小于等于信道容量C 。

（3）处理器处理能力弱，速度慢。

低速链路对高速CPU 也会产生拥塞。

要避免拥塞的发生，必须对链路带宽、路由器处理速度和存储容量等问题予以考虑，尽可能使系统的各个部分相互匹配。

但由于网络流量分布的不均衡性，随着用户数量和服务类型的增加，从根本上避免拥塞是不可能的。

因此必须采取一定措施来尽可能避免网络拥塞，是网络尽快从拥塞中恢复出来。

2. TCP拥塞控制TCP是建立在Internet体系结构中网络层和应用层之间的传输层协议，端到端的通道为应用层提供了可靠有序的数据传输服务。

TCP的主要目的是为了增强由Internet IP层所提供的尽最大努力服务的性能和控制网络中的数据流量，实现端到端的流量控制，以期能够有效地利用网络资源，消除或减少网络路由器中的拥塞，并使不同的数据流能够合理地共享使用网络资源。

TCP拥塞控制是Internet稳定发展的主要因素，自从1986年Internet发生了首次网络拥塞[2]以来便激发了人们对TCP拥塞控制的广泛研究。

它采用窗口控制机制，发送方维持着一个拥塞窗口变量来控制每次发送出但未被接收方接收的数据包的最大数量。

目的节点在接收到数据包后会向源节点发送确认信息（ACK）。

当窗口变量耗尽时源端就进入等待状态，直到下一个ACK到达才继续发送数据包。

TCP是一种加性增加乘性减少（AIMD）的拥塞控制算法。

当发送方发现窗口内的一个报文发生丢失，就认为这个丢失是由于网络拥塞造成的，于是将窗口减半以减小发送速率，从而避免拥塞的加重；如果窗口的报文没有丢失则表明目前网络状况良好，发送者将窗口加倍从而增大了报文的发送速率。

这种拥塞控制有两个特点：（1）自同步，当拥塞发生和ACK延迟的时候会自动减小源端的发送速率。

（2）窗口控制源端的发送速率。

虽然TCP拥塞控制算法种类繁多，但算法大多有四个部分组成[3]：（1）慢启动阶段：当建立一个新的TCP连接时，拥塞窗口（cwnd）被初始化为一个数据包大小。

源端按cwnd的大小发送数据，没收到一个ACK确认，cwnd就增加一个数据包发送量，继续这样的过程直到拥塞控制窗口增加至慢启动阀值，显然cwnd的增长将随RTT呈指数级增长，发送端向网络中发送的数据量将急剧增加。

慢启动最初阀值被设为最大窗口值的一半，当窗口大小增加至启动阀值时慢启动阶段结束，进入拥塞避免阶段。

（2）拥塞避免阶段：当发现超时或者收到3个相同的ACK时，网络即发生拥塞，此时进入拥塞避免阶段。

慢启动阀值（ssthresh）被设置为当前cwnd的一半；超时时cwnd被置为1.如果cwnd大于慢启动阀值则TCP停止慢启动过程转而执行拥塞避免过程，使发送端的cwnd每经过一个往返时延RTT就增加一个MSS大小。

这样拥塞窗口按线性规律缓慢增长。

（3）快速重传和恢复：当数据包超时时，cwnd被设置为1，重新进入慢启动阶段，这会导致过大地减少发送窗口尺寸，降低TCP吞吐量。

因此快速重传和恢复就是在发送端收到3个或以上重复的ACK时就断定数据包丢失，并重传数据包，同时将慢启动阀值设置为当前cwnd的一半，而不必等到RTO超时。

快速恢复的算法如下：（1）当第三个重复ACK到达时，设置慢启动阀值（ssthresh）为当前cwnd的一半；重传丢失的数据包；设置cwnd=ssthresh+3。

（2）每次有一个更多的重复ACK到达就把cwnd加1并在可能的情况下传输数据包。

（3）当确认数据包的下一个ACK到达时，设置cwnd=ssthresh，进入拥塞避免阶段。

3. TCP拥塞控制算法自1986年互联网出现严重的拥塞崩溃现象后，网络拥塞控制受到了广泛的关注。

Jacobson和Karels最早开发了一种拥塞控制机制：TCP-Tahoe，并于1988年在4.3BSD中实现，此后人们对TCP拥塞控制做了很多的研究。

目前TCP协议版本非常多，本文将主要介绍TCP Tahoe，TCP Reno，TCP SACK，TCP Vegas。

3.1 TCP TahoeTCP Tahoe指的是1988年加入Van Jacobson提出的慢启动、拥塞避免和快速重传算法之后的4.3BSD或类似的TCP版本。

才用了递增式肯定重传策略和“go-back-n”模型（滑动窗口算法）[4]。

在慢启动阶段，拥塞窗口（cwnd）随着确认的到来以指数方式递增（这种以ACK来触发TRANSMIT的机制被称为“ACK clocking”），直到到达阀值；之后TCP 进入拥塞避免阶段，cwnd每隔RTT以线性方式递增一个单位。

如果连续收到3个重复ACK，TCP不等重传定时器溢出就马上重传丢失的数据包，之后TCP返回慢启动状态。

TCP Tahoe是在早期TCP实现中为了减少拥塞现象，加入了许多新的算法得到的，目的在于保持良好的用户通信吞吐量的同时控制网络拥塞。

另外Tahoe算法能对往返时间（RTT）的估量进行修改，并把RTT设置为RTO的基值。

它实现了早期Jacobson的拥塞控制机制。

1990年Van Jacobson对Tahoe算法进行了改进[5]，出现了TCP Reno算法。

TCP Reno 在快速重传之后进入快速恢复，而不是TCP Tahoe采用的慢启动。

Reno可以分为四个阶段: 慢启动阶段、拥塞避免阶段、快速重传和快速恢复阶段。

相应地, 在不同阶段调用了不同的算法, 分别为: 慢启动算法、拥塞避免算法、快速重传和快速恢复算法。

当数据包超时，cwnd被重置为1，重新进入慢启动，这将大大减少发送窗口的尺寸，降低TCP 吞吐量。

Reno算法的理想情况是在一个窗口中数据包丢失时，Reno算法中的发送方在每个RTT中最多重传一个包。

和Tahoe算法相比，Reno可用的带宽增加了，重传率也降低了。

相对于其他算法，当一个数据窗丢失多个数据包时，Reno出此案的问题最严重[6]。

Reno的快速恢复算法仅在丢失一个数据包时得到充分利用，表现得比Tahoe好。

虽然TCP Reno是TCP Tahoe的改进版，但TCP Teno算法仍有不足之处：TCP Reno在一个窗口中的多个数据包同时丢失时会出现性能问题，丢失的数据包会使得TCP不断执行快速重传和快速恢复，而cwnd和ssthresh亦会多次被减半，大大降低吞吐量。

另外在大多数TCP实现中，RTO计数器的值被认为是RTT的均值和方差的估计值的函数。

而准确估计TRO和RTT不是一件容易的事。

理论上RTT的测量比较简单，只是数据包从发出到确认ACK返回发送端的时间；但由于TCP使用的是用一个ACK确认所有已收到数据的“累计”确认方式，故实际上RTT的估计往往很复杂。

3.3 TCP SACKSACK（Selective Acknowledge）算法是有效恢复同一窗口中多个分组丢失的另一种技术途径，在Reno算法基础上进行扩展，加上了选择ACK确认帧和选择重传机制。

SACK在接收端发往源端的ACK确认帧中加入了SACK选项，报告一些收到的非连续数据。

选择性的确认可以让接收端另外报告它所收到的非连续数据，对数据包进行有选择的确认和重传，避免不必要的重传，减少时延，提高网络吞吐量。

SACK和Reno，Tahoe的主要区别是当一个窗口丢失多个包时两者的不同表现[6]，此时SACK的表现最佳，它能快速从数据的丢失中恢复出来。

SACK能够避免多数的超时和慢启动，其总的性能优于Tahoe和Reno。

由于回路响应时间与网络运行情况密切相关，所以又出现了利用回路响应时间控制拥塞的TCP Vegas算法。

Vegas算法是通过观察以前TCP连接中的RTT值的变化情况来控制拥塞窗口，使拥塞窗口控制在一个合适的值上。

如果RTT变大，Vegas就认为网络拥塞发生，就减少拥塞窗口；反之则增大拥塞窗口。

TCP Vegas相对于TCP Reno在以下三方面做出了改进：第一，TCP Vegas采用一种全新的重传机制，当接受到第一个重复的ACK时就确定该数据包丢失，而不像TCP Reno一样等接收到三个重复的ACK时才确定该数据包丢失，这就使得其对拥塞的反应更加迅速。

第二，TCP Vegas在初次使用慢启动时就以一种更谨慎的方式增加拥塞窗口来减小丢包率。

在慢启动的改进方面，它与拥塞预测的改进机制类似，通过监视吞吐率的变化来决定是否离开慢启动模式。

第三，TCP Vegas采用一种新的拥塞避免机制来矫正TCP Reno的振荡性。

具体的方法是，信源自行估计它发出的被缓存起来的数据包的数量，并尽可能的通过调整拥塞窗口的大小使被缓存起来的数据包的数量介于α和β之间时，下一个回路响应时间（RTT）里拥塞窗口不变，否则拥塞窗口将随着被缓存起来的数据包的数量小于α或者大于β的数量线性的增大或者减小。

TCP Vegas可以提高带宽的利用率，减少重传次数，减少超时次数。

它最大不同于TCP Tahoe，Reno，Sack的就是它以队列延时作为拥塞的标志。