1、下載第20章TCP的成塊數據流20.1引言在第15章我們看到 TFTP使用了停止等待協議。數據發送方在發送下一個數據塊之前需要 等待接收對已發送數據的確認。本章我們將介紹 TCP所使用的被稱為滑動窗口協議的另一種 形式的流量控制方法。該協議允許發送方在停止?等待確認前可以連續發送多個分組。由于 發送方不必每發一個分組就停下來等待確認，因此該協議可以加速數據的傳輸。我們還將介紹 TCP的PUSH標志，該標志在前面的許多例子中都出現過。此外，我們還要 介紹慢啟動， TCP使用該技術在一個連接上建立數據流，最后介紹成塊數據流的吞吐量。20.2正常數據流我們以從主機 svr4單向傳輸 8192個字節到

2、主機 bsdi開始。在 bsdi上運行 sock?序作 為服務器：bsdi % sock -i -s 7777 其中，標志 -i和-s指示?序作為一個“吸收（ sink）”服務器運行（從網絡上讀取?丟棄 數據），服務器端口指明為 7777。相應的客戶?序運行為：svr4 % sock -i -n8 bsdi 7777 該命令指示客戶向網絡發送 8個1024字節的數據。圖 20-1顯示了這個過?的時間系列。我 們在輸出的前 3個報文段中顯示了每一端 MSS的值。發送方首先傳送 3個數據報文段（ 46）。下一個報文段（ 7）僅確認了前兩個數據報文段， 這可以從其確認序號為 2048而不是3073看

3、出來。報文段7的ACK的序號之所以是 2048而不是3073是由以下原因造成的：當一個分組到達時， 它首先被設備中斷例?進行處理，然后放置到 IP的輸入隊列中。三個報文段 4、5和6依次到達 ?按接收順序放到 IP的輸入隊列。 IP將按同樣順序將它們交給 TCP。當 TCP處理報文段 4時， 該連接被標記為產生一個經受時延的確認。 TCP處理下一報文段（ 5），由于TCP現在有兩個未 完成的報文段需要確認，因此產生一個序號為 2048的ACK（報文段 7），?清除該連接產生經 受時延的確認標志。 TCP處理下一個報文段（ 6），而連接又被標志為產生一個經受時延的確 認。在報文段9到來之前，由于

4、時延定時器溢出，因此產生一個序號為 3073的ACK（報文段 8）。 報文段 8中的窗口大小為 3072，表明在 TCP的接收緩存中還有 1024個字節的數據等待被應用? 序讀取。報文段1116說明了通常使用的“隔一個報文段確認”的策略。報文段 11、12和13到達? 被放入 IP的接收隊列。當報文段 11被處理時，連接被標記為產生一個經受時延的確認。當報 文段12被處理時，它們的 ACK（報文段 14）被產生且連接的經受時延的確認標志被清除。報 文段13使得連接再次被標記為產生經受時延。但在時延定時器溢出之前，報文段 15處理完畢， 因此該確認立刻被發送。圖20-1 從svr4 傳輸8192

5、個字節到bsdi注意到報文段 7、14和16中的ACK確認了兩個收到的報文段是很重要的。使用 TCP的滑動 窗口協議時，接收方不必確認每一個收到的分組。在 TCP中，ACK是累積的它們表示接 收方已經正確收到了一直到確認序號減 1的所有字節。在本例中，三個確認的數據為 2048字節 而兩個確認的數據為 1024字節（忽略了連接建立和終止中的確認）。用tcpdump看到的是 TCP的動態活動情況。我們在線路上看到的分組順序依賴于許多無 法控制的因素：發送方 TCP的實現、接收方 TCP的實現、接收進?讀取數據（依賴于操作系統 的調度）和網絡的動態性（如以太網的沖突和退避等）。對這兩個TCP而言，

6、沒有一種單一的、 正確的方法來交換給定數量的數據。為顯示情況可能怎樣變化，圖 20-2顯示了在同樣兩個主機之間交換同樣數據時的另一個 時間系列，它們是在圖 20-1所示的幾分鐘之后截獲的。一些情況發生了變化。這一次接收方沒有發送一個序號為 3073的ACK，而是等待?發送 序號為 4097的ACK。接收方僅發送了 4個ACK（報文段 7、10、12和15）：三個確認了 2048字節，另一個確認了 1024字節。最后 1024字節數據的 ACK出現在報文段 17中，它與 FIN的ACK一道發送（比較該圖中的報文段 17與圖20-1中的報文段 16和18）。圖20-2 從svr4 到bsdi 的另

