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窗口通告後，就啓動堅持定時器，並在定時器溢出的時候向客戶端查詢窗口是否已經增大。(2)在定時器未到，就收到非零通告，則關閉該定時器，併發送數據。
(3)若定時器已到，還沒有收到非零通告，就發探查報文。
(4)如果探查報文ACK的通告窗口爲0，就將堅持定時器的值加倍，TCP的堅持定時器使用1，2，4，8，16……64秒這樣的普通指數退避序列來作爲每一次的溢出時間，重複1、2、3步，如果通告窗口非零，發送數據，關閉定時器。
