22.1簡介

我們已經知道接收者會在窗口大小中向發送者通告一個適當的數據數量，TCP通過這種方法來進行流量控制。當窗口大小變成0時將會發生什么情況？它將有效地阻止發送者向另一端傳輸數據，直到窗口大小變成非零。

我們可以在圖20.3看到這種情況。段9打開了被段8關閉的窗口，當發送者收到段9以后，它立即開始發送數據。TCP必須能夠處理打開窗口的確認（段9）丟失的情況。確認不是可靠傳輸的，也就是說，TCP不會對確認進行ACK，它只ACK包含數據的段。

 附圖20.3

如果有確認丟失，我們要結束兩端的互相等待：接收者等待接收數據（因為它提供給發送者一個非零的窗口），發送者則在等待允許它發送的窗口更新（已丟失！）。為了防止這種情況的死鎖發生，發送者使用了一個持續計時器（persiet timer）來周期性的詢問接收者是否已增加了窗口。從發送者發出的這些段稱為窗口探測（window probes）。在本章，我們研究窗口探測和持續定時器。我們同樣檢查和持續定時器相關的糊涂窗口綜合癥（silly window syndrome）。

22.2 范例

為了解工作中的持續定時器，我們將啟動一個從客戶端監聽連接請求的接收者進程，接受連接請求，并且在從網絡讀取數據之前睡眠（sleep）很長一段時間。

Sock程序的暫停選項-P可以使服務器在接受連接請求和執行第一次讀之間睡眠。我們用如下方式運轉服務器：
svr4 % sock -i -s -P100000 5555

這樣可以讓服務器在從網絡讀取數據之前睡眠100000秒（27.8個小時）。客戶端運行在主機bsdi，并向服務器的5555端口寫1024字節的數據。圖22.1顯示了tcpdump輸出（我們已經在輸出中去掉了連接的建立過程）

圖22.1持續定時器探測零大小窗口的例子

段1-13顯示了從客戶端到服務器的正常數據傳輸，用9216個字節的數據填充了窗口。服務器通告的窗口大小是4096，并有一個默認的socket緩沖區，大小也是4096。這是SVR4中TCP/IP代碼和數據流子系統（stream subsystem）之間交互的某種形式。（This is some form of interaction between the TCP/IP code and the streams subsystems in SVR4.）

在段13，服務器確認了前面4個數據段，當通告窗口大小是0，阻止了客戶端傳輸更多的數據。這將引起客戶端設置它的持續定時器。當定時器期滿時，如果客戶端未收到窗口更新，它就探測這個空窗口，看是否有窗口更新丟失了。這是因為我們的服務器正在睡眠，那9216個字節被TCP放在緩沖區里，正等待著應用程序對它們的讀取。

注意客戶端探測窗口間的時間間隔。第一個（段14）是在收到0大小窗口的4.949秒之后。下一個（段16）是4.996秒之后。往下的前后兩段的間隔大約是6，12，24，48和60秒。

為什么這些間隔總是比5，6，12，24，48和60少零點幾秒？這些探測是由TCP的500毫秒定時器期滿觸發的。當定時器期滿時，窗口探測被發出，并且在4毫秒之后收到回復。收到回復引起定時器的重新啟動，但到下一個時鐘tick的時間大約是（500-4）毫秒。（？）

使用標準的TCP指數后退（exponential backoff）來計算持續定時器Exponential 。對于一個典型的LAN，第一次超時的計算結果是1.5秒。第二次超時值是第一次的結果乘以2，即3秒。下一次乘以4，得到6，再往下乘以8，得到12……但是持續定時器總是在5到60秒之間，這就解釋了我們在圖22.1中的所見。

窗口探測包含了一個字節的數據（順序號9217）。TCP總是允許在已關閉窗口的結尾之外發送一個字節的數據。注意，盡管這樣，但返回的告知窗口大小為0的確認并不ACK這個字節。（它們只ACK9216之前（包括9216）的字節。）因此該字節可以被持續的重傳。

持續狀態的特征和21章重傳超時的不同在于TCP從不會放棄發送窗口探測。這些窗口探測以60秒的時間間隔連續發送，直到窗口打開，或者連接被關閉。

22.3 糊涂窗口綜合癥（silly window syndrome）

TCP使用的這種基于窗口的流量控制機制，可能導致進入一種叫做糊涂窗口綜合癥（SWS）的條件。當它發生時，小的數據通過連接被交換，而全長（full-sized）段卻無法傳輸 [Clark1982] 。

連接兩端都可能引起這種情況：接收者通告小的窗口（而不是等待出現較大窗口再通告），發送端發送小的數據（而不是等待其它的數據來發送一個較大的段）。可以在兩端采取正確的措施來避免糊涂窗口綜合癥的發生。

1．               接收者不可以通告小窗口。通常的算法是，接收者不通告比當前通告（可能是0）大的窗口，除非窗口可以增加一個全長段（比如正在被接收的MSS），或者增加半個接收者緩沖區空間，其它情況都要小于當前通告。（即等到窗口到一定大小后再通告。）

2．               發送者通過停止發送來避免糊涂窗口綜合癥，除非下列某個條件成立：（a）一個全長段能夠被發送，（b）至少有對方曾經通告的最大窗口一半的段能夠被發送，（c）不需要確認（即沒有未被確認的數據）或者連接上Nagel算法（19.4）已被禁止時，任何數據都可以被發送。