7、外8192字節數據的傳輸過?快的發送方和慢的接收方圖20-3顯示了另外一個時間系列。這次是從一個快的發送方（一個 Sparc工作站）到一個 慢的接收方（配有慢速以太網卡的 80386機器）。它的動態活動情況又有所不同。發送方發送 4個背靠背（ back-to-back）的數據報文段去填充接收方的窗口，然后停下來 等待一個 ACK。接收方發送 ACK（報文段 8），但通告其窗口大小為 0，這說明接收方已收到 所有數據，但這些數據都在接收方的 TCP緩沖區，因為應用?序還沒有機會讀取這些數據。 另一個 ACK（稱為窗口更新）在 17.4 ms后發送，表明接收方現在可以接收另外的 4096個字節 的

8、數據。雖然這看起來像一個 ACK，但由于它?不確認任何新數據，只是用來增加窗口的右 邊沿，因此被稱為窗口更新。發送方發送最后 4個報文段（ 1013），再次填充了接收方的窗口。注意到報文段 13中包括 兩個比特標志： PUSH和FIN。隨后從接收方傳來另外兩個 ACK，它們確認了最后的 4096字節 的數據（從 4097到8192字節）和 FIN（標號為 8192）。圖20-3 從一個快發送方發送8192字節的數據到一個慢接收方20.8 滑動窗口圖20-4用可視化的方法顯示了我們在前一節觀察到的滑動窗口協議。提供的窗口 由接收方通告可用的窗口發送?被確認不能夠發送，發送，但未被確認直至窗口移動

9、 能夠發送ASAP圖20-4 TCP滑動窗口的可視化表示在這個圖中，我們將字節從 1至11進行標號。接收方通告的窗口稱為提出的窗口（ offered window），它覆蓋了從第 4字節到第 9字節的區域，表明接收方已經確認了包括第 3字節在內的 數據，且通告窗口大小為 6。回顧第 17章，我們知道窗口大小是與確認序號相對應的。發送方 計算它的可用窗口，該窗口表明多少數據可以立即被發送。當接收方確認數據后，這個滑動窗口不時地向右移動。窗口兩個邊沿的相對運動增加或 減少了窗口的大小。我們使用三個術語來描述窗口左右邊沿的運動：1) 稱窗口左邊沿向右邊沿靠近為窗口合攏。這種現象發生在數據被發送和確認

10、時。2) 當窗口右邊沿向右移動時將允許發送更多的數據，我們稱之為窗口張開。這種現象發 生在另一端的接收進?讀取已經確認的數據?釋放了 TCP的接收緩存時。3) 當右邊沿向左移動時，我們稱之為窗口收縮。 Host Requirements RFC強烈建議不要使 用這種方式。但 TCP必須能夠在某一端產生這種情況時進行處理。第 22.3節給出了這樣的一個 例子，一端希望向左移動右邊沿來收縮窗口，但沒能夠這樣做。，圖20-5表示了這三種情況。因為窗口的左邊 沿受另一端發送的確認序號的控制，因此不可能 向左邊移動。如果接收到一個指示窗口左邊沿向 左移動的 A C K ，則它被認為是一個重復 A C K

11、 ?被丟棄。合攏收縮張開窗口圖20-5 窗口邊沿的移動如果左邊沿到達右邊沿，則稱其為一個零窗口，此時發送方不能夠發送任何數據。一個例子圖20-6顯示了在圖 20-1所示的數據傳輸過?中滑動窗口協議的動態性。由第2個報文段通告的窗口在第4,5,6報文段中發送的數據被第7報文段確認由第7個報文段通告的窗口 被第8報文段確認由第8個報文段通告的窗口在第9報文段 中發送的數據被第10報文段確認由第10個報文段通告的窗口在第11,12,13報文段 中發送的數據被第14報文段確認由第14個報文段 通告的窗口在第15報文段中發送的數據 被第16報文段確認圖20-6 圖20-1的滑動窗口協議以該圖為例可以總結

