速讀原著-TCP/IP(ICMP的差錯)

• 2020 年 3 月 12 日
• 筆記

第21章 TCP的超時與重傳

21.10 ICMP的差錯

讓我們來看一下 T C P是怎樣處理一個給定的連接返回的 I C M P的差錯。T C P能夠遇到的最常見的I C M P差錯就是源站抑制、主機不可達和網路不可達。

當前基於伯克利的實現對這些錯誤的處理是： • 一個接收到的源站抑制引起擁塞窗口 c w n d被置為1個報文段大小來發起慢啟動，但是慢啟動門限s s t h re s h沒有變化，所以窗口將打開直至它或者開放了所有的通路（受窗口大小和往返時間的限制）或者發生了擁塞。 • 一個接收到的主機不可達或網路不可達實際上都被忽略，因為這兩個差錯都被認為是短暫現象。這有可能是由於中間路由器被關閉而導致選路協議要花費數分鐘才能穩定

到另一個替換路由。在這個過程中就可能發生這兩個 I C M P差錯中的一個，但是連接並不必被關閉。相反， T C P試圖發送引起該差錯的數據，儘管最終有可能會超時（回想圖 2 1 – 1中T C P在9分鐘內沒有放棄的情況）。當前基於伯克利的實現記錄發生的 I C M P差錯，如果連接超時， I C M P差錯被轉換為一個更合適的的差錯碼而不是「連接超時」。早期的B S D實現在任何時候收到一個主機不可達或網路不可達的I C M P差錯時會不正確的放棄連接。

一個例子 可以通過在連接中撥號 S L I P鏈路的斷開來觀察一個 I C M P主機不可達的差錯是如何被處理的。建立一個從主機 s l i p到主機a i x的連接（從扉頁前的圖中可以看到這個連接經過了我們的撥號S L I P鏈路）。在建立連接並發送一些數據之後，在路由器 s u n和n e t b之間的S L I P鏈路被斷開，這引起 s u n上的默認路由表項（見 9 . 2節）被移去。我們希望 s u n對目的為1 4 0 . 2 5 2 . 1 乙太網的I P數據報響應I C M P主機不可達。希望觀察T C P如何處理這些I C M P差錯。下面是主機s l i p的交互會話：

圖2 1 – 1 2顯示了在路由器 b s d i上截獲的t c p d u m p的相應輸出（去掉了連接建立和所有的窗口通告）。我們連接到在主機 a i x上的回顯伺服器並鍵入「 test line」（第1行），它被回顯（第2行）且回顯被確認（第3行），接著我們斷開了S L I P鏈路。

我們鍵入「another line」（第3行之後）並希望看到T C P超時和重傳報文。的確，這一行在收到應答前被發送了6次。第4 ~ 1 3行顯示了第1次傳輸和接著的4次重傳，每個都產生了一個來自路由器s u n的I C M P主機不可達。這正是我們所希望的：從 s l i p來的I P數據報發往路由器b s d i（這是一個指向s u n的默認路由器），併到達檢測到鏈路中斷的 s u n。在發生這些重傳時， S L I P鏈路又被連通，在第 1 4行的重傳被交付。第 1 5行是來自a i x的回顯，而第1 6行是對這個回顯的確認。

這表明T C P忽略I C M P主機不可達的差錯並堅持重傳。我們也可以觀察到所預期的在每一次重傳超時中的指數退避：第 1次約為2 . 5秒，接著乘2（約5秒），乘4（約1 0秒），乘8（約2 0秒），乘1 4（約4 0秒）。

接著我們鍵入輸入的第3行（「line number 3」）並看到它在第1 7行被發送，在第1 8行回顯，並在第1 9行對回顯進行確認。

現在我們希望觀察在接收到 I C M P主機不可達後， T C P重傳並放棄的情況。於是再次斷開S L I P鏈路，之後鍵入「the last line」，並觀察到在T C P放棄之前該行被發送了1 3次（我們已經從結果中刪除了第3 0 ~ 4 3行，它們是額外的重傳）。

然而，我們所觀察到的現象是 s o c k程式在最終放棄時列印出來的差錯資訊：「沒有到達主機的路由」。這與U n i x的I C M P主機不可達的差錯類似（圖 6 – 1 2）。這表明T C P保存了它在連接上收到的I C M P差錯，並在最終放棄時列印出該差錯，而不是「連接超時」。

最後，注意到第2 2 ~ 4 6行與第6 ~ 1 4行不同的重傳間隔。看起來我們鍵入的第 3行在第1 7 ~ 1 9行被發送和確認時（無任何重傳），T C P更新了它的估計器。最初的重傳超時時間現在是 3秒，後續取值為6, 12, 24, 48，直至上限6 4。