JAVA面试题分享三百零四：TCP的流量控制是如何实现的？

目录

一、前言

二、滑动窗口

---

一、前言

流量控制是为了控制发送方发送速率，保证接收方来得及接收。TCP 利用滑动窗口来实现流量控制，接收方根据自己的处理能力，动态调整自己的可接收数据窗口大小，通过ACK报文将窗口大小告知发送方，发送方根据收到的窗口大小，调整发送数据的流量。

二、滑动窗口

有了滑动窗口，发送方就算有海量等待发送的数据，也只能按照接收方给出的窗口大小来慢慢发。滑动窗口带来的另一个好处是，只要窗口大小允许（并且满足发送条件），发送方不必等待前面数据的ACK，也可以发送数据。接收方可以延时确认，用后面数据包的ACK，一并把前面的数据都确认了，减少了报文数量。

发送端和接收端各自有自己的滑动窗口。发送方的滑动窗口可以分为四个部分：

1 已发送并且收到ACK确认的数据

2 已发送但未收到ACK确认的数据

3 未发送但可以发送的的数据

4 不允许被发送的数据

接收方的滑动窗口可以分为三个部分：

1 接收并已确认的数据

2 等待接收且允许发送方发送的数据（接收窗口）

3 不可接收且不允许发送方发送的数据

在数据传输过程中，接收方会不断更新窗口大小，通过TCP报文段中的窗口字段，来告知发送方当前可接收的数据量。

发送方根据接收方的窗口大小来调整发送的数据量，以确保发送的数据不会超过接收方的处理能力。如果接收方的窗口变小，发送方会减少发送的数据量以避免数据丢失或拥塞。当接收方的窗口变大时，发送方可以增加发送的数据量，从而提高数据传输的效率。

需要注意的是，如果接收方太忙了，接收方有可能会关闭窗口，即设置窗口大小为0，此时发送方停止发送数据，直到窗口重新打开。为了防止重新打开窗口的报文丢失造成死锁，发送方在窗口关闭后开启，启动一个定时器，定时发送窗口探测报文，这样接收方在确认这个探测报文时，就可以给出自己现在的接收窗口大小。

另外，如果接收方太忙了，来不及取走接收窗口里的数据，那么就会导致发送方的发送窗口越来越小，如果发送方每次就发送几个字节给接收方，显然是不划算的，因为这时报文中的报文头部就占了几十个字节，而真实传输的有用的数据却只有几个字节。

这个问题叫做TCP的糊涂窗口综合症，解决糊涂窗口综合症，一方面是让接收方不通告小窗口给发送方，通常情况下，当接收窗口小于TCP最大报文段长度MSS和接收缓存一半大小中的最小值时，就会向发送方通告窗口为 0，也就阻止了发送方再发数据过来。另一方面，发送方也可以开启Nagle算法，避免发送小数据给接收方。