tcp通過讓接收方指明希望從傳送方接收的資料位元組數（即視窗大小）來進行流量控制。如果視窗大小為 0會發生什麼情況呢？這將有效地阻止傳送方傳送資料，直到視窗變為非0為止。
tcp不對ack報文段進行確認， tcp只確認那些包含有資料的ack報文段。
如果乙個確認丟失了，則雙方就有可能因為等待對方而使連線終止：接收方等待接收資料（因為它已經向傳送方通告了乙個非 0的視窗），而傳送方在等待允許它繼續傳送資料的視窗更新。為防止這種死鎖情況的發生，傳送方使用乙個堅持定時器 (persist timer)來周期性地向接收方查詢，以便發現視窗是否已增大。這些從傳送方發出的報文段稱為視窗探查 (window probe)。
為了觀察到實際中的堅持定時器，我們啟動乙個接收程序。它監聽來自客戶的連線請求，接受該連線請求，然後在從網上讀取資料前休眠很長一段時間。
sock程式可以通過指定乙個暫停選項 - p使伺服器在接受連線和進行第一次讀動作之間進入休眠。我們以這種方式呼叫伺服器：
svr4 % sock -i -s -p100000 5555該命令在從網路上讀資料之前休眠 100 000秒（27.8小時）。客戶執行在主機bsdi上，並向伺服器的5555埠執行1024位元組的寫操作。下圖給出了tcpdump的輸出結果（我們已經在結果中去掉了連線的建立過程）。
報文段1 ~ 1 3顯示的是從客戶到伺服器的正常的資料傳輸過程，有9216個位元組的資料填充了視窗。伺服器通告視窗大小為4096位元組，且預設的插口快取大小為4096位元組。但實際上它一共接收了9216位元組的資料，這是在s v r 4中tcp**和流子系統(stream subsystem)之間某種形式互動的結果。
在報文段1 3中，伺服器確認了前面 4個資料報文段，然後通告視窗為 0，從而使客戶停止傳送任何其他的資料。這就引起客戶設定其堅持定時器。如果在該定時器時間到時客戶還沒有接收到乙個視窗更新，它就探查這個空的視窗以決定視窗更新是否丟失。由於伺服器程序處於休眠狀態，所以tcp快取9216位元組的資料並等待應用程序讀取。
請注意客戶發出的視窗探查之間的時間間隔。在收到乙個大小為 0的視窗通告後的第1個（報文段1 4）間隔為4.949秒，下乙個（報文段16）間隔是4.996秒，隨後的間隔分別約為6,12,24,48和60秒。
為什麼這些間隔總是比5、6、12、24、48和60小乙個零點幾秒呢？因為這些探查被tcp的500 ms定時器超時例程所觸發。當定時器時間到時，就傳送視窗探查，並大約在4 ms之後收到乙個應答。
接收到應答使得定時器被重新啟動，但到下乙個時鐘滴答之間的時間則約為500減4ms。計算堅持定時器時使用了普通的 tcp指數退避。對乙個典型的區域網連線，首次超時時間算出來是1 . 5秒，第2次的超時值增加一倍，為 3秒，再下次乘以4為6秒，之後再乘以8為1 2秒等。但是堅持定時器總是在5 ~ 6 0秒之間，這與我們在上圖中觀察到的現象一致。
視窗探查包含乙個位元組的資料（序號為 9 2 1 7）。tcp總是允許在關閉連線前傳送乙個位元組的資料。請注意，儘管如此，所返回的視窗為0的ack並不是確認該位元組（它們確認了包括9216在內的所有資料），因此這個位元組被持續重傳。
堅持狀態與重傳超時之間乙個不同的特點就是 tcp從不放棄傳送視窗探查。這些探查每隔60秒傳送一次，這個過程將持續到或者視窗被開啟，或者應用程序使用的連線被終止。
產生原因：
首先，接收端傳送乙個視窗大小為0的ack報文；傳送端收到該訊號後，等待接收方傳送視窗大小大於0的ack.
然後，接收端傳送視窗大小大於0的報文，但是該報文丟失，因為tcp並不對ack報文進行確認，這就造成了
接收方等待接收資料，而傳送方仍然等待視窗大於0的ack，產生死鎖。
解決：傳送方使用乙個堅持定時器 (persist timer)來周期性地向接收方查詢，以便發現視窗是否已增大。這些從傳送方發出的報文段稱為視窗探查 (window probe)。
TCP的四個定時器
希望收到另一端的確認。如 一端傳送資料，希望收到ack，但遲遲未收到ack，就會重傳，這裡經過多長時間重傳由重傳定時器決定。使視窗大小資訊保持不斷流動。如 看另一篇博文。檢測乙個空閒連線的另一端何時崩潰或重啟。連線建立好後，連線上無資料傳輸，連線仍然繼續保持。這就導致了乙個問題，如客戶端崩潰了，伺服...
如何管理定時器 詳解TCP四種定時器和四個定時器
重傳計時器 retransmission timer 堅持計時器 persistent timer 保活計時器 keeplive timer 時間等待計時器 time wait timer。1 重傳計時器 很明顯重傳定時器是用來計算tcp報文段的超時重傳時間的 至於超時重傳時間的確定，這裡涉及到一大...
TCP IP詳解之TCP的堅持定時器5
tcp的堅持定時器章節目錄 1.乙個例子 2.糊塗視窗綜合症 可以在圖20 3中看到這種情況。當傳送方接收到報文段9時，它開啟被報文段8關閉的視窗並立即開始傳送資料。tcp必須能夠處理開啟此視窗的ack 報文段9 丟失的情況。ack的傳輸並不可靠，也就是說，tcp不對ack報文段進行確認，tcp只確...