12、如下幾點：1) 發送方不必發送一個全窗口大小的數據。2) 來自接收方的一個報文段確認數據?把窗口向右邊滑動。這是因為窗口的大小是相對 于確認序號的。3) 正如從報文段 7到報文段 8中變化的那樣，窗口的大小可以減小，但是窗口的右邊沿卻 不能夠向左移動。4) 接收方在發送一個 ACK前不必等待窗口被填滿。在前面我們看到許多實現每收到兩個 報文段就會發送一個 ACK。下面我們可以看到更多的滑動窗口協議動態變化的例子。20.9 窗口大小由接收方提供的窗口的大小通常可以由接收進?控制，這將影響 TCP的性能。 4.2BSD默認設置發送和接受緩沖區的大小為 2048個字節。在4.3BSD中雙方被增加為

13、4096個字節。正如我們在本書中迄今為止所看到的例子一樣，SunOS 4.1.3 、BSD/386和SVR4仍然使用4096字節的默認大小。其他的系統，如Solaris 2.2、4.4BSD和 AIX3.2則使用更大的默認緩存大小，如8192或16384等。插口API允許進程設置發送和接收緩存的大小。接收緩存的大小是該連接上所能夠通告的最大窗口大小。有一些應用程序通過修改插口緩存大小來增加性能。Mogul 1993顯示了在改變發送和接收緩存大小（在單向數據流的應用中，如文件傳輸， 只需改變發送方的發送緩存和接收方的接收緩存大小）的情況下，位于以太網上的兩個工作 站之間進行文件傳輸時的一些結果。

14、它表明對以太網而言，默認的 4096字節?不是最理想的 大小，將兩個緩存增加到 16384 個字節可以增加約 40%左右的吞吐量。在 Papadopoulos和 Parulkar 1993中也有相似的結果。在20.7節中，我們將看到在給定通信媒體帶寬和兩端往返時間的情況下，如何計算最小的 緩存大小。一個例子可以使用 sock?序來控制這些緩存的大小。我們以如下方式調用服務器?序：bsdi % sock -i -s -R6144 5555 該命令設置接收緩存為 6144個字節（ -R選項）。接著我們在主機 sun上啟動客戶?序?使 之發送8192個字節的數據：sun % sock -i -n1

15、-w8192 bsdi 5555 圖20-7顯示了結果。首先注意到的是在報文段 2中提供的窗口大小為 6144字節。由于這是一個較大的窗口，因 此客戶立即連續發送了 6個報文段（ 49），然后停止。報文段 10確認了所有的數據（從第 1到 6144字節），但提供的窗口大小卻為 2048，這很可能是接收?序沒有機會讀取多于 2048字節的 數據。報文段 11和12完成了客戶的數據傳輸，且最后一個報文段帶有 FIN標志。報文段 13包含與報文段 10相同的確認序號，但通告了一個更大的窗口大小。報文段 14確 認了最后的 2048字節的數據和 FIN，報文段 15和16僅用于通告一個更大的窗口大小。

16、報文段17和18完成通常的關閉過?。圖20-7 接收方提供一個6144字節的接收窗口的情況下的數據傳輸20.10 PUSH標志在每一個 TCP例子中，我們都看到了 PUSH標志，但一直沒有介紹它的用途。發送方使用 該標志通知接收方將所收到的數據全部提交給接收進?。這里的數據包括與 PUSH一起傳送的 數據以及接收方 TCP已經為接收進?收到的其他數據。在最初的 TCP規范中，一般假定編?接口允許發送進?告訴它的 TCP何時設置 PUSH標志。 例如，在一個交互?序中，當客戶發送一個命令給服務器時，它設置 PUSH標志?停下來等待 服務器的響應（在習題 19.1中我們假定當發送 12字節的請求時

17、客戶設置 PUSH標志）。通過允 許客戶應用?序通知其 TCP設置PUSH標志，客戶進?通知 TCP在向服務器發送一個報文段時 不要因等待額外數據而使已提交數據在緩存中滯留。類似地，當服務器的 TCP接收到一個設 置了PUSH標志的報文段時，它需要立即將這些數據遞交給服務器進?而不能等待判斷是否還 會有額外的數據到達。然而，目前大多數的 API沒有向應用?序提供通知其 TCP設置 PUSH標志的方法。的確， 許多實現?序認為 PUSH標志已經過時，一個好的 TCP實現能夠自行決定何時設置這個標志。如果待發送數據將清空發送緩存，則大多數的源于伯克利的實現能夠自動設置 PUSH標志。 這意味著我們

