組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：陶志榮（dick_hw  jerrytaowx@263.net）
譯文發布時間：2001-7-14
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須保留本
文檔的翻譯及版權信息。




Network Working Group                                        K. Lahey
Request for Comments: 2923                            dotRocket, Inc.
Category: Informational                                September 2000


						 TCP的路徑MTU發現問題
（TCP Problems with Path MTU Discovery）


本備忘錄的狀態

本文檔為Internet社區提供信息。它并不定義任何Internet標準。本備忘錄的發布不受任
何限制。

版權聲明

Copyright (C) The Internet Society (2000).  All Rights Reserved.

摘要

本備忘錄編制了幾個已知和路徑最大傳輸單元發現(PMTUD)相關的傳輸控制協議（TCP）實
現問題，包括長期存在的黑洞問題，由于最大段長（MSS）和段長的混淆造成的彈性確認
（ACKs）問題，以及基于PMTU的MSS通告問題。

目錄
1 介紹	2
2 已知的實現問題	2
2.1  問題名字	2
2.2 問題名字	4
2.3 問題名字	7
3 安全考慮	9
4 致謝	9
5 參考	9
6  作者地址：	10
7 完整的版權說明	10
1 介紹
本備忘錄編制了幾個已知和路徑最大傳輸單元發現(PMTUD)相關的傳輸控制協議（TCP）實
現問題，包括長期存在的黑洞問題，由于最大段長（MSS）和段長的混淆造成的彈性確認
（ACKs）問題，以及基于PMTU的MSS通告問題。這么做的目的是通過改進當前TCP/IP實現
的質量來改善目前Internet的環境。
路徑MTU發現（PMTUD）可被任何上層協議使用，但通常TCP用得最多。本文檔不打算涉及
其它上層協議遇到的問題。Ipv6的路徑MTU發現[RFC1981]只處理與Ipv6相關的情況，不
是本文檔要討論的情況。
每個問題按如下定義：
問題名字
	與問題相聯系的名字。在本備忘錄中，名字作為子小節的標題。
分類
	該問題的更多分類是：“擁塞控制”，“性能”，“可靠性”，“非互操作――連接
失敗”。
描述
	問題定義，簡潔但包括了必要的背景材料。
意義
	對幾個環境的簡單總結表明問題的意義。
含義
	為什么這個問題被當作一個問題。
相關RFC
	和該問題相抵觸的定義TCP的RFC。這些RFC通常使用術語如必須，應該，可以及其它
大寫的詞語指示該如何動作。這些術語的確切解釋見RFC2119。
闡述問題的輸出文件
	若合適的話，給出一個或多個ASCII輸出文件闡述問題
解釋什么是正確處理的輸出文件
	若合適的話，給出一個或多個ASCII輸出文件解釋正確處理的輸出
參考
	對問題進一步討論的參考材料
如何檢測
	如何對實現測試來檢查是否有這個問題。
如何修改
	對原因已明的問題，如何改正實現。
2 已知的實現問題
2.1  問題名字
	黑洞檢測
分類
	非交互操作――連接失敗
描述
	主機執行路徑MTU發現方法是發送盡可能大的包，在IP頭置上不要分片位（DF）。若
包太大無法由路由器轉發到特定路徑，路由器必須給源地址發送一個目的不可達――需要
分片的ICMP消息。主機將基于這個ICMP消息調整包大小。

	正如[RFC1435]中指出的，路由器并不總能正確處理這種事件――許多路由器未能發送
ICMP消息，或是由于核心的bug或是由于配置原因等。若實現遵守相關文檔的建議，
Ipsec[RFC2401]和IP-in-IP[RFC2003]隧道不應引起這種問題。

	如[RFC1191]中指出的，當原始主機未能收到合適的ICMP消息時PMTUD失敗。沒有
ICMP消息通知就無法發現需要減小包大小，上層協議則繼續嘗試發送大包。它發的包在
PMTUD黑洞中消失。
意義
	當由于沒有ICMP消息導致PMTUD失敗時，TCP在某些條件下也會完全失效。
含義
	因為到目的主機的ping和某些交互式TCP連接是正常的，這種故障尤其難查。大流量
傳輸在第一個大包即失敗而連接最終超時。
	這種情況幾乎總是由于網絡的應該被更正的配置錯誤造成。然而似乎在路徑上某些TCP
實現互操作失敗而未影響到其它TCP實現（也就是那些沒有PMTUD的），這是不合適的。這
使得市場不愿將TCP實現配置為PMTUD使能。
相關RFC
	RFC1191描述路徑MTU發現。RFC1435提供了早期這類問題的描述。
