关于TCP拥塞控制的理解

TCP的可靠传输要求发送方受到两个控制：流量控制和拥塞控制。前者是为了避免使接收方缓存溢出，后者是为了避免网络的拥塞对时延和接收的影响。由于教材中这一部分的讲解有些啰嗦，我希望能讲讲自己的理解。
首先需要明确TCP拥塞控制的核心思想就是两点：1.在没有发生拥塞的时候适当地增大拥塞窗口(cwnd)；
2.在发生拥塞的时候适当地减小cwnd。
因此，拥塞控制算法要考虑的事情就可以归纳为以下三点：1.发送方如何感知TCP传输路径上是否存在拥塞？
2.发送方在没有拥塞时如何调整cwnd？
3.发送方感知到拥塞时该如何减小cwnd？

一.感知拥塞

当发生拥塞时，在TCP传输路径上的一台或多台路由器会溢出，导致某一个包被丢弃，这个包会引发丢包事件，那么发送方就会知道这个路径发生了拥塞。
我们定义一个TCP的丢包事件：出现超时，或者收到来自接收方的3个冗余的ACK(此处强调是冗余的，所以这个序号的包实际上是收到了4个ACK)。

二.拥塞控制算法

下面就是经典的TCP拥塞控制算法的细节介绍，这个算法包括三部分：慢启动，拥塞避免和快速恢复。
TCP连接刚开始时，cwnd会被初始化为1个MSS(最大报文段长度)，这时候发送速率很小，很可能是远小于带宽限制，发送方会希望可以迅速达到带宽限制。此时就是慢启动状态，cwnd以1个MSS开始并在每次收到确认包时将cwnd增加1个MSS，因此实际上每经过一个RTT，cwnd都会翻倍。所以TCP发送速率初始值小，但在慢启动阶段是以指数增长。
那么，这样的指数增长该在何时结束呢？
首先，如果发生了超时的丢包事件，发送方会将cwnd置为1并重新开始慢启动算法，而且会将慢启动阈值(ssthresh)设为发生拥塞时的cwnd的一半。
其次，哪怕没有发生拥塞事件，只要cwnd大于或等于当前的ssthresh也会结束指数增长，由于此时如果再将cwnd翻倍将会使其达到上一次发生拥塞时的值，因此发送方保守地将cwnd的增长步长设为1，这就是拥塞避免算法，它将结束于丢包事件。
第三种情况是当发生了另一种丢包事件–收到三个冗余ACK时，TCP会采取一种相对柔和的方式应对：将cwnd减半，并将ssthresh设为cwnd的一半，再继续执行拥塞避免算法(此时cwnd=ssthresh)。
在这里，我们还没有提到快速恢复算法，但其实它已经涵盖在上述的窗口变化中了。快速重传算法要求：**针对不同的丢包事件，TCP采取不同的应对方案。**不过这只是一个可选的优化方案，在TCP早期版本TCP Tahoe中，两种丢包事件采取的方案是一样的，即cwnd设为1并且ssthresh设为cwnd的一半；但在TCP Reno中采取的方案就是上面说到的了。
上述的算法还有一个问题没有讲：如何使得cwnd以1为步长增长？对于cwnd翻倍的方式我们已经讲了，每当收到一个ACK就将cwnd加1，累积起来便是翻倍。而要让cwnd每过一个RTT增加1，就要让其在每次收到ACK时只增长1/cwnd，注意：这里的cwnd单位是MSS。假设当前的cwnd为10，每到一个ACK时cwnd增加0.1个MSS(由于TCP是面向字节流的，这里的0.1个MSS其实很好办)，当10个ACK都被收到了之后cwnd便增加了1。