18、能夠觀察到每個應用?序寫的數據均被設置了 PUSH標志，因為數據在寫的時候就立即被發送。代碼中的注釋表明該算法對那些只有在緩存被填滿或收到一個 PUSH標志時才向應 用程序提交數據的TCP實現有效。使用插口 API通知 TCP設置正在接收數據的 PUSH標志或得到該數據是否被設置 PUSH標志的信息是不可能的。由于源于伯克利的實現一般從不將接收到的數據推遲交付給應用?序，因此它們忽略所 接收的PUSH標志。舉例在圖20-1中我們觀察到所有 8個數據報文段（ 46、9、1113和15）的PUSH標志均被置 1， 這是因為客戶進行了 8次1024字節數據的寫操作，?且每次寫操作均清空了發送緩存。再

19、次觀察圖 20-7，我們預計報文段 12中的 PUSH標志被置 1，因為它是最后一個報文段。 為什?發送方知道有更多的數據需要發送還設置報文段 7中的PUSH標志呢？這是因為雖然我 們指定寫的是 8192個字節的數據，但發送方的發送緩存卻是 4096個字節。值得注意的另外一點是在圖 20-7中的第 14、15和16這三個連續的確認報文段。在圖 20-3 中我們也觀察到了兩個連續的 ACK，但那是因為接收方已經通告其窗口為 0（使發送方停止）。 當窗口張開時，需要發送另一個窗口非 0的ACK來使發送方重新啟動。可是，在圖 20-7中，窗 口的大小從來沒有達到過 0。然而，當窗口大小增加了 204

20、8個字節的時候，另一個 ACK(報文 段15和16)被發送以通知對方窗口被更新（在報文段 15和16中，這兩個窗口更新是不需要的， 因為已經收到了對方的 FIN，表明它不會再發送任何數據）。許多 TCP實現在窗口大小增加了 兩個最大報文段長度（本例中為 2048字節，因為 MSS為1024字節）或者最大可能窗口的 50%（本例中為 2048字節，因為最大窗口大小為 4096字節）時發送這個窗口更新。在第 22.3節詳細 考察糊?窗口綜合癥的時候，我們還會看到這種現象。作為PUSH標志的另一個例子，再次回到圖 20-3。我們之所以看到前 4個報文段（ 47）的 標志被設置，是因為它們每一個均使

21、TCP產生了一個報文段?提交給 IP層。但是隨后， TCP停 下來等待一個確認來移動 4096字節的窗口。在此期間， TCP又得到了應用?序的最后 4096個 字節的數據。當窗口張開時（報文段 9），發送方 TCP知道它有 4個可立即發送的報文段，因此 它只設置了最后一個報文段（ 13）的PUSH標志。20.11 慢啟動迄今為止，在本章所有的例子中，發送方一開始便向網絡發送多個報文段，直至達到接 收方通告的窗口大小為止。當發送方和接收方處于同一個局域網時，這種方式是可以的。但 是如果在發送方和接收方之間存在多個路由器和速率較慢的鏈路時，就有可能出現一些問題。 一些中間路由器必須緩存分組，?有可

22、能耗盡存儲器的空間。 Jacobson 1988 證明了這種連 接方式是如何嚴重降低了 TCP連接的吞吐量的。現在，TCP需要支持一種被稱為“慢啟動 (slow start)”的算法。該算法通過觀察到新分組 進入網絡的速率應該與另一端返回確認的速率相同而進行工作。慢啟動為發送方的 TCP增加了另一個窗口：擁塞窗口 (congestion window)，記為cwnd。當與另一個網絡的主機建立 TCP連接時，擁塞窗口被初始化為 1個報文段（即另一端通告的報文 段大小）。每收到一個 ACK，擁塞窗口就增加一個報文段（ cwnd以字節為單位，但是慢啟動 以報文段大小為單位進行增加）。發送方取擁塞窗口

23、與通告窗口中的最小值作為發送上限。擁 塞窗口是發送方使用的流量控制，而通告窗口則是接收方使用的流量控制。發送方開始時發送一個報文段，然后等待 ACK。當收到該 ACK時，擁塞窗口從 1增加為2， 即可以發送兩個報文段。當收到這兩個報文段的 ACK時，擁塞窗口就增加為 4。這是一種指數 增加的關系。在某些點上可能達到了互聯網的容量，于是中間路由器開始丟棄分組。這就通知發送方 它的擁塞窗口開得過大。當我們在下一章討論 TCP的超時和重傳機制時，將會看到它們是怎 樣對擁塞窗口起作用的。現在，我們來觀察一個實際中的慢啟動。一個例子圖20-8表示的是將從主機sun發送到主機vangogh.cs.berk