闡述問題的輸出文件
	用tcpdump[Jacobson89]在一個中間主機上記錄的結果：

      20:12:11.951321 A > B: S 1748427200:1748427200(0)
           win 49152 <mss 1460>
      20:12:11.951829 B > A: S 1001927984:1001927984(0)
           ack 1748427201 win 16384 <mss 65240>
      20:12:11.955230 A > B: . ack 1 win 49152 (DF)
      20:12:11.959099 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:12:13.139074 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:12:16.188685 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:12:22.290483 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:12:34.491856 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:12:58.896405 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:13:47.703184 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:14:52.780640 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:15:57.856037 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:17:02.932431 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:18:08.009337 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:19:13.090521 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:20:18.168066 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
      20:21:23.242761 A > B: R 1461:1461(0) ack 1 win 49152 (DF)

	短的SYN包因為包小通過網絡沒問題。同樣，用于診斷連通性問題的ICMP響應包也能
成功通過。
	大數據包通過網絡時失敗。最終連接超時。若應用是從少量數據的寫開始，成功，再
開始大數據量寫，失敗，這種情形尤其令人迷惑。
解釋什么是正確處理的輸出文件
	用tcpdump[Jacobson89]在一個中間主機上記錄的結果：

      16:48:42.659115 A > B: S 271394446:271394446(0)
           win 8192 <mss 1460> (DF)
      16:48:42.672279 B > A: S 2837734676:2837734676(0)
           ack 271394447 win 16384 <mss 65240>

      16:48:42.676890 A > B: . ack 1 win 8760 (DF)
      16:48:42.870574 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
      16:48:42.871799 A > B: . 1461:2921(1460) ack 1 win 8760 (DF)
      16:48:45.786814 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
      16:48:51.794676 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
      16:49:03.808912 A > B: . 1:537(536) ack 1 win 8760
      16:49:04.016476 B > A: . ack 537 win 16384
      16:49:04.021245 A > B: . 537:1073(536) ack 1 win 8760
      16:49:04.021697 A > B: . 1073:1609(536) ack 1 win 8760
      16:49:04.120694 B > A: . ack 1609 win 16384
      16:49:04.126142 A > B: . 1609:2145(536) ack 1 win 8760

	在這種情況下，發送者發現四個包發送失敗（使用兩個包的初始發送窗口），停掉了
PMTUD。所有接著發送的包的DF標志都關閉，包大小設為缺省值536[RFC1122]。
參考
	這個問題在tcp實現的郵件列表中被廣泛討論；名字“黑洞”已使用多年。
如何檢測
	這個問題表現為TCP連接掛起（無法繼續）直到超時（這常常表現為連接已建立并開
始傳輸，然后在15分鐘后最終終止而未發送任何字節）。而象ftp這樣的應用尤其令人討
厭，開始傳輸小包的控制信息時非常好，但開始大塊數據傳輸時就失敗。
	一系列的ICMP響應包表明兩端主機仍能傳送包，一系列MTU大小的ICMP響應包會發現
有分片現象，而一系列MTU大小的帶DF標志的ICMP響應包則失敗。對要診斷問題的網絡工
程師來說這令人迷惑。
	有幾個做PMTUD的traceroute的實現能解釋這個問題。
如何修改
	TCP應該會注意到連接已超時。在幾次超時后，TCP應該試圖發送小一點的包，也可以
把每個包的DF標志關閉。若這樣成功，就應繼續把這個連接的PMTUD關閉一段時間，直到
它再次檢測試圖確定路徑是否已改變。
	注意，在Ipv6中沒有DF位――它是永遠隱含設置的。在路由器中不允許分片，只在
源主機允許分片。幸運的是，Ipv6支持的最小MTU是1280字節，遠遠大于Ipv4中的最小
68字節。當Ipv4實現檢測到黑洞問題時可能要關掉DF，與之相比，Ipv6實現后退到1280
字節的包應是合理的。
	ICMP黑洞理想的處理應是在發現時處理。
	若主機開始執行黑洞檢測，有可能問題將仍然被人忽視并未得到修復。因為每次檢測
將花費幾秒時間且延遲將引起隱藏的性能相當下降，這十分糟糕。實施黑洞檢測的主機應
記錄檢測的黑洞以便能修復。


2.2 問題名字
	由于PMTUD引起的ACK延遲(stretch ACK)
分類
	擁塞控制/性能
描述
	當一個實現上未作復雜處理的TCP協議棧和一個有PMTUD功能的TCP協議棧通信時，對
