22.1簡介
我們已經(jīng)知道接收者會在窗口大小中向發(fā)送者通告一個適當?shù)臄?shù)據(jù)數(shù)量，TCP通過這種方法來進行流量控制。當窗口大小變成0時將會發(fā)生什么情況？它將有效地阻止發(fā)送者向另一端傳輸數(shù)據(jù)，直到窗口大小變成非零。
我們可以在圖20.3看到這種情況。段9打開了被段8關閉的窗口，當發(fā)送者收到段9以后，它立即開始發(fā)送數(shù)據(jù)。TCP必須能夠處理打開窗口的確認（段9）丟失的情況。確認不是可靠傳輸?shù)模簿褪钦f，TCP不會對確認進行ACK，它只ACK包含數(shù)據(jù)的段。
附圖20.3
如果有確認丟失，我們要結束兩端的互相等待：接收者等待接收數(shù)據(jù)（因為它提供給發(fā)送者一個非零的窗口），發(fā)送者則在等待允許它發(fā)送的窗口更新（已丟失！）。為了防止這種情況的死鎖發(fā)生，發(fā)送者使用了一個持續(xù)計時器（persiet timer）來周期性的詢問接收者是否已增加了窗口。從發(fā)送者發(fā)出的這些段稱為窗口探測（window probes）。在本章，我們研究窗口探測和持續(xù)定時器。我們同樣檢查和持續(xù)定時器相關的糊涂窗口綜合癥（silly window syndrome）。
22.2 范例
為了解工作中的持續(xù)定時器，我們將啟動一個從客戶端監(jiān)聽連接請求的接收者進程，接受連接請求，并且在從網(wǎng)絡讀取數(shù)據(jù)之前睡眠（sleep）很長一段時間。
Sock程序的暫停選項-P可以使服務器在接受連接請求和執(zhí)行第一次讀之間睡眠。我們用如下方式運轉服務器：
svr4 % sock -i -s -P100000 5555
這樣可以讓服務器在從網(wǎng)絡讀取數(shù)據(jù)之前睡眠100000秒（27.8個小時）。客戶端運行在主機bsdi，并向服務器的5555端口寫1024字節(jié)的數(shù)據(jù)。圖22.1顯示了tcpdump輸出（我們已經(jīng)在輸出中去掉了連接的建立過程）
圖22.1持續(xù)定時器探測零大小窗口的例子
段1-13顯示了從客戶端到服務器的正常數(shù)據(jù)傳輸，用9216個字節(jié)的數(shù)據(jù)填充了窗口。服務器通告的窗口大小是4096，并有一個默認的socket緩沖區(qū)，大小也是4096。這是SVR4中TCP/IP代碼和數(shù)據(jù)流子系統(tǒng)（stream subsystem）之間交互的某種形式。（This is some form of interaction between the TCP/IP code and the streams subsystems in SVR4.）
在段13，服務器確認了前面4個數(shù)據(jù)段，當通告窗口大小是0，阻止了客戶端傳輸更多的數(shù)據(jù)。這將引起客戶端設置它的持續(xù)定時器。當定時器期滿時，如果客戶端未收到窗口更新，它就探測這個空窗口，看是否有窗口更新丟失了。這是因為我們的服務器正在睡眠，那9216個字節(jié)被TCP放在緩沖區(qū)里，正等待著應用程序對它們的讀取。
注意客戶端探測窗口間的時間間隔。第一個（段14）是在收到0大小窗口的4.949秒之后。下一個（段16）是4.996秒之后。往下的前后兩段的間隔大約是6，12，24，48和60秒。
為什么這些間隔總是比5，6，12，24，48和60少零點幾秒？這些探測是由TCP的500毫秒定時器期滿觸發(fā)的。當定時器期滿時，窗口探測被發(fā)出，并且在4毫秒之后收到回復。收到回復引起定時器的重新啟動，但到下一個時鐘tick的時間大約是（500-4）毫秒。（？）
使用標準的TCP指數(shù)后退（exponential backoff）來計算持續(xù)定時器Exponential 。對于一個典型的LAN，第一次超時的計算結果是1.5秒。第二次超時值是第一次的結果乘以2，即3秒。下一次乘以4，得到6，再往下乘以8，得到12……但是持續(xù)定時器總是在5到60秒之間，這就解釋了我們在圖22.1中的所見。
窗口探測包含了一個字節(jié)的數(shù)據(jù)（順序號9217）。TCP總是允許在已關閉窗口的結尾之外發(fā)送一個字節(jié)的數(shù)據(jù)。注意，盡管這樣，但返回的告知窗口大小為0的確認并不ACK這個字節(jié)。（它們只ACK9216之前（包括9216）的字節(jié)。）因此該字節(jié)可以被持續(xù)的重傳。
持續(xù)狀態(tài)的特征和21章重傳超時的不同在于TCP從不會放棄發(fā)送窗口探測。這些窗口探測以60秒的時間間隔連續(xù)發(fā)送，直到窗口打開，或者連接被關閉。
22.3 糊涂窗口綜合癥（silly window syndrome）
TCP使用的這種基于窗口的流量控制機制，可能導致進入一種叫做糊涂窗口綜合癥（SWS）的條件。當它發(fā)生時，小的數(shù)據(jù)通過連接被交換，而全長（full-sized）段卻無法傳輸 [Clark1982] 。
連接兩端都可能引起這種情況：接收者通告小的窗口（而不是等待出現(xiàn)較大窗口再通告），發(fā)送端發(fā)送小的數(shù)據(jù)（而不是等待其它的數(shù)據(jù)來發(fā)送一個較大的段）。可以在兩端采取正確的措施來避免糊涂窗口綜合癥的發(fā)生。
1． 接收者不可以通告小窗口。通常的算法是，接收者不通告比當前通告（可能是0）大的窗口，除非窗口可以增加一個全長段（比如正在被接收的MSS），或者增加半個接收者緩沖區(qū)空間，其它情況都要小于當前通告。（即等到窗口到一定大小后再通告。）
2． 發(fā)送者通過停止發(fā)送來避免糊涂窗口綜合癥，除非下列某個條件成立：（a）一個全長段能夠被發(fā)送，（b）至少有對方曾經(jīng)通告的最大窗口一半的段能夠被發(fā)送，（c）不需要確認（即沒有未被確認的數(shù)據(jù)）或者連接上Nagel算法（19.4）已被禁止時，任何數(shù)據(jù)都可以被發(fā)送。
條件（b）用以處理總是通告小窗口（可能比段長度更小）的情況，條件（c）阻止我們在有未被確認的數(shù)據(jù)（正在等待被確認），以及Nagel算法被禁止時發(fā)送小段。如果應用程序正在寫小數(shù)據(jù)（比如比段長度更小），條件（c）可以避免糊涂窗口綜合癥。
這3個條件也需要我們回答這樣一個問題：當有未被確認的數(shù)據(jù)時，如果有Nagel算法阻止我們發(fā)送小的段，那么到底多小才算小？從條件（a）我們知道“小”意思是字節(jié)數(shù)少于段長度。條件（b）只用在較老的原始主機。
步驟2中的條件（b）需要我們跟蹤由另一端通告的最大窗口長度。這是發(fā)送者對對方接收緩沖區(qū)的大小的猜測嘗試。盡管接收者緩沖區(qū)在連接建立時可能減小，但事實上這很少
發(fā)生。
范例*
在發(fā)送主機sun使用sock程序向網(wǎng)絡寫6個1024字節(jié)的數(shù)據(jù)。
sun % sock -i -n6 bsdi 7777
在主機bsdi的接收進程放置一些暫停，在第一次讀之前暫停4秒，在連續(xù)兩次讀之間暫停2秒。而且接收者每次讀256字節(jié)
bsdi % sock -i -s -P4 -p2 -r256 7777
初始的暫停是為了填滿接收者的緩沖區(qū)，迫使發(fā)送者停止發(fā)送。由于接收者接著從網(wǎng)絡讀了少量數(shù)據(jù)，我們期望能看到接收者執(zhí)行的糊涂窗口綜合癥的避免措施。
圖22.2是傳輸6144個字節(jié)數(shù)據(jù)的時間線。
圖22.2 顯示接收者避免糊涂窗口綜合癥的時間線
我們同樣需要跟蹤讀取數(shù)據(jù)的應用程序在每個時間點的變化，接收緩沖區(qū)的當前字節(jié)數(shù)，以及緩沖區(qū)可用空間的字節(jié)數(shù)。圖22.3顯示了這些變化。
圖22.3接收者避免糊涂窗口綜合癥的事件順序
圖22.3 第一列是每個動作發(fā)生的相對時間點。那些帶三位小數(shù)點的是從tcpdump輸出得到的（圖22.2）。那些小數(shù)點后為99的是接收端主機發(fā)生行為時的假想（assumed）時間。
當從發(fā)送者收到數(shù)據(jù)時，接收者的緩沖區(qū)的數(shù)據(jù)數(shù)量增加；而當應用程序從緩沖區(qū)讀取數(shù)據(jù)時，數(shù)量減少。我們需要跟蹤的是接收者發(fā)給發(fā)送者的窗口通告，從中我們可以看到接收者避免糊涂窗口綜合癥的方法。
前四個數(shù)據(jù)段和相關的ACK（段1-5）顯示發(fā)送者填滿了接收者緩沖區(qū)。發(fā)送者被迫停止，但還有數(shù)據(jù)需要發(fā)送。它設置持續(xù)定時器的最小值為5秒。
當持續(xù)定時器期滿時，一個字節(jié)的數(shù)據(jù)被發(fā)送（段6）。由于接收端應用程序已經(jīng)從緩沖區(qū)讀取了256字節(jié)（在時間3.99），因此該字節(jié)被接收并確認（段7）。但通告的窗口仍是0，這是由于接收者還沒有騰出能夠容難一個全長段或半個緩沖區(qū)大小的空間。這是接收端的糊涂窗口綜合癥的避免措施。
發(fā)送者的持續(xù)定時器被重置，并在5秒之后（在時間10.151）期滿，又有一個字節(jié)發(fā)送并被確認（段8，9）。這時接收者緩沖區(qū)的可用空間是1022字節(jié)，因此仍通告0窗口。
在時間15.151，定時器期滿，段10和11被發(fā)送和接收。此時可用空間為1533字節(jié)，（大于全長段1024）因此通告一個非零窗口。發(fā)送者立即使用這個窗口，發(fā)送1024個字節(jié)（段12）。對這1024個字節(jié)的確認（段13）通告窗口大小是509字節(jié)。這似乎與我們前面看到的小窗口通告相矛盾（即為什么通知窗口大小不是0）。
這里段11通告一個1533字節(jié)的窗口，并且發(fā)送者只發(fā)送1024字節(jié)。如果段13通告的窗口大小是0，就與窗口不能通過左移右邊緣來收縮的TCP原則（20.3）相沖突。這就是為何通告509字節(jié)小窗口的原因。
接下來我們看，發(fā)送者沒有立即向小窗口發(fā)送數(shù)據(jù)。這是發(fā)送者糊涂窗口綜合癥的避免方法。相反地，它又等待了一個持續(xù)定時器時間（到時間20.151），發(fā)送了509字節(jié)數(shù)據(jù)。盡管它最終發(fā)送這509個字節(jié)的小數(shù)據(jù)，但它在發(fā)送前等待了5秒，看是否有ACK到達以使窗口打開得更大些。這509個字節(jié)使得接收者緩沖區(qū)的可用空間剩下768字節(jié)，（不到一個全長度）因此確認（段15）通告窗口大小是0。
在時間25.151，持續(xù)定時器期滿，發(fā)送者發(fā)送一個字節(jié)的數(shù)據(jù)（段16）。在段17接收者通告窗口大小1279字節(jié)。
發(fā)送者有額外511個字節(jié)需要發(fā)送（上次發(fā)送遺留下的），因此它在收到段17后立即發(fā)送這511個字節(jié)（段18）。該段也包括了一個FIN標志，段19對數(shù)據(jù)和FIN進行了確認，通告窗口為767字節(jié)。（1279-511=768，為什么通告窗口少了一個字節(jié)？被FIN消費了）
發(fā)送端應用程序在寫完第六段1024字節(jié)的數(shù)據(jù)后發(fā)出了close，它由ESTABLISHED狀態(tài)，遷移到FIN_WAIT_1狀態(tài)，再到FIN_WAIT_2狀態(tài)（圖18.12）。它保持這個狀態(tài)，直到從另一端收到FIN。FIN_WAIT_2這個狀態(tài)沒有定時器，因為她在段18中發(fā)送的FIN已經(jīng)由段19確認。這就是我們在它收到對方的FIN（段21）之前看不到其他傳輸?shù)脑颉?/span>
接收端的應用程序繼續(xù)每隔兩秒地從緩沖區(qū)讀取256個字節(jié)的數(shù)據(jù)。為什么在時間39.99，段10被發(fā)送？當應用程序讀到39.99時，接收者緩沖區(qū)空間已經(jīng)由上次通告的767字節(jié)（段19）上升到了2816。緩沖區(qū)增加的空間是2049空間。前面我們提到，接收者緩沖區(qū)空間增加它的一半時，需要發(fā)送一個窗口更新。從中我們可以發(fā)現(xiàn)，應用程序從緩沖區(qū)讀取數(shù)據(jù)時，接收端在時時地檢查是否該發(fā)送一個窗口更新。
在時間51.99，應用程序執(zhí)行最后一次讀取，并收到一個文件結束標志，因為緩沖區(qū)已經(jīng)為空。最后兩個段被發(fā)送，連接終止。