TCP通过让接收方指明希望从发送方接收的数据字节数（即窗体大小）来进行流量控制。
假设窗体大小为0会发生什么情况呢？这将有效阻止发送方传送数据，直到窗体变为非0为止。
ACK的传输并不可靠，也就是说，TCP不正确ACK报文段进行确认，TCP仅仅确认那些包括有数据的ACK报文段。
1.坚持定时器
假设一个场景：假设一个确认丢失了，则两方就有可能由于等待对方而使连接终止，接收方等待接收数据（由于它已经向发送方通告了一个非0的窗体），而发送方在等待同意它继续发送数据的窗体更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器（persist timer）来周期性地向接收方查询，以便发现窗体是否已增大。这些从发送方发出的报文段称为窗体探查（window probe）。
计算坚持定时器时使用了普通的TCP指针退避，窗体探查报文包括一个字节的数据。坚持状态与21章介绍的重传超时之间一个不同的特点就是TCP从不放弃发送窗体探查。这些探查每隔60秒发送一次，这个过程将持续到窗体打开或者应用进程使用的连接被终止。
糊涂窗体综合症：接收方能够通告一个小的窗体（而不是一直等到有大的窗体时才通告）。而发送方能够通过这个小窗体发送少量的数据（而不是等待其他的数据以便发送一个大的报文段），即。少量的数据通过连接交换。而不是满长度的报文段，TCP的传输效率可想而知。
怎样避免“糊涂窗体综合症”：
接收方：接收方不通告小窗体，除非添加一个报文段(MMS)或者接收方缓存空间的一半，否则通告为0。
发送方：
(1)能够发送一个满长度的报文段(MMS)
(2)能够发送至少接收方通告窗体一半的报文段
(3)能够发送手头的全部数据而且不希望接收ACK。或者该连接禁止了Nagle算法时，能够发送随意数据。
坚持定时器工作流程:
(1)发送端收到0窗体通告后，就启动坚持定时器，并在定时器溢出的时候向client查询窗体是否已经增大。(2)在定时器未到，就收到非零通告，则关闭该定时器。并发送数据。
(3)若定时器已到，还没有收到非零通告，就发探查报文。
(4)假设探查报文ACK的通告窗体为0。就将坚持定时器的值加倍，TCP的坚持定时器使用1，2，4。8，16……64秒这种普通指数退避序列来作为每一次的溢出时间。反复1、2、3步。假设通告窗体非零，发送数据，关闭定时器。
作者原创，转载请标明原处：http://blog.csdn.net/xifeijian/article/details/44263605