作者：林沛满
出处：Wireshark网络分析就是这么简单
网络之所以能限制发送窗口，是因为它一口气收到太多数据时就会拥塞。拥塞的结果就是丢包，这是发送方最忌惮的。能导致网络拥塞的数据量成为拥塞点，反送方当然希望把发送窗口控制在拥塞点之下，这样就能避免拥塞了。但问题是连网络设备都不知道自己的拥塞点，即便知道了也无法通知发送方。这种情况下，发送方如何避免触碰拥塞点呢？
方案1. 发送方知道自己的网卡带宽，能否以此推测该连接的拥塞点？
不能。因为发送方和接收方之间还有路由器和交换机，其中任何一个设备都可能是瓶颈。比如发送方的网卡是10Gbit/s，而接收方只有1Gbit/s，如果按照10Gbit/s计算肯定会出问题。就算用1Gbit/s来计算也没有意义，因为网络带宽是多个连接共享的，其他连接也会占用一定带宽。
方案2. 逐次增加发送量，知道网络发生拥塞，这样得到的最大发送量能定为该连接的拥塞点吗？
这是一个好方法，但没有这么简单。网络就像马路一样，有的时候很堵，有的时候很空。所以拥塞点是随时改变的动态值。
经过几代人的努力，总算有了一个最靠谱的策略。这个策略就是在发送方维护一个虚拟的拥塞窗口，并利用各种算法是它尽可能接近拥塞点。网络对发送窗口的限制，就是通过拥塞窗口实现的。下面我们就来看看拥塞窗口如何维护。
拥塞控制的过程分为四个阶段：慢启动、拥塞避免、快重传和快恢复
-
慢启动过程思路是不要一开始就发送大量的数据，如果一口气发太多数据就可能遭遇拥塞，所以发送方把拥塞窗口的初始值定得很小。RFC的建议是2个、3个或者4个MSS，具体视MSS大小而定。
如果发出去的包都得到确认，表明还没有达到拥塞点，可以增大拥塞窗口。由于这个阶段发生拥塞的概率很低，所以增速应该快一些。RFC建议的是每收到n个确认，可以吧拥塞窗口增加n个MSS。这个过程增速很快，但是由于技术低，传输速度还是比较慢的，所以被称为慢启动过程。若出现丢包，则将拥塞窗口减半，进入拥塞避免阶段； - 慢启动过程持续一段时间后，拥塞串口达到一个比较大的值。这个时候传输速度比较快，触碰拥塞点的概率也大了，所以不能采用翻倍的慢启动算法，而是要缓慢一点。RFC建议的算法是在每个往返时间增加1个MSS。这个阶段叫拥塞避免过程。
- 当收到对一个报文的三个重复的 ACK 时，认为这个报文的下一个报文丢失了，进入快重传阶段，要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方，可提高网络吞吐量约20%）而不要等到自己发送数据时捎带确认；
- RFC5681 则认为，快重传之后，进入快恢复阶段，为了不该刚发生拥塞的网络雪上加霜，建议把拥塞窗口降到1个MSS，然后再次进入慢启动过程。
- 在《TCP/IP Illustrated》中，Richard Stevens认为：快重传完成后进入快恢复阶段，将临界窗口值修改为当前拥塞窗口值的一半，从这个临界窗口值开始，继续进入拥塞避免阶段，重复上述过程。
其他参考资料：