每隔兩個的全尺寸包將試圖產生一個ACK。若是基于通告的MSS來決定全尺寸大小，則在面
臨PMUTD時會嚴重降低性能。
	PMTU可以減小為只是通告的MSS的一小段；在這種情況下，ACK只是會很少產生。
意義
	延遲的ACK有一系列不好的影響，更完整的列在[RFC2525]。由于ACK很少到達，多數
會產生更突發性的連接。它們能阻止擁塞窗口的增長。
含義
	延遲的ACK的完整含義列在[RFC2525]。
相關RFC
	RFC1122列出了對ACK頻繁產生的需求。[RFC2581]對此進行了擴展并且聲明延遲ACK
是應該而不是必須。
闡述問題的輸出文件
	在中間主機上使用tcpdump記錄。為簡明起見，除了頭兩個包以外，其它包的時間戳
選項都被刪除。	

   18:16:52.976657 A > B: S 3183102292:3183102292(0) win 16384
        <mss 4312,nop,wscale 0,nop,nop,timestamp 12128 0> (DF)
   18:16:52.979580 B > A: S 2022212745:2022212745(0) ack 3183102293 win
        49152 <mss 4312,nop,wscale 1,nop,nop,timestamp 1592957 12128> (DF)
   18:16:52.979738 A > B: . ack 1 win 17248  (DF)
   18:16:52.982473 A > B: . 1:4301(4300) ack 1 win 17248  (DF)
   18:16:52.982557 C > A: icmp: B unreachable -
        need to frag (mtu 1500)! (DF)
   18:16:52.985839 B > A: . ack 1 win 32768  (DF)
   18:16:54.129928 A > B: . 1:1449(1448) ack 1 win 17248  (DF)
        .
        .
        .
   18:16:58.507078 A > B: . 1463941:1465389(1448) ack 1 win 17248  (DF)
   18:16:58.507200 A > B: . 1465389:1466837(1448) ack 1 win 17248  (DF)
   18:16:58.507326 A > B: . 1466837:1468285(1448) ack 1 win 17248  (DF)
   18:16:58.507439 A > B: . 1468285:1469733(1448) ack 1 win 17248  (DF)
   18:16:58.524763 B > A: . ack 1452357 win 32768  (DF)
   18:16:58.524986 B > A: . ack 1461045 win 32768  (DF)
   18:16:58.525138 A > B: . 1469733:1471181(1448) ack 1 win 17248  (DF)
   18:16:58.525268 A > B: . 1471181:1472629(1448) ack 1 win 17248  (DF)
   18:16:58.525393 A > B: . 1472629:1474077(1448) ack 1 win 17248  (DF)
   18:16:58.525516 A > B: . 1474077:1475525(1448) ack 1 win 17248  (DF)
   18:16:58.525642 A > B: . 1475525:1476973(1448) ack 1 win 17248  (DF)
   18:16:58.525766 A > B: . 1476973:1478421(1448) ack 1 win 17248  (DF)
   18:16:58.526063 A > B: . 1478421:1479869(1448) ack 1 win 17248  (DF)
   18:16:58.526187 A > B: . 1479869:1481317(1448) ack 1 win 17248  (DF)
   18:16:58.526310 A > B: . 1481317:1482765(1448) ack 1 win 17248  (DF)
   18:16:58.526432 A > B: . 1482765:1484213(1448) ack 1 win 17248  (DF)
   18:16:58.526561 A > B: . 1484213:1485661(1448) ack 1 win 17248  (DF)
   18:16:58.526671 A > B: . 1485661:1487109(1448) ack 1 win 17248  (DF)
   18:16:58.537944 B > A: . ack 1478421 win 32768  (DF)
   18:16:58.538328 A > B: . 1487109:1488557(1448) ack 1 win 17248  (DF)
注意ACK之間的間隔比兩倍段大小還要大；它消耗了幾乎兩倍于建議的MSS的時間。傳輸時
間長得可以驗證延遲的ACK不是丟失ACK包的結果。

解釋什么是正確處理的輸出文件
在中間主機上使用tcpdump記錄。為簡明起見，除了頭兩個包以外，其它包的時間戳選項
都被刪除。

   18:13:32.287965 A > B: S 2972697496:2972697496(0)
        win 16384 <mss 4312,nop,wscale 0,nop,nop,timestamp 11326 0> (DF)
   18:13:32.290785 B > A: S 245639054:245639054(0)
        ack 2972697497 win 34496 <mss 4312> (DF)
   18:13:32.290941 A > B: . ack 1 win 17248 (DF)
   18:13:32.293774 A > B: . 1:4313(4312) ack 1 win 17248 (DF)
   18:13:32.293856 C > A: icmp: B unreachable -
        need to frag (mtu 1500)! (DF)