tcp的运输控制分为tcp流量控制和tcp拥塞控制,这里先讲tcp的拥塞控制。
为了讲清楚tcp的拥塞控制，还是利用那个渡河的场景。为了更好的说明问题，这里把渡人换成搬粮食。
话说东村要往西村运输粮食，只能走水路。每天都会有大量的粮食从东村经码头运往西村。由于工作量繁重，运输工人们都希望能尽快把粮食运输到西村。加上水面交通繁忙，各式各样的商船客船往来络绎不绝，更加加大了搬运的困难性。
在开始运输粮食的时候，工人们为了加快进程，拼命搬运粮食，一船接一船的发送粮食。可是由于过往船只太多，水面出现拥堵，工人们只好等待，这样反而降低了运输的效率。工人们想这也不是个事，后来决定改变策略：首先运输一船粮食过去，该船也有检测水面拥堵状况的作用。船到达对岸后卸掉粮食立即返回。如果船只能够在很短的时间内返回，说明水面交通状况还好，可以继续搬运粮食。接下来搬运2船粮食过去，如果依旧能够在预定的时间内返回，则继续搬运3船粮食，依次类推。
后来发现这样搬运还是有点慢，因为根据经验，要一次发送很多船时才会出现堵塞。所以工人们觉得刚开始的时候可以加快运输速度，他们决定发送的船只数量是上一次的两倍。
按照这样，每次都比前一次多发一倍数量的船过去，到某个时候肯定会出现水面堵塞的情形。根据长期搬运的经验，工人们总结出了一个数量ssthresh，当一次运输船只的数量到达这个数时就降低增速，改为每次比前一次多发一只船。我们把前面的阶段叫慢启动发船阶段，后面的阶段叫拥塞避免发船阶段。
随着每次发送船只的数量越来越多，终于还是堵塞了。在东村岸上的工人怎么知道堵塞了呢？前面说到根据船只返回的时间。岸上的工人看到船只到了预定的时间还没有返回，就知道水面堵塞了。于是他们决定回到刚开始的时候，只发送一只船过去（为什么不停止发送呢，因为这个也是有时间成本的。堵塞总会解决，后面停止发送也会耽搁时间）。然后再上演之前的节奏。
后来发现这样做也太sb了。因为一旦拥塞解除，后面的运输力量就跟不上了。所以工人们提出了要快速恢复运输的想法，他们决定堵塞后下次发送船只的数量为阈值ssthresh的一半，然后下次再增加1。这样既不会让水面继续堵塞，也不会在堵塞后使后面的运输跟不上。
tcp的拥塞控制的思想和上面运输粮食的策略类似，也有慢启动阶段和拥塞避免阶段，拥塞后也会有快速恢复。下图可以说明这个问题：
tcp拥塞后的可能还有快速重传的操作。先来回忆一下，发送方如何判定产生拥塞？已知的一种情况是对方回复 ack 超时。其实还有一种情况，如果发送方连续收到接收方多个重复的 ack（接收方不会没事发送重复的 ack 的），也说明网络生产拥塞。为什么呢？
首先对于接收方来说，如果接收方收到一个失序的报文段，就立即回送一个 ACK 给发送方，而不是等待发送延时的 ACK（请参考前面确认延迟）。所谓失序的报文是指，用户没有按照顺序收到 TCP 报文段，比如接收方收到了报文 M1, M2, M4，那么 M4 就称为失序 报文。
这样做的目的是可以让发送方尽可能早的知道报文段 M3 未到达接收方。快重传算法规定，如果发送方一连收到 3 个重复的确认，就应当立即传送对方未收到的报文 M3，而不必等待 M3 的重传计时器到期。下图说明这个问题：
下一篇：
欢迎关注公众号『白话互联网技术』。一个把互联网/编程技术当故事讲的公众号。如果有任何技术或者职业方面的问题需要我提供帮助，也可通过这个公众号与我取得联系。
