tcp的堅持定時器章節目錄
1.乙個例子
2.糊塗視窗綜合症
可以在圖20-3中看到這種情況。當傳送方接收到報文段9時，它開啟被報文段8關閉的視窗並立即開始傳送資料。tcp必須能夠處理開啟此視窗的ack（報文段9）丟失的情況。ack的傳輸並不可靠，也就是說，tcp不對ack報文段進行確認，tcp只確認那些包含有資料的ack報文段。
如果乙個確認丟失了，則雙方就有可能因為等待對方而使連線終止：接收方等待接收資料（因為它已經向傳送方通告了乙個非0的視窗），而傳送方在等待允許它繼續傳送資料的視窗更新。為防止這種死鎖情況的發生，傳送方使用乙個堅持定時器(persisttimer)來周期性地向接收方查詢，以便發現視窗是否已增大。這些從傳送方發出的報文段稱為視窗探查(window probe)。
為什麼這些間隔總是比5、6、12、24、48和60小乙個零點幾秒呢？因為這些探查被tcp的500ms定時器超時例程所觸發。當定時器時間到時，就傳送視窗探查，並大約在4ms之後收到乙個應答。接收到應答使得定時器被重新啟動，但到下乙個時鐘滴答之間的時間則約為500減4ms。
計算堅持定時器時使用了普通的tcp指數退避。對乙個典型的區域網連線，首次超時時間算出來是1.5秒，第2次的超時值增加一倍，為3秒，再下次乘以4為6秒，之後再乘以8為12秒等。但是堅持定時器總是在5~60秒之間，這與我們在圖22-1中觀察到的現象一致。視窗探查包含乙個位元組的資料（序號為9217）。tcp總是允許在關閉連線前傳送乙個位元組的資料。請注意，儘管如此，所返回的視窗為0的ack並不是確認該位元組（它們確認了包括9216在內的所有資料），因此這個位元組被持續重傳。
堅持狀態與第21章中介紹的重傳超時之間乙個不同的特點就是tcp從不放棄傳送視窗探查。這些探查每隔60秒傳送一次，這個過程將持續到或者視窗被開啟，或者應用程序使用的連線被終止。
在連線的一方需要傳送資料但對方已通告視窗大小為0時，就需要設定tcp的堅持定時器。傳送方使用與第21章類似的重傳間隔時間，不斷地探查已關閉的視窗。這個探查過程將一直持續下去。
當執行乙個例子來觀察堅持定時器時，我們還觀察到了tcp的避免出現糊塗視窗綜合症的現象。這就是使tcp避免通告小的視窗大小或傳送小的報文段。在我們的例子中，可以觀察到傳送方和接收方為避免糊塗視窗綜合症所使用的策略。
當接收到來自傳送方的資料時，接收方快取中的資料增加，而當應用程序從快取中讀取資料時，資料就減少。接下來我們關注的是接收方發給傳送方的視窗通告以及這些視窗通告是什麼。這樣就可以使我們看到接收方是如何避免糊塗視窗綜合症的。
前4個資料報文段及其ack（報文段1~5）表示傳送方正在填充接收方的快取。在那個時刻傳送方停止了傳送，但仍然有更多的資料需要傳送。它將自己的堅持定時器置為最小值5分鐘。當堅持定時器時間到時，就傳送出1個位元組的資料（報文段6）。接收的應用程序已經從接收快取中讀取了256位元組的資料（在時刻3.99），因此這個位元組被接受並被確認（報文段7段）。但是通告視窗仍為0，由於接收方仍然沒有足夠的空間來接收乙個滿長度的報文，或者不能騰出快取空間的一半。這就是接收方的糊塗視窗避免措施。
傳送方的堅持定時器被復位，並在5秒後再次到時（在時刻10.151）。然後又傳送乙個位元組並被確認（報文段8和9），而接收方的快取空間還不夠用（1022位元組），使得通告視窗為0。
傳送方的堅持定時器在時刻15.151再次時間到，又傳送了另乙個位元組並被確認（報文段10和11）。這一次由於接收方有1533位元組的有效快取空間，因此通告了乙個非0視窗。傳送方立即利用這個視窗傳送了1024位元組的資料（報文段12）。對這1024位元組資料的確認（報文段13）通告其視窗為509位元組。這看起來與我們在前面看到的小視窗通告相牴觸。
在這裡之所以發生這種情況，是因為報文段11段通告了乙個大小為1533位元組的視窗，而傳送方只使用了其中的1024位元組。如果在報文段13中的ack通告其視窗為0，就會違反視窗的右邊沿不能向左邊沿移動而導致視窗收縮的tcp原則（見第20.3節）。這就是為什麼必須通告乙個509位元組的視窗的原因。
接下來我們看到傳送方沒有立即向這個小視窗傳送資料。這就是傳送方採取的糊塗視窗避免策略。相反，它等待另乙個堅持定時器在時刻20.151到時間，並在該時刻傳送509位元組的資料。儘管它最終還是傳送了乙個長度為509位元組的小資料段，但在傳送前它等待了5秒鐘，看是否會有乙個ack到達，以便可以將視窗開得更大。這509位元組的資料使得接收快取僅剩下768位元組的有效空間，因此接收方通告視窗為0（報文段15）。
堅持定時器在時刻25.151再次到時間，傳送方傳送1個位元組，於是接收快取中有1279位元組的可用空間，這就是在報文段17所通告的視窗大小。
傳送方只有另外的511個位元組的資料需要傳送，因此在收到1279的視窗通告後立刻傳送了這些資料（報文段18）。這個報文段也帶有fin標誌。接收方確認資料和fin，並通告視窗大小為767。
由於傳送應用程序在執行完6個1024位元組的寫操作後發出關閉命令，傳送方的連線從established狀態轉變到fin_wait_1狀態，再到fin_wait_2狀態（見圖18-12）。它一直處於這個狀態，直到收到對方的fin。在這個狀態上沒有設定定時器（回憶我們在18.6節結束時的討論），因為它在報文段18中傳送的fin被報文段19確認。這就是為什麼我們看到傳送方直到接收到fin（報文段21）為止沒有傳送其他任何資料的原因。
接收應用程序繼續每隔2秒從接收快取區中讀取256個位元組的資料。為什麼在時刻39.99傳送ack（報文段20）呢？這是因為應用程序在時刻39.99讀取資料時，接收快取中的可用空間已經從原來通告的767（報文段19）變為2816，這相當於接收快取中增加了額外的2049位元組的空間。回憶本節開始講的第1個規則，因為現在接收快取已經增加了其空間的一半，因此接收方現在傳送視窗更新。這意味著每次當應用程序從tcp的接收快取中讀取資料時，接收的tcp將檢查是否需要更新傳送視窗。
應用程序在時間51.99發出最後乙個讀操作，然後收到乙個檔案結束標誌，因為快取已經變空。這就導致了最後兩個完成連線終止的報文段（報文段21和22）的傳送。
tcp ip詳解學習 tcp
1。tcp連線的建立與終止 建立過程 1 客戶端請求建立連線。ack 0 syn 1 sequence number isn client acknowledgement number null options mss 2 服務段確認連線。ack 1 syn 1 sequence number is...
TCP IP隨筆 TCP協議詳解
tcp協議詳解 應用層 訊息 報文包含了將要傳送的完整的資料資訊 傳輸層 資料段 報文段 segment 注 tcp叫tcp報文段，udp叫udp資料報,也有人叫udp段 網路層 分組 資料報 packet 鏈路層 幀 frame 物理層 p pdu bit 位元組流和資料報都是一種資料傳遞方式 t...
TCP IP詳解之TCP的互動資料流2
tcp的互動資料流目錄章節 1.互動式輸入 2.經受時延的確認 3.nagle演算法 4.視窗大小通告 如果按照分組數量計算，約有一半的t c p報文段包含成塊資料 如 f t p 電子郵件和 u s e n e t新聞 另一半則包含互動資料 如te l n e t和r l o g i n 如果按位...