网络拥塞控制(四) TCP拥塞控制的其他算法

四、TCP拥塞的其他方面：

1994年，Brakmo提出了一种新的拥塞控制机制TCP Vegas，从另外的一个角度来进行拥塞控制。从前面可以看到，TCP的拥塞控制是基于丢包的，一旦出现丢包，于是调整拥塞窗口，然而由于丢包不一定是由于网络进入了拥塞，但是由于RTT值与网络运行情况有比较密切的关系，于是TCP Vegas利用RTT值的改变来判断网络是否拥塞，从而调整拥塞控制窗口。如果发现RTT在增大，Vegas就认为网络正在发生拥塞，于是开始减小拥塞窗口，如果RTT变小，Vegas认为网络拥塞正在逐步解除，于是再次增加拥塞窗口。由于Vegas不是利用丢包来判断网络可用带宽，而是利用RTT变化来判断，因而可以更精确的探测网络的可用带宽，从而效率更好。然而Vegas的有一个缺陷，并且可以说致命的，最终影响TCP Vegas并没有在互联网上大规模使用。这个问题就是采用TCP Vegas的流的带宽竞争力不及未使用TCP Vegas的流，这是因为网络中路由器只要缓冲了数据，就会造成RTT的变大，如果缓冲区没有溢出的话，并不会发生拥塞，但是由于缓存数据就会导致处理时延，从而RTT变大，特别是在带宽比较小的网络上，只要一开始传输数据，RTT就会急剧增大，这个在无线网络上特别明显。在这种情况下，TCP Vegas降低自己的拥塞窗口，但是只要没有丢包的话，从上面看到标准的TCP是不会降低自己的窗口的，于是两者开始不公平，再这样循环下去，TCP Vegas的效率就非常低了。其实如果所有的TCP都采用Vegas拥塞控制方式的话，流之间的公平性会更好，竞争能力并不是Vegas算法本身的问题。

另外介绍下Limited transmit。这个算法是在拥塞窗口比较小的时候如果在一个传输窗口内有多个包丢失时比较有效率的恢复算法。之前已经讲过，TCP有一个快速恢复的机制，而快速恢复的前提是收到3个重复ACK。然而，接收方发送重复ACK却又需要乱序包的到达才可以触发，TCP在每收到一个乱序包就会立即发送一个重复的ACK给发送端。如果拥塞窗口比较小的时候会发生情况呢？发送方和接收方进入一段互相等待的状况，接收方等待再收到一个包于是发生重复ACK，而发送方却等待第3个重复ACK，如果窗口较小，例如为3，如果此时第一个包丢失了，接收方对第二个和第三个包分别发送了重复ACK，总共两个重复ACK，此时发送端由于窗口的关系不能再发送数据，此时双方进入互等，直到发送方的重传超时计时器到，才能打破该僵局，显然如果是这样的话效率就明显降低，因为重传超时的时间设置为RTT+4×RTTVar，一般该值都比较大。

Limited Transmit就是为了解决这种情况的，它的方法很简单，那就是当收到两个重复ACK时，检测两个条件：

1）接收方的通告窗口rwnd是否允许传输新的数据包，即是否满足rwnd>cwnd？

2）停留在网络中的数据包个数是否小于或等于cwnd+2？

如果这两个条件都满足的话，那么TCP再发送新的数据包，其实第二个条件换个意思理解就是说在这种情况下可以超出拥塞窗口最多再发送两个数据包。假设新的数据包和相应的ACK不被丢失的话，那么有了这两个新的数据包，从而双方可以立即从僵局中恢复出来，发送方接着进入标准的快速恢复。注意的是尽管可以发送两个新的数据包，但是cwnd的值要保持不变，而不能把它增加2。显然Limited Transmit算法比利用超时重传在包乱序时具有更好的鲁棒性。

此外，由于一开始的TCP协议设计中，通常假设网络中乱序现象很少发生，但是随着Internet乱序现象的增多(有两篇文章详细论述过：Packet Reordering is Not Pathological  network Behavior、Measurement and Classification of Out-of-Sequence Packets in a Tier-1 IP Backbone)，TCP会把乱序误认为是丢包的发生，从而降低自己的发生速率，影响了自己的性能。针对这种情况，又有了新的改进算法见此(On Making TCP More Robust to Packet Reordering)，不再详细说明。

另外还有Eifel算法，具体参看RFC3522、RFC4015。Eiffel算法主要是用于TCP发送方更好的区分伪重传，Eifel算法利用了TCP的时间戳选项。

由于网络拥塞控制的重要性，因而TCP的拥塞控制方面的研究及改进非常多，对于标准的TCP拥塞控制，暂时先到此。

   下一节：TCP拥塞控制存在的缺陷。