rfc2923.txt

很多RFC的中文文档

   18:13:33.637338 A > B: . 1:1461(1460) ack 1 win 17248 (DF)
        .
        .
        .
   18:13:35.561691 A > B: . 1514021:1515481(1460) ack 1 win 17248 (DF)
   18:13:35.561814 A > B: . 1515481:1516941(1460) ack 1 win 17248 (DF)
   18:13:35.561938 A > B: . 1516941:1518401(1460) ack 1 win 17248 (DF)
   18:13:35.562059 A > B: . 1518401:1519861(1460) ack 1 win 17248 (DF)
   18:13:35.562174 A > B: . 1519861:1521321(1460) ack 1 win 17248 (DF)
   18:13:35.564008 B > A: . ack 1481901 win 64680 (DF)
   18:13:35.564383 A > B: . 1521321:1522781(1460) ack 1 win 17248 (DF)
   18:13:35.564499 A > B: . 1522781:1524241(1460) ack 1 win 17248 (DF)
   18:13:35.615576 B > A: . ack 1484821 win 64680 (DF)
   18:13:35.615646 B > A: . ack 1487741 win 64680 (DF)
   18:13:35.615716 B > A: . ack 1490661 win 64680 (DF)
   18:13:35.615784 B > A: . ack 1493581 win 64680 (DF)
   18:13:35.615856 B > A: . ack 1496501 win 64680 (DF)
   18:13:35.615952 A > B: . 1524241:1525701(1460) ack 1 win 17248 (DF)
   18:13:35.615966 B > A: . ack 1499421 win 64680 (DF)
   18:13:35.616088 A > B: . 1525701:1527161(1460) ack 1 win 17248 (DF)
   18:13:35.616105 B > A: . ack 1502341 win 64680 (DF)
   18:13:35.616211 A > B: . 1527161:1528621(1460) ack 1 win 17248 (DF)
   18:13:35.616228 B > A: . ack 1505261 win 64680 (DF)
   18:13:35.616327 A > B: . 1528621:1530081(1460) ack 1 win 17248 (DF)
   18:13:35.616349 B > A: . ack 1508181 win 64680 (DF)
   18:13:35.616448 A > B: . 1530081:1531541(1460) ack 1 win 17248 (DF)
   18:13:35.616565 A > B: . 1531541:1533001(1460) ack 1 win 17248 (DF)
   18:13:35.616891 A > B: . 1533001:1534461(1460) ack 1 win 17248 (DF)

	在本例中，每两段到达的数据产生一个ACK。(即使源主机是同一个，由于没有时间戳
选项，在本例中段长较大)。

如何检测
	这样的情况可在当通告的MSS比连接的实际PMTU要大得多的跟踪包中可看到。
如何修改该问题有几个建议：
	一个简单的办法是回答每个包，而不管其大小。这有一个缺点是在处理大量小包时产
生大量的ACK；在X窗口系统中就有这样的应用。
	一个稍微复杂的处理办法是监测进来的段大小并试图决定发送者使用的段大小。这对
接收者的状态要求多一点，但计算得更精确，能避免糊涂窗口综合症。

2.3 问题名字
	从PMTU确定MSS
分类
	性能
描述
	在连接开始阶段的MSS通告应基于系统接口的MTU。（因为效率和其它原因这可能不是
最大的MSS）。某些系统使用决定的PMTUD值来决定要通告的MSS值。
	这导致了通告的MSS要小于系统能接收的最大的MTU。
意义
	通告的MSS向远程系统指示了可接收的最大TCP段[RFC879]。若该值太小，远程系统
在发送时被迫使用小的段长，完全是由于本地系统在较早时发现一个特别的PMTU。
	由于Internet上路由器的不对称属性[Paxson97]，返回的PMTU和发送的PMTU完全可
能不同。使用这种办法限制段长可能造成性能降低及使PMTUD算法失败。
	即使路由器是对称的，人为将段长限制降低会使得不可能以后查询来决定PMTU是否改
变。
含义
	整个PMTUD的要点是尽可能发送大的段。若一个持续了很长时间的连接不能检测到更
大的PMTUD，那么就无法获得潜在的性能。这破坏了PMTUD的要点。
相关RFC RFC1191。
	[RFC879]有MSS计算和适当值的讨论。注意本实践并不和这些RFC的定义相冲突。