24、的數據。這些數據 將通過一個慢的SLIP鏈路，該鏈路是TCP連接上的瓶頸（我們已經在時間系列上去掉了連接建立 的過?）。圖20-8 慢啟動的例子我們觀察到發送方發送一個長度為 512字節的報文段，然后等待 ACK。該ACK在716 ms后 收到。這個時間是一個往返時間的指示。于是擁塞窗口增加了 2個報文段，且又發送了兩個報 文段。當收到報文段 5的ACK后，擁塞窗口增加為 3。此時盡管可發送多達 3個報文段，可是在 下一個ACK收到之前，只發送了 2個報文段。在21.6節中我們將再次討論慢啟動，?介紹怎樣采用另一種被稱為“擁塞避免”的技術來作為通常的實現。20.7成塊數據的吞吐

25、量讓我們看一看窗口大小、窗口流量控制以及慢啟動對傳輸成塊數據的 TCP連接的吞吐量 的相互作用。圖20-9顯示了左邊的發送方和右邊的接收方之間的一個 TCP連接上的時間系列，共顯示了 16個時間單元。為簡單起見，本圖只顯示離散的時間單元。每個粗箭頭線的上半部分顯示的 是從左到右的攜帶數據的報文段，標記為 1, 2, 3, 等等。在粗線箭頭下面表示的是反向傳輸的 ACK。我們把 ACK用細箭頭線表示，?標注了被確認的報文段號。發送方發送方發送方接收方接收方接收方接收方 接收方接收方發送方發送方圖20-9 時間015的成塊數據吞吐量舉例在時間 0，發送方發送了一個報文段。由于發送方處于慢啟動中（其

26、擁塞窗口為 1個報文 段），因此在繼續發送以前它必須等待該數據段的確認。在時間1, 2和3，報文段從左向右移動一個時間單元。在時間 4接收方讀取這個報文段?產 生確認。經過時間 5、6和7，ACK移動到左邊的發送方。我們有了一個 8個時間單元的往返時 間RTT（Round-Trip T ime）。我們有意把 ACK報文段畫得比數據報文段小，這是因為它通常只有一個 IP 首部和一個 TCP首部。這里顯示僅僅是一個單向的數據流動，?且假定 ACK的移動速率與數據報文段的 移動速率相等。實際上?不總是這樣。通常發送一個分組的時間取決于兩個因素：傳播時延（由光的有限速率、傳輸設 備的等待時間等引起）和

27、一個取決于媒體速率（即媒體每秒可傳輸的比特數）的發送 時延。對于一個給定的兩個接點之間的通路，傳播時延一般是固定的，而發送時延則 取決于分組的大小。在速率較慢的情況下發送時延起主要作用（例如，在習題 7.2中我 們甚至沒有考慮傳播時延），而在千兆比特速率下傳播時延則占主要地位（見圖24-6）。當發送方收到ACK后，在時間8和9發送兩個報文段（我們標記為2和3）。此時它的擁塞窗口 為2個報文段。這兩個報文段向右傳送到接收方，在時間12和13接收方產生兩個ACK。這兩個返 回到發送方的 ACK之間的間隔與報文段之間的間隔一致，被稱為 TCP的自計時(self-clocking)行 為。由于接收方只

28、有在數據到達時才產生 ACK，因此發送方接收到的ACK之間的間隔與數據到 達接收方的間隔是一致的（然而在實際中，返回路徑上的排隊會改變ACK的到達率）。圖20-10表示的是后面 16個時間單位。 2個ACK的到達使得擁塞窗口從 2個報文段增加為 4 個，而這 4個報文段在時間 1619時被發送。第 1個ACK在時間 23到達。 4個ACK的到達使得擁 塞窗口從 4個報文段增加為 8個，?在時間 2431發送8個報文段。發送方 發送方發送方 發送方發送方發送方 發送方發送方發送方 發送方發送方接收方發送方接收方接收方 接收方發送方接收方 接收方接收方 接收方發送方接收方 接收方接收方 接收方發送

