Network Working Group K. Lahey
Request for Comments: 2923 dotRocket, Inc.
Category: Informational September 2000
Network Working Group K. Lahey
Request for Comments: 2923 dotRocket, Inc.
Category: Informational September 2000
TCP Problems with Path MTU Discovery
路径MTU发现的TCP问题
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU.
本备忘录列出了几个已知的传输控制协议（TCP）实现问题，这些问题涉及路径最大传输单元发现（PMTUD），包括长期存在的黑洞问题、由于最大段大小（MSS）和段大小之间的混淆而产生的拉伸确认（ACK）以及基于PMTU的MSS广告。
This memo catalogs several known TCP implementation problems dealing with Path MTU Discovery [RFC1191], including the long-standing black hole problem, stretch ACKs due to confusion between MSS and segment size, and MSS advertisement based on PMTU. The goal in doing so is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations.
本备忘录列出了几个已知的TCP实现问题，这些问题涉及路径MTU发现[RFC1191]，包括长期存在的黑洞问题、由于MSS和段大小之间的混淆而导致的拉伸确认，以及基于PMTU的MSS广告。这样做的目的是通过提高当前TCP/IP实现的质量来改善现有Internet的条件。
While Path MTU Discovery (PMTUD) can be used with any upper-layer protocol, it is most commonly used by TCP; this document does not attempt to treat problems encountered by other upper-layer protocols. Path MTU Discovery for IPv6 [RFC1981] treats only IPv6-dependent issues, but not the TCP issues brought up in this document.
虽然路径MTU发现（PMTUD）可用于任何上层协议，但它最常用于TCP；本文档不试图处理其他上层协议遇到的问题。IPv6的路径MTU发现[RFC1981]仅处理与IPv6相关的问题，而不处理本文档中提出的TCP问题。
Each problem is defined as follows:
每个问题的定义如下：
Name of Problem The name associated with the problem. In this memo, the name is given as a subsection heading.
问题名称与问题关联的名称。在本备忘录中，该名称作为小节标题给出。
Classification One or more problem categories for which the problem is classified: "congestion control", "performance", "reliability", "non-interoperation -- connectivity failure".
分类问题分类的一个或多个问题类别：“拥塞控制”、“性能”、“可靠性”、“非互操作——连接故障”。
Description A definition of the problem, succinct but including necessary background material.
描述问题的定义，简洁但包括必要的背景材料。
Significance A brief summary of the sorts of environments for which the problem is significant.
重要性简要概述问题所针对的环境类型。
Implications Why the problem is viewed as a problem.
问题被视为问题的含义。
Relevant RFCs The RFCs defining the TCP specification with which the problem conflicts. These RFCs often qualify behavior using terms such as MUST, SHOULD, MAY, and others written capitalized. See RFC 2119 for the exact interpretation of these terms.
相关RFC定义问题与之冲突的TCP规范的RFC。这些RFC通常使用诸如必须、应该、可能和其他大写的术语来限定行为。有关这些术语的准确解释，请参见RFC 2119。
Trace file demonstrating the problem One or more ASCII trace files demonstrating the problem, if applicable.
演示问题的跟踪文件演示问题的一个或多个ASCII跟踪文件（如果适用）。
Trace file demonstrating correct behavior One or more examples of how correct behavior appears in a trace, if applicable.
显示正确行为的跟踪文件一个或多个示例，说明正确行为在跟踪中的显示方式（如果适用）。
References References that further discuss the problem.
进一步讨论该问题的参考资料。
How to detect How to test an implementation to see if it exhibits the problem. This discussion may include difficulties and subtleties associated with causing the problem to manifest itself, and with interpreting traces to detect the presence of the problem (if applicable).
如何检测如何测试一个实现以查看它是否出现问题。这一讨论可能包括与导致问题显现相关的困难和微妙之处，以及与解释痕迹以检测问题的存在（如果适用）相关的困难和微妙之处。
How to fix For known causes of the problem, how to correct the implementation.
如何修复问题的已知原因，如何纠正实施。
2.1.
2.1.
Name of Problem Black Hole Detection
问题黑洞探测的名称
Classification Non-interoperation -- connectivity failure
分类非互操作--连接失败
Description A host performs Path MTU Discovery by sending out as large a packet as possible, with the Don't Fragment (DF) bit set in the IP header. If the packet is too large for a router to forward on to a particular link, the router must send an ICMP Destination Unreachable -- Fragmentation Needed message to the source address. The host then adjusts the packet size based on the ICMP message.
描述主机通过发送尽可能大的数据包来执行路径MTU发现，并在IP报头中设置Dot-Fragment（DF）位。如果数据包太大，路由器无法转发到特定链路，则路由器必须向源地址发送ICMP目的地不可到达（需要碎片）消息。然后，主机根据ICMP消息调整数据包大小。
As was pointed out in [RFC1435], routers don't always do this correctly -- many routers fail to send the ICMP messages, for a variety of reasons ranging from kernel bugs to configuration problems. Firewalls are often misconfigured to suppress all ICMP messages. IPsec [RFC2401] and IP-in-IP [RFC2003] tunnels shouldn't cause these sorts of problems, if the implementations follow the advice in the appropriate documents.
正如[RFC1435]中指出的，路由器并不总是正确地执行此操作——许多路由器无法发送ICMP消息，原因有很多，从内核错误到配置问题。防火墙通常被错误配置为抑制所有ICMP消息。IPsec[RFC2401]和IP[RFC2003]隧道中的IP如果实现遵循适当文档中的建议，则不应导致此类问题。
PMTUD, as documented in [RFC1191], fails when the appropriate ICMP messages are not received by the originating host. The upper-layer protocol continues to try to send large packets and, without the ICMP messages, never discovers that it needs to reduce the size of those packets. Its packets are disappearing into a PMTUD black hole.
如[RFC1191]中所述，当发起主机未接收到适当的ICMP消息时，PMTUD将失败。上层协议继续尝试发送大数据包，并且在没有ICMP消息的情况下，从未发现需要减小这些数据包的大小。它的数据包正在消失在一个PMTUD黑洞中。
Significance When PMTUD fails due to the lack of ICMP messages, TCP will also completely fail under some conditions.
重要意义当PMTUD由于缺少ICMP消息而失败时，TCP在某些情况下也会完全失败。
Implications This failure is especially difficult to debug, as pings and some interactive TCP connections to the destination host work. Bulk transfers fail with the first large packet and the connection eventually times out.
由于ping和到目标主机的一些交互式TCP连接可以正常工作，因此此故障尤其难以调试。第一个大数据包的批量传输失败，连接最终超时。
These situations can almost always be blamed on a misconfiguration within the network, which should be corrected. However it seems inappropriate for some TCP implementations to suffer
这些情况几乎总是可以归咎于网络内部的错误配置，应该予以纠正。然而，对于某些TCP实现来说，这似乎是不合适的
interoperability failures over paths which do not affect other TCP implementations (i.e. those without PMTUD). This creates a market disincentive for deploying TCP implementation with PMTUD enabled.
路径上的互操作性故障不会影响其他TCP实现（即没有PMTUD的路径）。这就造成了市场对部署启用PMTUD的TCP实现的抑制。
Relevant RFCs RFC 1191 describes Path MTU Discovery. RFC 1435 provides an early description of these sorts of problems.
相关RFCs RFC 1191描述了路径MTU发现。RFC 1435提供了此类问题的早期描述。
Trace file demonstrating the problem Made using tcpdump [Jacobson89] recording at an intermediate host.
在中间主机上使用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)
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)
The short SYN packet has no trouble traversing the network, due to its small size. Similarly, ICMP echo packets used to diagnose connectivity problems will succeed.
短SYN数据包由于其较小的尺寸，在穿越网络时没有问题。同样，用于诊断连接问题的ICMP回显数据包也会成功。
Large data packets fail to traverse the network. Eventually the connection times out. This can be especially confusing when the application starts out with a very small write, which succeeds, following up with many large writes, which then fail.
大数据包无法通过网络。最终连接超时。当应用程序以一个非常小的写入开始时，这可能会特别令人困惑，它成功了，接着是许多大的写入，然后失败了。
Trace file demonstrating correct behavior
显示正确行为的跟踪文件
Made using tcpdump recording at an intermediate host.
在中间主机上使用tcpdump录制制作。
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.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
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
In this case, the sender sees four packets fail to traverse the network (using a two-packet initial send window) and turns off PMTUD. All subsequent packets have the DF flag turned off, and the size set to the default value of 536 [RFC1122].
在这种情况下，发送方看到四个数据包无法通过网络（使用两个数据包的初始发送窗口），并关闭PMTUD。所有后续数据包的DF标志都已关闭，并且大小设置为默认值536[RFC1122]。
References This problem has been discussed extensively on the tcp-impl mailing list; the name "black hole" has been in use for many years.
参考文献在tcp impl邮件列表中对此问题进行了广泛讨论；“黑洞”这个名字已经用了很多年了。
How to detect This shows up as a TCP connection which hangs (fails to make progress) until closed by timeout (this often manifests itself as a connection that connects and starts to transfer, then eventually terminates after 15 minutes with zero bytes transfered). This is particularly annoying with an application like ftp, which will work perfectly while it uses small packets for control information, and then fail on bulk transfers.
如何检测这一点显示为TCP连接挂起（无法取得进展），直到超时关闭（这通常表现为连接并开始传输，然后在15分钟后以零字节传输结束）。对于ftp这样的应用程序来说，这尤其令人恼火，因为它使用小数据包作为控制信息，然后在大容量传输时失败，但却能完美地工作。
A series of ICMP echo packets will show that the two end hosts are still capable of passing packets, a series of MTU-sized ICMP echo packets will show some fragmentation, and a series of MTU-sized ICMP echo packets with DF set will fail. This can be confusing for network engineers trying to diagnose the problem.
一系列ICMP回显数据包将显示两个终端主机仍然能够传递数据包，一系列MTU大小的ICMP回显数据包将显示一些碎片，一系列设置了DF的MTU大小的ICMP回显数据包将失败。对于试图诊断问题的网络工程师来说，这可能会令人困惑。
There are several traceroute implementations that do PMTUD, and can demonstrate the problem.
有几个traceroute实现可以实现PMTUD，并且可以演示这个问题。
How to fix TCP should notice that the connection is timing out. After several timeouts, TCP should attempt to send smaller packets, perhaps turning off the DF flag for each packet. If this succeeds, it should continue to turn off PMTUD for the connection for some reasonable period of time, after which it should probe again to try to determine if the path has changed.
如何修复TCP应该注意连接正在超时。在几次超时之后，TCP应该尝试发送较小的数据包，可能会关闭每个数据包的DF标志。如果成功，它应该在一段合理的时间内继续关闭连接的PMTUD，之后应该再次探测以尝试确定路径是否已更改。
Note that, under IPv6, there is no DF bit -- it is implicitly on at all times. Fragmentation is not allowed in routers, only at the originating host. Fortunately, the minimum supported MTU for IPv6 is 1280 octets, which is significantly larger than the 68 octet minimum in IPv4. This should make it more reasonable for IPv6 TCP implementations to fall back to 1280 octet packets, when IPv4 implementations will probably have to turn off DF to respond to black hole detection.
请注意，在IPv6下，没有DF位——它始终隐式打开。路由器中不允许碎片，仅在原始主机上。幸运的是，IPv6支持的最小MTU为1280个八位字节，远远大于IPv4中的最小68个八位字节。这将使IPv6 TCP实现回退到1280个八位字节数据包更加合理，而IPv4实现可能必须关闭DF才能响应黑洞检测。
Ideally, the ICMP black holes should be fixed when they are found.
理想情况下，ICMP黑洞在被发现时应该被修复。
If hosts start to implement black hole detection, it may be that these problems will go unnoticed and unfixed. This is especially unfortunate, since detection can take several seconds each time, and these delays could result in a significant, hidden degradation of performance. Hosts that implement black hole detection should probably log detected black holes, so that they can be fixed.
如果主机开始执行黑洞检测，这些问题可能会被忽略，并且没有得到解决。这尤其令人遗憾，因为每次检测可能需要几秒钟的时间，而这些延迟可能会导致性能显著、隐蔽的下降。实现黑洞检测的主机可能应该记录检测到的黑洞，以便修复它们。
2.2.
2.2.
Name of Problem Stretch ACK due to PMTUD
PMTUD导致的问题拉伸确认的名称
Classification Congestion Control / Performance
分类拥塞控制/性能
Description When a naively implemented TCP stack communicates with a PMTUD equipped stack, it will try to generate an ACK for every second full-sized segment. If it determines the full-sized segment based on the advertised MSS, this can degrade badly in the face of PMTUD.
说明：当一个简单实现的TCP堆栈与配备PMTUD的堆栈通信时，它将尝试为每一秒的全尺寸段生成一个ACK。如果它根据公布的MSS确定全尺寸段，则在面对PMTUD时会严重降级。
The PMTU can wind up being a small fraction of the advertised MSS; in this case, an ACK would be generated only very infrequently.
PMTU最终可能只是广告MSS的一小部分；在这种情况下，只会非常不频繁地生成ACK。
Significance
意义
Stretch ACKs have a variety of unfortunate effects, more fully outlined in [RFC2525]. Most of these have to do with encouraging a more bursty connection, due to the infrequent arrival of ACKs. They can also impede congestion window growth.
[RFC2525]中更全面地概述了拉伸ACK有各种不幸的影响。由于ACK很少出现，其中大部分都与鼓励更频繁的连接有关。它们还可能阻碍拥堵窗口的增长。
Implications
启示
The complete implications of stretch ACKs are outlined in [RFC2525].
[RFC2525]概述了拉伸ACK的完整含义。
Relevant RFCs RFC 1122 outlines the requirements for frequency of ACK generation. [RFC2581] expands on this and clarifies that delayed ACK is a SHOULD, not a MUST.
相关RFC RFC 1122概述了ACK生成频率的要求。[RFC2581]对此进行了扩展，并阐明延迟确认是应该的，而不是必须的。
Trace file demonstrating it
演示它的跟踪文件
Made using tcpdump recording at an intermediate host. The timestamp options from all but the first two packets have been removed for clarity.
在中间主机上使用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)
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)
Note that the interval between ACKs is significantly larger than two times the segment size; it works out to be almost exactly two times the advertised MSS. This transfer was long enough that it could be verified that the stretch ACK was not the result of lost ACK packets.
注意，ACK之间的间隔明显大于段大小的两倍；它几乎正好是广告MSS的两倍。此传输足够长，可以验证拉伸ACK不是丢失ACK数据包的结果。
Trace file demonstrating correct behavior
显示正确行为的跟踪文件
Made using tcpdump recording at an intermediate host. The timestamp options from all but the first two packets have been removed for clarity.
在中间主机上使用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)
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)
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)
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)
In this trace, an ACK is generated for every two segments that arrive. (The segment size is slightly larger in this trace, even though the source hosts are the same, because of the lack of timestamp options in this trace.)
在此跟踪中，每两个到达的段生成一个ACK。（由于此跟踪中缺少时间戳选项，因此即使源主机相同，此跟踪中的段大小也稍大。）
How to detect This condition can be observed in a packet trace when the advertised MSS is significantly larger than the actual PMTU of a connection.
当播发的MSS明显大于连接的实际PMTU时，可以在数据包跟踪中观察到如何检测这种情况。
How to fix Several solutions for this problem have been proposed:
已经提出了如何解决此问题的几种解决方案：
A simple solution is to ACK every other packet, regardless of size. This has the drawback of generating large numbers of ACKs in the face of lots of very small packets; this shows up with applications like the X Window System.
一个简单的解决方案是，不管大小，每隔一个数据包都要确认一次。这具有在面对大量非常小的数据包时生成大量ack的缺点；这在像X窗口系统这样的应用程序中表现出来。
A slightly more complex solution would monitor the size of incoming segments and try to determine what segment size the sender is using. This requires slightly more state in the receiver, but has the advantage of making receiver silly window syndrome avoidance computations more accurate [RFC813].
一个稍微复杂一点的解决方案将监视传入段的大小，并尝试确定发送方使用的段大小。这需要接收器中稍多的状态，但其优点是使接收器的计算更精确[RFC813]。
2.3.
2.3.
Name of Problem Determining MSS from PMTU
从PMTU确定MSS的问题名称
Classification Performance
分类性能
Description The MSS advertised at the start of a connection should be based on the MTU of the interfaces on the system. (For efficiency and other reasons this may not be the largest MSS possible.) Some systems use PMTUD determined values to determine the MSS to advertise.
说明连接开始时公布的MSS应基于系统接口的MTU。（出于效率和其他原因，这可能不是可能的最大MSS。）一些系统使用PMTUD确定的值来确定要公布的MSS。
This results in an advertised MSS that is smaller than the largest MTU the system can receive.
这导致播发的MSS小于系统可接收的最大MTU。
Significance The advertised MSS is an indication to the remote system about the largest TCP segment that can be received [RFC879]. If this value is too small, the remote system will be forced to use a smaller segment size when sending, purely because the local system found a particular PMTU earlier.
意义播发的MSS向远程系统指示可接收的最大TCP段[RFC879]。如果该值太小，则在发送时，远程系统将被迫使用较小的段大小，这纯粹是因为本地系统先前发现了特定的PMTU。
Given the asymmetric nature of many routes on the Internet [Paxson97], it seems entirely possible that the return PMTU is different from the sending PMTU. Limiting the segment size in this way can reduce performance and frustrate the PMTUD algorithm.
考虑到互联网上许多路由的不对称性质[Paxson97]，返回的PMTU与发送的PMTU似乎完全可能不同。以这种方式限制段大小会降低性能并阻碍PMTUD算法。
Even if the route was symmetric, setting this artificially lowered limit on segment size will make it impossible to probe later to determine if the PMTU has changed.
即使路线是对称的，设置人为降低的段大小限制也将使以后无法探测以确定PMTU是否已更改。
Implications The whole point of PMTUD is to send as large a segment as possible. If long-running connections cannot successfully probe for larger PMTU, then potential performance gains will be impossible to realize. This destroys the whole point of PMTUD.
含义PMTUD的全部目的是发送尽可能大的数据段。如果长时间运行的连接无法成功探测到更大的PMTU，那么潜在的性能提升将不可能实现。这破坏了PMTUD的全部功能。
Relevant RFCs RFC 1191. [RFC879] provides a complete discussion of MSS calculations and appropriate values. Note that this practice does not violate any of the specifications in these RFCs.
相关RFC RFC 1191。[RFC879]提供了MSS计算和适当值的完整讨论。请注意，这种做法不违反这些RFC中的任何规范。
Trace file demonstrating it This trace was made using tcpdump running on an intermediate host. Host A initiates two separate consecutive connections, A1 and A2, to host B. Router C is the location of the MTU bottleneck. As usual, TCP options are removed from all non-SYN packets.
此跟踪是使用运行在中间主机上的tcpdump进行的。主机A向主机B发起两个独立的连续连接A1和A2。路由器C是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: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.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)
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)
[...]
[...]
Notice that the SYN packet for session A2 specifies an MSS of 984.
注意，会话A2的SYN数据包指定MSS为984。
Trace file demonstrating correct behavior
显示正确行为的跟踪文件
As before, this trace was made using tcpdump running on an intermediate host. Host A initiates two separate consecutive connections, A1 and A2, to host B. Router C is the location of the MTU bottleneck. As usual, TCP options are removed from all non-SYN packets.
与以前一样，此跟踪是使用在中间主机上运行的tcpdump进行的。主机A向主机B发起两个独立的连续连接A1和A2。路由器C是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: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)
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)
Note that the same MSS was used for both session A1 and session A2.
注意，会话A1和会话A2都使用了相同的MSS。
How to detect This can be detected using a packet trace of two separate connections; the first should invoke PMTUD; the second should start soon enough after the first that the PMTU value does not time out.
如何检测这一点可以使用两个独立连接的数据包跟踪来检测；第一个应该调用PMTUD；第二个应在第一个之后很快开始，以使PMTU值不会超时。
How to fix The MSS should be determined based on the MTUs of the interfaces on the system, as outlined in [RFC1122] and [RFC1191].
应根据[RFC1122]和[RFC1191]中概述的系统上接口的MTU确定如何修复MSS。
The one security concern raised by this memo is that ICMP black holes are often caused by over-zealous security administrators who block all ICMP messages. It is vitally important that those who design and deploy security systems understand the impact of strict filtering on upper-layer protocols. The safest web site in the world is worthless if most TCP implementations cannot transfer data from it. It would be far nicer to have all of the black holes fixed rather than fixing all of the TCP implementations.
这份备忘录提出的一个安全问题是，ICMP黑洞通常是由过于热心的安全管理员阻止所有ICMP消息造成的。设计和部署安全系统的人员必须了解严格过滤对上层协议的影响，这一点至关重要。如果大多数TCP实现无法从中传输数据，那么世界上最安全的网站就一文不值。修复所有黑洞比修复所有TCP实现要好得多。
Thanks to Mark Allman, Vern Paxson, and Jamshid Mahdavi for generous help reviewing the document, and to Matt Mathis for early suggestions of various mechanisms that can cause PMTUD black holes, as well as review. The structure for describing TCP problems, and the early description of that structure is from [RFC2525]. Special thanks to Amy Bock, who helped perform the PMTUD tests which discovered these bugs.
感谢Mark Allman、Vern Paxson和Jamshid Mahdavi对审查该文件的慷慨帮助，感谢Matt Mathis对可能导致PMTUD黑洞的各种机制的早期建议以及审查。描述TCP问题的结构，以及该结构的早期描述来自[RFC2525]。特别感谢Amy Bock，他帮助执行了发现这些bug的PMTUD测试。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求——通信层”，标准3，RFC 1122，1989年10月。
[RFC813] Clark, D., "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
[RFC813]Clark，D.，“TCP中的窗口和确认策略”，RFC813，1982年7月。
[Jacobson89] V. Jacobson, C. Leres, and S. McCanne, tcpdump, June 1989, ftp.ee.lbl.gov
[Jacobson89]V.Jacobson，C.Leres和S.McCanne，tcpdump，1989年6月，ftp.ee.lbl.gov
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[RFC1435]Knowles，S.，“来自Path MTU发现经验的IESG建议”，RFC 1435，1993年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[Paxson96] V. Paxson, "End-to-End Routing Behavior in the Internet", IEEE/ACM Transactions on Networking (5), pp.~601-615, Oct. 1997.
[Paxson 96]V.Paxson，“互联网中的端到端路由行为”，IEEE/ACM网络交易（5），第601-615页，1997年10月。
[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.
[RFC2525]Paxon，V.，Allman，M.，Dawson，S.，Fenner，W.，Griner，J.，天堂，I.，Lahey，K.，Semke，I.和B.Volz，“已知的TCP实施问题”，RFC 25251999年3月。
[RFC879] Postel, J., "The TCP Maximum Segment Size and Related Topics", RFC 879, November 1983.
[RFC879]Postel，J.，“TCP最大段大小和相关主题”，RFC879，1983年11月。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[RFC2001]Stevens，W.“TCP慢启动、拥塞避免、快速重传和快速恢复算法”，RFC 2001，1997年1月。
Kevin Lahey dotRocket, Inc. 1901 S. Bascom Ave., Suite 300 Campbell, CA 95008 USA
Kevin Lahey dotRocket，Inc.美国加利福尼亚州坎贝尔南巴斯康大道1901号300室，邮编95008
Phone: +1 408-371-8977 x115
email: kml@dotrocket.com
Phone: +1 408-371-8977 x115
email: kml@dotrocket.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。