阐述问题的输出文件
	输出文件是在中间主机上用tcpdump记录。主机A初始化两条到主机B的单独的连接
A1和A2。路由器是在MTU瓶颈位置。TCP选项照常从所有非SYN包中移走。

   22:33:32.305912 A1 > B: S 1523306220:1523306220(0)
        win 8760 <mss 1460> (DF)
   22:33:32.306518 B > A1: S 729966260:729966260(0)
        ack 1523306221 win 16384 <mss 65240>
   22:33:32.310307 A1 > B: . ack 1 win 8760 (DF)
   22:33:32.323496 A1 > B: P 1:1461(1460) ack 1 win 8760 (DF)
   22:33:32.323569 C > A1: icmp: 129.99.238.5 unreachable -
        need to frag (mtu 1024) (DF) (ttl 255, id 20666)
   22:33:32.783694 A1 > B: . 1:985(984) ack 1 win 8856 (DF)
   22:33:32.840817 B > A1: . ack 985 win 16384
   22:33:32.845651 A1 > B: . 1461:2445(984) ack 1 win 8856 (DF)
   22:33:32.846094 B > A1: . ack 985 win 16384
   22:33:33.724392 A1 > B: . 985:1969(984) ack 1 win 8856 (DF)
   22:33:33.724893 B > A1: . ack 2445 win 14924
   22:33:33.728591 A1 > B: . 2445:2921(476) ack 1 win 8856 (DF)
   22:33:33.729161 A1 > B: . ack 1 win 8856 (DF)
   22:33:33.840758 B > A1: . ack 2921 win 16384

   [...]

   22:33:34.238659 A1 > B: F 7301:8193(892) ack 1 win 8856 (DF)
   22:33:34.239036 B > A1: . ack 8194 win 15492
   22:33:34.239303 B > A1: F 1:1(0) ack 8194 win 16384

   22:33:34.242971 A1 > B: . ack 2 win 8856 (DF)
   22:33:34.454218 A2 > B: S 1523591299:1523591299(0)
        win 8856 <mss 984> (DF)
   22:33:34.454617 B > A2: S 732408874:732408874(0)
        ack 1523591300 win 16384 <mss 65240>
   22:33:34.457516 A2 > B: . ack 1 win 8856 (DF)
   22:33:34.470683 A2 > B: P 1:985(984) ack 1 win 8856 (DF)
   22:33:34.471144 B > A2: . ack 985 win 16384
   22:33:34.476554 A2 > B: . 985:1969(984) ack 1 win 8856 (DF)
   22:33:34.477580 A2 > B: P 1969:2953(984) ack 1 win 8856 (DF)

   [...]
注意会话A2的SYN包定义了MSS为984。

解释什么是正确处理的输出文件
和前面一样，输出文件是在中间主机上用tcpdump记录。主机A初始化两条到主机B的单独
的连接A1和A2。路由器是在MTU瓶颈位置。TCP选项照常从所有非SYN包中移走。

   22:36:58.828602 A1 > B: S 3402991286:3402991286(0) win 32768
        <mss 4312,wscale 0,nop,timestamp 1123370309 0,
         echo 1123370309> (DF)
   22:36:58.844040 B > A1: S 946999880:946999880(0)
        ack 3402991287 win 16384
        <mss 65240,nop,wscale 0,nop,nop,timestamp 429552 1123370309>
   22:36:58.848058 A1 > B: . ack 1 win 32768  (DF)
   22:36:58.851514 A1 > B: P 1:1025(1024) ack 1 win 32768  (DF)
   22:36:58.851584 C > A1: icmp: 129.99.238.5 unreachable -
        need to frag (mtu 1024) (DF)
   22:36:58.855885 A1 > B: . 1:969(968) ack 1 win 32768  (DF)
   22:36:58.856378 A1 > B: . 969:985(16) ack 1 win 32768  (DF)
   22:36:59.036309 B > A1: . ack 985 win 16384
   22:36:59.039255 A1 > B: FP 985:1025(40) ack 1 win 32768  (DF)
   22:36:59.039623 B > A1: . ack 1026 win 16344
   22:36:59.039828 B > A1: F 1:1(0) ack 1026 win 16384
   22:36:59.043037 A1 > B: . ack 2 win 32768  (DF)
   22:37:01.436032 A2 > B: S 3404812097:3404812097(0) win 32768
        <mss 4312,wscale 0,nop,timestamp 1123372916 0,
         echo 1123372916> (DF)
   22:37:01.436424 B > A2: S 949814769:949814769(0)
        ack 3404812098 win 16384
        <mss 65240,nop,wscale 0,nop,nop,timestamp 429562 1123372916>
   22:37:01.440147 A2 > B: . ack 1 win 32768  (DF)
   22:37:01.442736 A2 > B: . 1:969(968) ack 1 win 32768  (DF)

   22:37:01.442894 A2 > B: P 969:985(16) ack 1 win 32768  (DF)
   22:37:01.443283 B > A2: . ack 985 win 16384
   22:37:01.446068 A2 > B: P 985:1025(40) ack 1 win 32768  (DF)
   22:37:01.446519 B > A2: . ack 1025 win 16384
   22:37:01.448465 A2 > B: F 1025:1025(0) ack 1 win 32768  (DF)
   22:37:01.448837 B > A2: . ack 1026 win 16384
   22:37:01.449007 B > A2: F 1:1(0) ack 1026 win 16384
   22:37:01.452201 A2 > B: . ack 2 win 32768  (DF)