條件（b）用以處理總是通告小窗口（可能比段長度更小）的情況，條件（c）阻止我們在有未被確認的數據（正在等待被確認），以及Nagel算法被禁止時發送小段。如果應用程序正在寫小數據（比如比段長度更小），條件（c）可以避免糊涂窗口綜合癥。

這3個條件也需要我們回答這樣一個問題：當有未被確認的數據時，如果有Nagel算法阻止我們發送小的段，那么到底多小才算小？從條件（a）我們知道“小”意思是字節數少于段長度。條件（b）只用在較老的原始主機。

步驟2中的條件（b）需要我們跟蹤由另一端通告的最大窗口長度。這是發送者對對方接收緩沖區的大小的猜測嘗試。盡管接收者緩沖區在連接建立時可能減小，但事實上這很少

發生。

范例*

在發送主機sun使用sock程序向網絡寫6個1024字節的數據。

sun % sock -i -n6 bsdi 7777

在主機bsdi的接收進程放置一些暫停，在第一次讀之前暫停4秒，在連續兩次讀之間暫停2秒。而且接收者每次讀256字節

bsdi % sock -i -s -P4 -p2 -r256 7777

初始的暫停是為了填滿接收者的緩沖區，迫使發送者停止發送。由于接收者接著從網絡讀了少量數據，我們期望能看到接收者執行的糊涂窗口綜合癥的避免措施。

圖22.2是傳輸6144個字節數據的時間線。

圖22.2 顯示接收者避免糊涂窗口綜合癥的時間線

我們同樣需要跟蹤讀取數據的應用程序在每個時間點的變化，接收緩沖區的當前字節數，以及緩沖區可用空間的字節數。圖22.3顯示了這些變化。

圖22.3接收者避免糊涂窗口綜合癥的事件順序

圖22.3 第一列是每個動作發生的相對時間點。那些帶三位小數點的是從tcpdump輸出得到的（圖22.2）。那些小數點后為99的是接收端主機發生行為時的假想（assumed）時間。

當從發送者收到數據時，接收者的緩沖區的數據數量增加；而當應用程序從緩沖區讀取數據時，數量減少。我們需要跟蹤的是接收者發給發送者的窗口通告，從中我們可以看到接收者避免糊涂窗口綜合癥的方法。

前四個數據段和相關的ACK（段1-5）顯示發送者填滿了接收者緩沖區。發送者被迫停止，但還有數據需要發送。它設置持續定時器的最小值為5秒。

當持續定時器期滿時，一個字節的數據被發送（段6）。由于接收端應用程序已經從緩沖區讀取了256字節（在時間3.99），因此該字節被接收并確認（段7）。但通告的窗口仍是0，這是由于接收者還沒有騰出能夠容難一個全長段或半個緩沖區大小的空間。這是接收端的糊涂窗口綜合癥的避免措施。

發送者的持續定時器被重置，并在5秒之后（在時間10.151）期滿，又有一個字節發送并被確認（段8，9）。這時接收者緩沖區的可用空間是1022字節，因此仍通告0窗口。

在時間15.151，定時器期滿，段10和11被發送和接收。此時可用空間為1533字節，（大于全長段1024）因此通告一個非零窗口。發送者立即使用這個窗口，發送1024個字節（段12）。對這1024個字節的確認（段13）通告窗口大小是509字節。這似乎與我們前面看到的小窗口通告相矛盾（即為什么通知窗口大小不是0）。

這里段11通告一個1533字節的窗口，并且發送者只發送1024字節。如果段13通告的窗口大小是0，就與窗口不能通過左移右邊緣來收縮的TCP原則（20.3）相沖突。這就是為何通告509字節小窗口的原因。

接下來我們看，發送者沒有立即向小窗口發送數據。這是發送者糊涂窗口綜合癥的避免方法。相反地，它又等待了一個持續定時器時間（到時間20.151），發送了509字節數據。盡管它最終發送這509個字節的小數據，但它在發送前等待了5秒，看是否有ACK到達以使窗口打開得更大些。這509個字節使得接收者緩沖區的可用空間剩下768字節，（不到一個全長度）因此確認（段15）通告窗口大小是0。

在時間25.151，持續定時器期滿，發送者發送一個字節的數據（段16）。在段17接收者通告窗口大小1279字節。

發送者有額外511個字節需要發送（上次發送遺留下的），因此它在收到段17后立即發送這511個字節（段18）。該段也包括了一個FIN標志，段19對數據和FIN進行了確認，通告窗口為767字節。（1279-511=768，為什么通告窗口少了一個字節？被FIN消費了）

發送端應用程序在寫完第六段1024字節的數據后發出了close，它由ESTABLISHED狀態，遷移到FIN_WAIT_1狀態，再到FIN_WAIT_2狀態（圖18.12）。它保持這個狀態，直到從另一端收到FIN。FIN_WAIT_2這個狀態沒有定時器，因為她在段18中發送的FIN已經由段19確認。這就是我們在它收到對方的FIN（段21）之前看不到其他傳輸的原因。

接收端的應用程序繼續每隔兩秒地從緩沖區讀取256個字節的數據。為什么在時間39.99，段10被發送？當應用程序讀到39.99時，接收者緩沖區空間已經由上次通告的767字節（段19）上升到了2816。緩沖區增加的空間是2049空間。前面我們提到，接收者緩沖區空間增加它的一半時，需要發送一個窗口更新。從中我們可以發現，應用程序從緩沖區讀取數據時，接收端在時時地檢查是否該發送一個窗口更新。

在時間51.99，應用程序執行最后一次讀取，并收到一個文件結束標志，因為緩沖區已經為空。最后兩個段被發送，連接終止。