rfc2923.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：陶志荣（dick_hw  [e-mail]）
译文发布时间：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)