TCP流量控制

为什么要流量控制

双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来，这时候接收方只能把处理不过来的数据存在缓存区里（失序的数据包也会被存放在缓存区里）。

如果缓存区满了发送方还在疯狂着发送数据，接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源，因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。

对发送方发送速率的控制，我们称之为流量控制。

利用滑动窗口实现流量控制

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

当双方建立连接时，发送方和接受方通过TCP报文首部窗口字段进行传输。

接收方每次收到数据包，可以在发送确定报文的时候，通过TCP首部的Window字段告诉发送方自己的缓存区还剩余多少是空闲的，我们也把缓存区的剩余大小称之为接收窗口大小。

发送方收到之后，便会调整自己的发送速率，也就是调整自己发送窗口的大小，当发送方收到接收窗口的大小为0时，发送方就会停止发送数据，防止出现大量丢包情况的发生。

 发送方何时再继续发送数据

当发送方收到接受窗口 win = 0 时，这时发送方停止发送报文，并且同时开启一个定时器，每隔一段时间就发个试探报文（这个特殊的报文只有一个字节）去询问接收方，试探是否可以继续发送数据了，如果可以，接收方就告诉他此时接受窗口的大小；如果接受窗口大小还是为0，则发送方再次刷新启动定时器。

问题

TCP通信有几个窗口 

 由于TCP/IP支持全双工传输，因此通信的双方都拥有两个滑动窗口，一个用于接受数据，称之为接收窗口；一个用于发送数据，称之为拥塞窗口(即发送窗口)。指出接受窗口大小的通知我们称之为窗口通告。

接收窗口的大小固定吗

在早期的TCP协议中，接受接受窗口的大小确实是固定的，不过随着网络的快速发展，固定大小的窗口太不灵活了，成为TCP性能瓶颈之一，也就是说，在现在的TCP协议中，接受窗口的大小是根据某种算法动态调整的。

接受窗口越大越好吗

接受窗口如果太小的话，显然这是不行的，这会严重浪费链路利用率，增加丢包率。那是否越大越好呢？当接收窗口达到某个值的时候，再增大的话也不怎么会减少丢包率的了，而且还会更加消耗内存。所以接收窗口的大小必须根据网络环境以及发送发的的拥塞窗口来动态调整。

发送窗口和接受窗口相等吗

接收方在发送确认报文的时候，会告诉发送发自己的接收窗口大小，而发送方的发送窗口会据此来设置自己的发送窗口，但这并不意味着他们就会相等。首先接收方把确认报文发出去的那一刻，就已经在一边处理堆在自己缓存区的数据了，所以一般情况下接收窗口 >= 发送窗口。

糊涂窗口综合症

如果接收方太忙了，来不及取走接收窗口里的数据，那么就会导致发送方的发送窗口越来越小。

到最后，如果接收方腾出几个字节并告诉发送方现在有几个字节的窗口，而发送方会义无反顾地发送这几个字节，这就是糊涂窗口综合症。

要知道，我们的 TCP + IP 头有 40 个字节，为了传输那几个字节的数据，要达上这么大的开销，这太不经济了。

糊涂窗口综合症场景：

接收方的窗口大小是 360 字节，但接收方由于某些原因陷入困境，假设接收方的应用层读取的能力如下：

• 接收方每接收 3 个字节，应用程序就只能从缓冲区中读取 1 个字节的数据；
• 在下一个发送方的 TCP 段到达之前，应用程序还从缓冲区中读取了 40 个额外的字节；

每个过程的窗口大小的变化，在图中都描述的很清楚了，可以发现窗口不断减少了，并且发送的数据都是比较小的了。

所以，糊涂窗口综合症的现象是可以发生在发送方和接收方：

• 接收方可以通告一个小的窗口
• 而发送方可以发送小数据

于是，要解决糊涂窗口综合症，就解决上面两个问题就可以了

• Clark解决方法

当接收方的窗口小于MSS（最大长度的报文段）或者小于1/2 缓存时，就会向发送方回复win=0，也就阻止了发送方再发数据过来。

• 让发送方避免发送小数据

使用 Nagle 算法，该算法的思路是延时处理，它满足以下两个条件中的一条才可以发送数据：

• 要等到窗口大小 >= MSS 或是 数据大小 >= MSS
• 收到之前发送数据的 ack 回包

只要没满足上面条件中的一条，发送方一直在囤积数据，直到满足上面的发送条件。

另外，Nagle 算法默认是打开的，如果对于一些需要小数据包交互的场景的程序，比如，telnet 或 ssh 这样的交互性比较强的程序，则需要关闭 Nagle 算法。

可以在 Socket 设置 TCP_NODELAY 选项来关闭这个算法（关闭 Nagle 算法没有全局参数，需要根据每个应用自己的特点来关闭）