注意会话A1和A2使用同样的MSS。

如何检测
	可以通过追踪两个单独连接的包来检测；第一个应该激活PMTUD；在第一个之后第二个
应该在PMTU值未超时前尽快启动。
如何修改
	如[RFC1122]和[RFC1191]中指出的，MSS应该基于系统接口的MTU来设置。
3 安全考虑
本备忘录指出的第一个安全考虑是，ICMP黑洞常常由于过于热心于安全的管理员阻塞所有
ICMP消息引起。那些设计和配置安全系统的人理解严格过滤上层协议的影响是至关重要
的。若大多数TCP实现无法从中传输数据的话，世界上最安全的web站点也就没有任何价
值。修复所有黑洞要比修复所有TCP实现要好得多。
4 致谢
	感谢Mark Allman, Vern Paxson,和Jamshid Mahdavi慷慨的帮助审阅了文档，感谢
Matt Mathis对引起PMTUD黑洞问题的各种机制的提议及评论。描述TCP问题的结构和该结
构的早期描述是从[RFC2525]中得来。特别感谢Amy Bock帮助进行PMTUD测试以发现这些漏
洞。

5 参考
   [RFC2581]    Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
                Control", RFC 2581, April 1999.

   [RFC1122]    Braden, R., "Requirements for Internet Hosts --
                Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC813]     Clark, D., "Window and Acknowledgement Strategy in TCP",
                RFC 813, July 1982.

   [Jacobson89] V. Jacobson, C. Leres, and S. McCanne, tcpdump, June
                1989, ftp.ee.lbl.gov

   [RFC1435]    Knowles, S., "IESG Advice from Experience with Path MTU
                Discovery", RFC 1435, March 1993.

   [RFC1191]    Mogul, J. and S. Deering, "Path MTU discovery", RFC
                1191, November 1990.

   [RFC1981]    McCann, J., Deering, S. and J. Mogul, "Path MTU
                Discovery for IP version 6", RFC 1981, August 1996.

   [Paxson96]   V. Paxson, "End-to-End Routing Behavior in the
                Internet", IEEE/ACM Transactions on Networking (5),
                pp.~601-615, Oct. 1997.

   [RFC2525]    Paxon, V., Allman, M., Dawson, S., Fenner, W., Griner,
                J., Heavens, I., Lahey, K., Semke, I. and B. Volz,
                "Known TCP Implementation Problems", RFC 2525, March
                1999.

   [RFC879]     Postel, J., "The TCP Maximum Segment Size and Related
                Topics", RFC 879, November 1983.

   [RFC2001]    Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
                Retransmit, and Fast Recovery Algorithms", RFC 2001,
                January 1997.


6  作者地址：

   Kevin Lahey
   dotRocket, Inc.
   1901 S. Bascom Ave., Suite 300
   Campbell, CA 95008
   USA

   Phone:  [phone] x115
   email:  [e-mail]


7 完整的版权说明

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

致谢
   Funding for the RFC Editor function is currently provided by the
   Internet Society.
RFC2923——TCP Problems with Path MTU Discovery                   TCP的路径MTU发现问题


1
RFC文档中文翻译计划