发送端在窗口变成0后，会发ZWP的包给接收方，来探测目前接收端的窗口大小，让接收方来ack他的Window尺寸。一般这个值会设置成3次，每次大约30-60秒（不同的实现可能会不一样）。如果3次过后还是0的话，有的TCP实现就会发RST掉这个连接。
注意：只要有等待的地方都可能出现DDoS攻击。攻击者可以在和Server建立好连接后，就向Server通告一个0窗口，然后Server端就只能等待进行ZWP，于是攻击者会并发大量的这样的请求，把Server端的资源耗尽。
Silly Window Syndrome
如果接收端处理能力很慢，这样接收端的窗口很快被填满，然后接收处理完几个字节，腾出几个字节的窗口后，通知发送端，这个时候发送端马上就发送几个字节给接收端吗？发送的话会不会太浪费了，就像一艘万吨油轮只装上几斤的油就开去目的地一样。我们的TCP+IP头有40个字节，为了几个字节，要达上这么大的开销，这太不经济了。
对于发送端产生数据的能力很弱也一样，如果发送端慢吞吞产生几个字节的数据要发送，这个时候该不该立即发送呢？还是累积多点在发送？
本质就是一个避免发送大量小包的问题。造成这个问题原因有二：
接收端一直在通知一个小的窗口;
在接收端解决这个问题，David D Clark’s 方案，如果收到的数据导致window size小于某个值，就ACK一个0窗口，这就阻止发送端在发数据过来。等到接收端处理了一些数据后windows size 大于等于了MSS，或者buffer有一半为空，就可以通告一个非0窗口。
发送端本身问题，一直在发送小包。这个问题，TCP中有个术语叫Silly Window Syndrome(糊涂窗口综合症)。解决这个问题的思路有两：
接收端不通知小窗口，
发送端积累一下数据在发送。
是在发送端解决这个问题，有个著名的Nagle’s algorithm。Nagle 算法的规则
如果包长度达到 MSS ，则允许发送；
如果该包含有 FIN ，则允许发送；
设置了 TCP_NODELAY 选项，则允许发送；
设置 TCP_CORK 选项时，若所有发出去的小数据包（包长度小于 MSS ）均被确认，则允许发送；
上述条件都未满足，但发生了超时（一般为 200ms ），则立即发送。
规则[4]指出TCP连接上最多只能有一个未被确认的小数据包。从规则[4]可以看出Nagle算法并不禁止发送小的数据包(超时时间内)，而是避免发送大量小的数据包。由于Nagle算法是依赖ACK的，如果ACK很快的话，也会出现一直发小包的情况，造成网络利用率低。TCP_CORK选项则是禁止发送小的数据包(超时时间内)，设置该选项后，TCP会尽力把小数据包拼接成一个大的数据包（一个 MTU）再发送出去，当然也不会一直等，发生了超时（一般为 200ms ），也立即发送。Nagle 算法和CP_CORK 选项提高了网络的利用率，但是增加是延时。从规则[3]可以看出，设置TCP_NODELAY 选项，就是完全禁用Nagle 算法了。
这里要说一个小插曲，Nagle算法和延迟确认(Delayed Acknoledgement)一起，当出现( write-write-read)的时候会引发一个40ms的延时问题，这个问题在HTTP svr中体现的比较明显。场景如下：
客户端在请求下载HTTP svr中的一个小文件，一般情况下，HTTP svr都是先发送HTTP响应头部，然后在发送HTTP响应BODY(特别是比较多的实现在发送文件的实施采用的是sendfile系统调用，这就出现write-write-read模式了)。当发送头部的时候，由于头部较小，于是形成一个小的TCP包发送到客户端，这个时候开始发送body，由于body也较小，这样还是形成一个小的TCP数据包，根据Nagle算法，HTTP svr已经发送一个小的数据包了，在收到第一个小包的ACK后或等待200ms超时后才能在发小包，HTTP svr不能发送这个body小TCP包；
客户端收到http响应头后，由于这是一个小的TCP包，于是客户端开启延迟确认，客户端在等待Svr的第二个包来在一起确认或等待一个超时(一般是40ms)在发送ACK包；这样就出现了你等我、然而我也在等你的死锁状态，于是出现最多的情况是客户端等待一个40ms的超时，然后发送ACK给HTTP svr，HTTP svr收到ACK包后在发送body部分。大家在测HTTP svr的时候就要留意这个问题了。
推荐阅读《TCP/IP之TCP协议：流量控制（滑动窗口协议）》
TCP的拥塞控制