因为tcp传输接收方和发送方的发送和接收处理的能力不会对等，所以会利用滑动窗口让发送方根据接收方的实际情况发送适当流量的数据，这就是流量控制。
举个例子当服务器作为接收方处理数据不及时的时候，如何借助滑动窗口去进行流量限制。发送的客户端和服务器初始窗口大小是360。
image.png
最后窗口收缩到了0，发送了窗口关闭，当发生窗口关闭的时候，发送方也会发探测报文定期探测接收方的接收窗口有没有变动，或者当接收方处理好数据的时候也会通知发送方。这样也保证了不会因为报文丢失导致了死锁的现象。
image.png
但是窗口探测一般也有次数--3 次，每次大约 30-60s。如果 3 次过后接收窗口还是 0 的话，有的 TCP 实现就会发 RST 报文来中断连接。
再假设一个场景，如果接收窗口突然有几个字节的空间，这个场景也去通知发送方，或者发送方检测到接收方窗口有几个字节就立马发送。tcp头部啥的都几十字节，这样传输过去肯定是没意义的，所以这个也叫糊涂窗口综合征。
image.png
要避免这个问题，一般采取两个方法。
- 让接收方不通告小窗口给发送方
当「窗口大小」小于 min( MSS，缓存空间/2 ) ，也就是小于 MSS 与 1/2 缓存大小中的最小值时，就会
向发送方通告窗口为 0 ，也就阻止了发送方再发数据过来。
等到接收方处理了一些数据后，窗口大小 >= MSS，或者接收方缓存空间有⼀一半可以使用，就可以把窗
口打开让发送方发送数据过来。 - 让发送方避免发小数据
这就要使用nagel算法了- 等到窗口大小大于或者等于 MSS, 或者数据大小 >= mss
- 收到之前发送数据的ack包
只有上面两种情况会继续发，否则就囤积数据。
