计算机网络——TCP的流量控制和拥塞控制

5.4 TCP的流量控制

TCP的流量控制

确实，发送数据并不是越快越好，要让对方来得及接收，这就是流量控制

利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。

先不考虑拥塞的情况，假设B告诉A，我的接收窗口可以接收400，那么A也将自己的发送窗口设置为400。

用自己的语言描述以下整个过程，A把自己的发送窗口设置为400，但是每一次只发送100.
如下图发送seq=1，表示发送数据报的首部为1，seq=101，表示发送数据报的首部为101.

如下图所示，seq=201的数据报发送过程中丢失了。

这时候接收方给发送方发送确认分组了，ACK=1表示是确认分组，ack=201表示201前的数据报都接收到了，rwnd=300，这是第一个流量控制，将接收窗口调整为300，对主机A进行流控。

然后窗口向前滑动，接受完的就可以丢弃。

然后接收窗口就可以相应改变为新的300.

然后对于201-300的数据的超时重传到了，然后就重传该数据分组，当落入窗口的三个数据分组都发送完毕后，当再次收到501号前的数据的累计确认后，就可以再一次调整窗口。

调整为100后，主机可以发送500到600的数据报。

然后再次收到累计确认，

这次的流量控制，接收窗口调整为0，就甭能再发送数据了。

现在不能再发送了，因为发送窗口被调整为0

而如此主机B这是缓存中又有位置了，可以发送非零窗口给A，通知它可以继续发送。

但是如果恰好此时B发送给A的非零通知丢失了，而A一直在等待B的非零通知，B一直在等待A的数据，这种时候大家互相等待，就会出现TCP的死锁问题

为了解决这个问题，设置了一个持续计时器。

主机A在接收到0窗口通知时，就立即启动一个计时器。当计时器超时时，主机A立即发送一个携带一字节数据的零窗口探测报文段

如果主机B现在还是0，就在接收到零窗口探测报文段后仍然发送主机的接收窗口仍然为0.

主机A再次接收到零窗口，就再次开启一个计时器。

反正没接收到非零时，就一直计时，一直探测。

如果零窗口探测报文丢失了，不怕，
因为零窗口探测报文也有计时器，如果丢失了，就会重传

TCP的拥塞控制

为什么会产生拥塞？

因为我们传到网络上的数据太多了，太大了，大过了硬件所能处理的数据的上限。

所以产生了发的数据来不及传送的状态。

主要是怎么判断拥塞呢

• 重传定时器超时
• 收到三个相同（重复）的ACK

假设第二个分组发送过程中丢失了，即使345都到达了，但是它们都只会返回还未收到2的确认分组ACK。

这里重要的是，收到ACK的时候 只是可能或者即将发生拥塞，而超时就已经是发生拥塞了

慢开始：

第一个轮次只发少量的分组（1个）
然后随着轮次越来越大，发送分组的个数也就越来越多，随指数增长。

1. 我们为其设置一个阈值，因为希望拥塞越慢越好，所以再拥塞窗口为16之后，就不要让其指数增长了，就让其每次加1加1。
2. 到了遇到超时的状态，这是非常严重的状态，就直接让其恢复到1，让其继续慢开始。而且它的阈值得减为上次超时的拥塞窗口的一半
3. 然后发现了3-ACK的拥塞状态，不过这种还好，因为它不是一种很严重的状态，所以不需要回到1.而可以直接让其减到一半，然后再慢慢加1就可以了。

总结一下就是

 慢开始，拥塞避免，快重传，快恢复