29、方接收方 接收方發送方接收方發送方接收方發送方接收方圖20-10 時間1631的成塊數據吞吐量舉例在時間 31及其后續時間，發送方和接收方之間的管道 (pipe)被填滿。此時不論擁塞窗口和 通告窗口是多少，它都不能再容納更多的數據。每當接收方在某一個時間單位從網絡上移去 一個報文段，發送方就再發送一個報文段到網絡上。但是不管有多少報文段填充了這個管道， 返回路徑上總是具有相同數目的 ACK。這就是連接的理想穩定狀態。20.7.1 帶寬時延乘積現在來回答窗口應該設置為多大的問題。在我們的例子中，作為最大的吞吐量，發送方 在任何時候有 8個已發送的報文段未被確認。接收方的通告窗口必須不小于這個數目

30、，因為通 告窗口限制了發送方能夠發送的段的數目。可以計算通道的容量為：capacity (bit) = bandwidth (b/s) × round-trip time (s) 一般稱之為帶寬時延乘積。這個值依賴于網絡速度和兩端的 RTT，可以有很大的變動。例如， 一條穿越美國（ RTT約為60 ms）的T1的電話線路（1 544 000 b/s）的帶寬時延乘積為 11 580字 節。對于 20.4節中討論的緩存大小而言，這個結果是合理的。但是一條穿越美國的 T3電話線路（45 000 000 b/s）的帶寬時延乘積則為 337 500字節，這個數值超過了最大所允許的 TCP通告窗

31、 口的大小（65535字節）。在24.4節我們將討論能夠避免當前 TCP限制的新的TCP窗口大小選項。T1電話線的1 544 000 b/s是原始比特率。由于每193個bit使用1個作為幀同步，因此實際數據率為1 536 000 b/s。一個T3電話線的原始比特率實際上是44 736 000 b/s，其數據率可達到44 210 000 b/s。在討論中我們使用1.544 Mb/s和45 Mb/s。不論是帶寬還是時延均會影響發送方和接收方之間通路的容量。在圖 20-11中我們顯示了 一個增加了一倍的 RTT會使通路容量也增加一倍。在圖20-11底下的說明部分，通過使用一個較長的 RTT，這個管道

32、能夠容納 8個報文段而不 是4個。類似地，圖 20-12表示了增加一倍的帶寬也可使該管道的容量增加一倍。倍增的RTT圖20-11 RTT加倍可使管道容量增加一倍圖20-12 帶寬加倍可使管道容量增加一倍在圖20-12的下部，假定網絡速率已經加倍，使得我們能夠只使用上面一半的時間來發送 4個報文段。這樣，該管道的容量再次加倍（假定該圖的上半部分與下半部分中的報文段具有 同樣大小，即具有相同的比特數）。20.7.2 擁塞當數據到達一個大的管道（如一個快速局域網）?向一個較小的管道（如一個較慢的廣域網）發送時便會發生擁塞。當多個輸入流到達一個路由器，而路由器的輸出流小于這些輸 入流的總和時也會發生擁

33、塞。圖20-13顯示了一個典型的大管道向小管道發送報文的情況。之所以說它典型，是因為大 多數的主機都連接在局域網上，?通過一個路由器與速率相對較低的廣域網相連（我們再次 假定圖中上半部分的報文段（ 920）都是相同的，而圖中下半部分的 ACK也都是相同的）。發送方發送方瓶頸 路由器 R1路由器R3路由 器R2路由器R4接收方接收方圖20-13 從較大管道向較小管道發送分組引起的擁塞在該圖中，我們已經標記路由器 R1為“瓶頸”，因為它是擁塞發生的地方。它從左側速 率較高的局域網接收數據?向右側速率較低的廣域網發送（通常R1與R3是同樣的路由器， 如同 R2與R4一樣。但這?不是必需的，有時也會使

34、用不對稱的路徑）。當路由器 R2將所接收 到的分組發送到右側的局域網時，這些分組之間維持與其左側廣域網上同樣的間隔，盡管局 域網具有更高的帶寬。類似地，返回的確認之間的間隔也與其在路徑中最慢的鏈路上的間隔 一致。在圖 20-13中已經假定發送方不使用慢啟動，它按照局域網的帶寬盡可能快地發送編號 為120的報文段（假定接收方的通告窗口至少為 20個報文段）。正如我們看到的那樣， ACK 之間的間隔與在最慢鏈路上的一致。假定瓶頸路由器具有足夠的容納這20個分組的緩存。 如果這個不能保證，就會引起路由器丟棄分組。在 21.6節討論避免擁塞時會看到怎樣避免這 種情況。20.3 緊急方式TCP提供了“緊

