我们先来看看第一个例子。当应用程序没有及时读取缓存时，发送窗口和接收窗口的变化。考虑以下场景：客户端作为发送方，服务端作为接收方，发送窗口和接收窗口初始大小为 360；服务端非常的繁忙，当收到客户端的数据时，应用层不能及时读取数据。
文章图片
客户端发送 140 字节数据后，可用窗口变为 220 。服务端收到 140 字节数据，但是服务端非常繁忙，应用进程只读取了 40 个字节，还有 100 字节占用着缓冲区，于是接收窗口收缩到了 260 ，最后发送确认信息时，将窗口大小通过给客户端。客户端收到确认和窗口通告报文后，发送窗口减少为 260。客户端发送 180 字节数据，此时可用窗口减少到 80。服务端收到 180 字节数据，但是应用程序没有读取任何数据，这 180 字节直接就留在了缓冲区，于是接收窗口收缩到了 80 ，并在发送确认信息时，通过窗口大小给客户端。客户端收到确认和窗口通告报文后，发送窗口减少为 80。客户端发送 80 字节数据后，可用窗口耗尽。服务端收到 80 字节数据，但是应用程序依然没有读取任何数据，这 80 字节留在了缓冲区，于是接收窗口收缩到了 0，并在发送确认信息时，通过窗口大小给客户端。客户端收到确认和窗口通告报文后，发送窗口减少为 0。可见最后窗口都收缩为 0 了，也就是发生了窗口关闭。当发送方可用窗口变为 0 时，发送方实际上会定时发送窗口探测报文，以便知道接收方的窗口是否发生了改变，这个内容后面会说，这里先简单提一下。我们先来看看第二个例子。当服务端系统资源非常紧张的时候，操心系统可能会直接减少了接收缓冲区大小，这时应用程序又无法及时读取缓存数据，那么这时候就有严重的事情发生了，会出现数据包丢失的现象。
文章图片
说明下每个过程：客户端发送 140 字节的数据，于是可用窗口减少到了 220。服务端因为现在非常的繁忙，操作系统于是就把接收缓存减少了 100 字节，当收到 对 140 数据确认报文后，又因为应用程序没有读取任何数据，所以 140 字节留在了缓冲区中，于是接收窗口大小从 360 收缩成了 100，最后发送确认信息时，通告窗口大小给对方。此时客户端因为还没有收到服务端的通告窗口报文，所以不知道此时接收窗口收缩成了 100，客户端只会看自己的可用窗口还有 220，所以客户端就发送了 180 字节数据，于是可用窗口减少到 40。服务端收到了 180 字节数据时，发现数据大小超过了接收窗口的大小，于是就把数据包丢失了。客户端收到第 2 步时，服务端发送的确认报文和通告窗口报文，尝试减少发送窗口到 100，把窗口的右端向左收缩了 80，此时可用窗口的大小就会出现诡异的负值。所以，如果发生了先减少缓存，再收缩窗口，就会出现丢包的现象。为了防止这种情况发生，TCP 规定是不允许同时减少缓存又收缩窗口的，而是采用先收缩窗口，过段时间在减少缓存，这样就可以避免了丢包情况。窗口关闭在前面我们都看到了，TCP 通过让接收方指明希望从发送方接收的数据大小来进行流量控制。如果窗口大小为 0 时，就会阻止发送方给接收方传递数据，直到窗口变为非 0 为止，这就是窗口关闭。窗口关闭潜在的危险
接收方向发送方通告窗口大小时，是通过 ACK 报文来通告的。那么，当发生窗口关闭时，接收方处理完数据后，会向发送方通告一个窗口非 0 的 ACK 报文，如果这个通告窗口的 ACK 报文在网络中丢失了，那麻烦就大了。
推荐阅读