35、急方式 (urgent mode) ”，它使一端可以告訴另一端有些具有某種方式的 “緊急數據”已經放置在普通的數據流中。另一端被通知這個緊急數據已被放置在普通數據流 中，由接收方決定如何處理。可以通過設置 TCP首部（圖 17-2）中的兩個字段來發出這種從一端到另一端的緊急數據 已經被放置在數據流中的通知。 URG比特被置 1，?且一個 16bit的緊急指針被置為一個正的 偏移量，該偏移量必須與 TCP首部中的序號字段相加，以便得出緊急數據的最后一個字節的 序號。仍有許多關于緊急指針是指向緊急數據的最后一個字節還是指向緊急數據最后一 個字節的下一個字節的爭論。最初的 TCP規范給出了兩種解釋，

36、但 Host Requirements RFC確定指向最后一個字節是正確的。然而，問題在于大多數的實現（包括源自伯克利的實現）繼續使用錯誤的解釋。所有符合Host Requirements RFC的實現都是可兼容的，但很有可能無法與其他大多數 主機正確通信。TCP必須通知接收進?，何時已接收到一個緊急數據指針以及何時某個緊急數據指針還不 在此連接上，或者緊急指針是否在數據流中向前移動。接著接收進?可以讀取數據流，?必 須能夠被告知何時碰到了緊急數據指針。只要從接收方當前讀取位置到緊急數據指針之間有 數據存在，就認為應用?序處于“緊急方式”。在緊急指針通過之后，應用?序便轉回到正常 方式。TCP

37、本身對緊急數據知之甚少。沒有辦法指明緊急數據從數據流的何處開始。 TCP通過連 接傳送的唯一信息就是緊急方式已經開始（ TCP首部中的 URG比特）和指向緊急數據最后一 個字節的指針。其他的事情留給應用?序去處理。不幸的是，許多實現不正確地稱 TCP的緊急方式為帶外數據 (out-of-band data)。如果一個 應用?序確實需要一個獨立的帶外信道，第二個 TCP連接是達到這個目的的最簡單的方法（許多運輸層確實提供許多人認為的那種真正的帶外數據：使用同一個連接的獨立的邏輯數據 通道作為正常的數據通道。這是 TCP所沒有提供的）。TCP的緊急方式與帶外數據之間的混淆，也是因為主要的編程接口（

38、插口 API）將 TCP的緊急方式映射為稱為帶外數據的插口。緊急方式有什?作用呢？兩個最常見的例子是 Telnet和Rlogin。當交互用戶鍵入中斷鍵時， 我們在第 26章將看到使用緊急方式來完成這個?能的例子。另一個例子是 FTP，當交互用戶 放棄一個文件的傳輸時，我們將在第 27章看到這樣的一個例子。Telnet和Rlogin從服務器到客戶使用緊急方式是因為在這個方向上的數據流很可能要被客戶 的TCP停止（也即，它通告了一個大小為 0的窗口）。但是如果服務器進?進入了緊急方式，盡 管它不能夠發送任何數據，服務器 TCP也會立即發送緊急指針和 URG標志。當客戶 TCP接收到 這個通知時就會

39、通知客戶進?，于是客戶可以從服務器讀取其輸入、打開窗口?使數據流動。如果在接收方處理第一個緊急指針之前，發送方多次進入緊急方式會發生什?情況呢？ 在數據流中的緊急指針會向前移動，而其在接收方的前一個位置將丟失。接收方只有一個緊 急指針，每當對方有新的值到達時它將被覆蓋。這意味著如果發送方進入緊急方式時所寫的 內容對接收方非常重要，那?這些字節數據必須被發送方用某種方式特別標記。我們將看到 Telnet通過在數據流中加入一個值為 255的字節作為前綴來標記它所有的命令。一個例子讓我們觀察一下即使是在接收方窗口關閉的情況下， TCP是如何發送緊急數據的。在主 機bsdi上啟動 sock?序，?使之在連接建立后和從網絡讀取前暫停 10秒種（通過使用 -P選 項），這將