Internet Engineering Task Force (IETF) D. Borman
Request for Comments: 6691 Quantum Corporation
Updates: 879, 2385 July 2012
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Borman
Request for Comments: 6691 Quantum Corporation
Updates: 879, 2385 July 2012
Category: Informational
ISSN: 2070-1721
TCP Options and Maximum Segment Size (MSS)
TCP选项和最大段大小（MSS）
Abstract
摘要
This memo discusses what value to use with the TCP Maximum Segment Size (MSS) option, and updates RFC 879 and RFC 2385.
本备忘录讨论了TCP最大段大小（MSS）选项使用的值，并更新了RFC 879和RFC 2385。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6691.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6691.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
There has been some confusion as to what value to use with the TCP MSS option when using IP and TCP options. RFC 879 [RFC879] states:
在使用IP和TCP选项时，对于使用TCP MSS选项的值有一些混淆。RFC 879[RFC879]规定：
The MSS counts only data octets in the segment, it does not count the TCP header or the IP header.
MSS只统计段中的数据八位字节，不统计TCP头或IP头。
This statement is unclear about what to do about IP and TCP options, since they are part of the headers. RFC 1122 [RFC1122] clarified the MSS option, which is discussed in Appendix A, but there still seems to be some confusion.
此声明不清楚如何处理IP和TCP选项，因为它们是标头的一部分。RFC 1122[RFC1122]澄清了MSS选项，该选项在附录A中进行了讨论，但似乎仍存在一些混淆。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
When calculating the value to put in the TCP MSS option, the MTU value SHOULD be decreased by only the size of the fixed IP and TCP headers and SHOULD NOT be decreased to account for any possible IP or TCP options; conversely, the sender MUST reduce the TCP data length to account for any IP or TCP options that it is including in the packets that it sends. The rest of this document just expounds on that statement, and the goal is to avoid IP-level fragmentation of TCP packets.
在计算要放入TCP MSS选项的值时，MTU值应仅减少固定IP和TCP头的大小，并且不应减少以考虑任何可能的IP或TCP选项；相反，发送方必须减少TCP数据长度，以考虑其发送的数据包中包含的任何IP或TCP选项。本文档的其余部分仅阐述了该语句，其目标是避免TCP数据包的IP级碎片。
The size of the fixed TCP header is 20 bytes [RFC793], the size of the fixed IPv4 header is 20 bytes [RFC791], and the size of the fixed IPv6 header is 40 bytes [RFC2460]. The determination of what MTU value should be used, especially in the case of multi-homed hosts, is beyond the scope of this document.
固定TCP报头的大小为20字节[RFC793]，固定IPv4报头的大小为20字节[RFC791]，固定IPv6报头的大小为40字节[RFC2460]。确定应该使用什么MTU值，特别是在多主机的情况下，超出了本文档的范围。
RFC 879 [RFC879] discusses the MSS option and other topics. In the Introduction, it states:
RFC 879[RFC879]讨论了MSS选项和其他主题。导言中指出：
THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS FORTY.
TCP最大段大小是IP最大数据报大小减去40。
In Section 13, it states:
在第13节中，它指出：
The definition of the MSS option can be stated:
MSS选项的定义如下：
The maximum number of data octets that may be received by the sender of this TCP option in TCP segments with no TCP header options transmitted in IP datagrams with no IP header options.
在没有TCP头选项的TCP段中，此TCP选项的发送方可以接收的最大数据八位字节数，在没有IP头选项的IP数据报中传输。
These are both correct. However, in the next paragraph -- in Section 14 -- it then confuses this by stating that the consequence is:
这些都是正确的。然而，在下一段——第14节——中，它指出其结果是：
When TCP is used in a situation when either the IP or TCP headers are not minimum and yet the maximum IP datagram that can be received remains 576 octets then the TCP Maximum Segment Size option must be used to reduce the limit on data octets allowed in a TCP segment.
如果在IP或TCP报头不是最小值，但可接收的最大IP数据报仍为576个八位字节的情况下使用TCP，则必须使用TCP最大段大小选项来减少TCP段中允许的数据八位字节限制。
For example, if the IP Security option (11 octets) were in use and the IP maximum datagram size remained at 576 octets, then the TCP should send the MSS with a value of 525 (536-11).
例如，如果正在使用IP安全选项（11个八位字节），且IP最大数据报大小保持在576个八位字节，则TCP应发送值为525（536-11）的MSS。
That is incorrect. The simpler and more correct statement would be:
这是不正确的。更简单、更正确的说法是：
When TCP is used in a situation where either the IP or TCP headers are not minimum, the sender must reduce the amount of TCP data in any given packet by the number of octets used by the IP and TCP options.
当TCP用于IP或TCP头不是最小值的情况时，发送方必须将任何给定数据包中的TCP数据量减少IP和TCP选项使用的八位字节数。
RFC 2385 [RFC2385] incorrectly states, in Section 4.3:
RFC 2385[RFC2385]在第4.3节中错误地说明：
As with other options that are added to every segment, the size of the MD5 option must be factored into the MSS offered to the other side during connection negotiation. Specifically, the size of the header to subtract from the MTU (whether it is the MTU of the outgoing interface or IP's minimal MTU of 576 bytes) is now at least 18 bytes larger.
与添加到每个段的其他选项一样，在连接协商期间，MD5选项的大小必须考虑到提供给另一方的MSS中。具体而言，要从MTU中减去的头的大小（无论是传出接口的MTU还是IP的最小576字节MTU）现在至少要大18字节。
This is incorrect. The value for the MSS option is only adjusted by the fixed IP and TCP headers.
这是不正确的。MSS选项的值仅由固定IP和TCP标头调整。
The initial clarification was sent to the TCP Large Windows mailing list in 1993 [Borman93]; this section is based on that message.
最初的澄清于1993年发送至TCP大型Windows邮件列表[Borman93]；本节以该消息为基础。
The MSS value to be sent in an MSS option should be equal to the effective MTU minus the fixed IP and TCP headers. By ignoring both IP and TCP options when calculating the value for the MSS option, if there are any IP or TCP options to be sent in a packet, then the sender must decrease the size of the TCP data accordingly. The reason for this can be seen in the following table:
在MSS选项中发送的MSS值应等于有效MTU减去固定IP和TCP头。通过在计算MSS选项的值时忽略IP和TCP选项，如果在数据包中要发送任何IP或TCP选项，则发送方必须相应地减小TCP数据的大小。原因如下表所示：
+--------------------+--------------------+
| MSS is adjusted | MSS isn't adjusted |
| to include options | to include options |
+--------------------+--------------------+--------------------+
| Sender adjusts | Packets are too | Packets are the |
| packet length | short | correct length |
| for options | | |
+--------------------+--------------------+--------------------+
| Sender doesn't | Packets are the | Packets are too |
| adjust packet | correct length | long |
| length for options | | |
+--------------------+--------------------+--------------------+
+--------------------+--------------------+
| MSS is adjusted | MSS isn't adjusted |
| to include options | to include options |
+--------------------+--------------------+--------------------+
| Sender adjusts | Packets are too | Packets are the |
| packet length | short | correct length |
| for options | | |
+--------------------+--------------------+--------------------+
| Sender doesn't | Packets are the | Packets are too |
| adjust packet | correct length | long |
| length for options | | |
+--------------------+--------------------+--------------------+
The goal is to not send IP datagrams that have to be fragmented, and packets sent with the constraints in the lower right of this grid will cause IP fragmentation. Since the sender doesn't know if the received MSS option was adjusted to include options, the only way to guarantee that the packets are not too long is for the data sender to decrease the TCP data length by the size of the IP and TCP options. It follows, then, that since the sender will be adjusting the TCP data length when sending IP and TCP options, there is no need to include the IP and TCP option lengths in the MSS value.
目标是不发送必须分段的IP数据报，使用该网格右下角的约束发送的数据包将导致IP分段。由于发送方不知道是否已将接收的MSS选项调整为包含选项，因此确保数据包不太长的唯一方法是数据发送方将TCP数据长度减少IP和TCP选项的大小。因此，由于发送方在发送IP和TCP选项时将调整TCP数据长度，因此无需在MSS值中包含IP和TCP选项长度。
Another argument against including IP or TCP options in the determination of the MSS value is that the MSS is a fixed value, and by their very nature the lengths of IP and TCP options are variable, so the MSS value can never accurately reflect all possible IP and TCP option combinations. The only one that knows for sure how many IP and TCP options are in any given packet is the sender; hence, the sender should be doing the adjustment to the TCP data length to account for any IP and TCP options.
另一个反对在确定MSS值时包括IP或TCP选项的论点是，MSS是一个固定值，并且就其性质而言，IP和TCP选项的长度是可变的，因此MSS值永远无法准确反映所有可能的IP和TCP选项组合。唯一能确定任何给定数据包中有多少IP和TCP选项的是发送方；因此，发送方应该调整TCP数据长度，以考虑任何IP和TCP选项。
The TCP MSS option specifies an upper bound for the size of packets that can be received. Hence, setting the value in the MSS option too small can impact the ability for Path MTU Discovery to find a larger path MTU. For more information on Path MTU Discovery, see:
TCP MSS选项指定可以接收的数据包大小的上限。因此，将MSS选项中的值设置得太小可能会影响路径MTU发现找到更大路径MTU的能力。有关路径MTU发现的详细信息，请参阅：
o "Path MTU Discovery" [RFC1191]
o “路径MTU发现”[RFC1191]
o "TCP Problems with Path MTU Discovery" [RFC2923]
o “路径MTU发现的TCP问题”[RFC2923]
o "Packetization Layer Path MTU Discovery" [RFC4821]
o “打包层路径MTU发现”[RFC4821]
The effective MTU can sometimes vary, as when used with variable compression, e.g., RObust Header Compression (ROHC) [RFC5795]. It is tempting for TCP to want to advertise the largest possible MSS, to support the most efficient use of compressed payloads. Unfortunately, some compression schemes occasionally need to transmit full headers (and thus smaller payloads) to resynchronize state at their endpoint compressors/decompressors. If the largest MTU is used to calculate the value to advertise in the MSS option, TCP retransmission may interfere with compressor resynchronization.
有效MTU有时会发生变化，如与可变压缩一起使用时，例如，鲁棒头压缩（ROHC）[RFC5795]。TCP很想宣传尽可能大的MSS，以支持压缩有效负载的最有效使用。不幸的是，一些压缩方案偶尔需要传输完整的报头（从而更小的有效负载），以便在其端点压缩器/解压缩器处重新同步状态。如果使用最大MTU计算MSS选项中要播发的值，TCP重传可能会干扰压缩器重新同步。
As a result, when the effective MTU of an interface varies, TCP SHOULD use the smallest effective MTU of the interface to calculate the value to advertise in the MSS option.
因此，当接口的有效MTU发生变化时，TCP应使用接口的最小有效MTU来计算要在MSS选项中公布的值。
In order to support TCP over IPv6 jumbograms, implementations need to be able to send TCP segments larger than 64K. RFC 2675 [RFC2675] defines that a value of 65,535 is to be treated as infinity, and Path MTU Discovery [RFC1981] is used to determine the actual MSS.
为了支持TCP over IPv6巨型程序，实现需要能够发送大于64K的TCP段。RFC 2675[RFC2675]定义65535的值将被视为无穷大，路径MTU发现[RFC1981]用于确定实际MSS。
Packets that are too long will either be fragmented or dropped. If packets are fragmented, intermediary firewalls or middle boxes may drop the fragmented packets. In either case, when packets are dropped, the connection can fail; hence, it is best to avoid generating fragments.
过长的数据包将被分割或丢弃。如果数据包是碎片化的，中间防火墙或中间盒可能会丢弃碎片化的数据包。在这两种情况下，当数据包被丢弃时，连接可能会失败；因此，最好避免生成片段。
This document clarifies how to determine what value should be used for the MSS option and does not introduce any new security concerns.
本文件阐明了如何确定MSS选项应使用的值，并且没有引入任何新的安全问题。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC879] Postel, J., "The TCP Maximum Segment Size and Related Topics", RFC 879, November 1983.
[RFC879]Postel，J.，“TCP最大段大小和相关主题”，RFC879，1983年11月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675]Borman，D.，Deering，S.，和R.Hinden，“IPv6巨型程序”，RFC 26751999年8月。
[Borman93] Borman, D., "TCP MSS & Timestamps", Message to the tcplw mailing list, January 7, 1993.
[Borman93]Borman，D.，“TCP MSS和时间戳”，发送给tcplw邮件列表的信息，1993年1月7日。
[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月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
[RFC5795]Sandlund，K.，Pelletier，G.和L-E.Jonsson，“鲁棒头压缩（ROHC）框架”，RFC 57952010年3月。
RFC 793 [RFC793] defines the MSS option as follows:
RFC 793[RFC793]将MSS选项定义如下：
Maximum Segment Size Option Data: 16 bits
最大段大小选项数据：16位
If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. This field must only be sent in the initial connection request (i.e., in segments with the SYN control bit set). If this option is not used, any segment size is allowed.
如果存在此选项，则它会在发送此段的TCP上传递最大接收段大小。此字段只能在初始连接请求中发送（即，在设置了SYN控制位的段中）。如果未使用此选项，则允许任何段大小。
RFC 1122 [RFC1122] provides additional clarification in Section 4.2.2.6, on pages 85-86. First, it changes the default behavior when the MSS option is not present:
RFC 1122[RFC1122]在第85-86页的第4.2.2.6节中提供了额外的澄清。首先，当MSS选项不存在时，它会更改默认行为：
If an MSS option is not received at connection setup, TCP MUST assume a default send MSS of 536 (576-40) [TCP:4].
如果在连接设置时未收到MSS选项，TCP必须假定默认发送MSS为536（576-40）[TCP:4]。
Then, it clarifies how to determine the value to use in the MSS option:
然后，说明如何确定MSS选项中使用的值：
The MSS value to be sent in an MSS option must be less than or equal to:
在MSS选项中发送的MSS值必须小于或等于：
MMS_R - 20
彩信_R-20
where MMS_R is the maximum size for a transport-layer message that can be received (and reassembled). TCP obtains MMS_R and MMS_S from the IP layer; see the generic call GET_MAXSIZES in Section 3.4.
其中，MMS_R是可接收（和重新组装）的传输层消息的最大大小。TCP从IP层获取MMS_R和MMS_S；参见第3.4节中的通用调用GET_MAXSIZES。
What is implied in RFC 1122, but not explicitly stated, is that the 20 is the size of the fixed TCP header. The definition of MMS_R is found in Section 3.3.2, on page 57:
RFC1122中暗示但未明确说明的是，20是固定TCP报头的大小。MMS_R的定义见第57页第3.3.2节：
MMS_R is given by:
MMS\u R由以下公式给出：
MMS_R = EMTU_R - 20
MMS_R = EMTU_R - 20
since 20 is the minimum size of an IP header.
因为20是IP头的最小大小。
and on page 56 (also Section 3.3.2):
第56页（也包括第3.3.2节）：
We designate the largest datagram size that can be reassembled by EMTU_R ("Effective MTU to receive"); this is sometimes called the "reassembly buffer size". EMTU_R MUST be greater than or equal to 576, SHOULD be either configurable or indefinite, and SHOULD be greater than or equal to the MTU of the connected network(s).
我们指定EMTU_R可重组的最大数据报大小（“接收的有效MTU”）；这有时称为“重组缓冲区大小”。EMTU_R必须大于或等于576，应可配置或不确定，并且应大于或等于所连接网络的MTU。
What should be noted here is that EMTU_R is the largest datagram size that can be reassembled, not the largest datagram size that can be received without fragmentation. Taking this literally, since most modern TCP/IP implementations can reassemble a full 64K IP packet, implementations should be using 65535 - 20 - 20, or 65495, for the MSS option. But there is more to it than that. RFC 1122 also states, on page 86:
这里需要注意的是，EMTU_R是可以重新组装的最大数据报大小，而不是可以在没有碎片的情况下接收的最大数据报大小。从字面上看，由于大多数现代TCP/IP实现可以重新组装一个完整的64K IP数据包，因此实现应该使用65535-20-20或65495作为MSS选项。但事情远不止这些。RFC 1122在第86页还规定：
The choice of TCP segment size has a strong effect on performance. Larger segments increase throughput by amortizing header size and per-datagram processing overhead over more data bytes; however, if the packet is so large that it causes IP fragmentation, efficiency drops sharply if any fragments are lost [IP:9].
TCP段大小的选择对性能有很大影响。较大的数据段通过在更多数据字节上摊销报头大小和每个数据报的处理开销来增加吞吐量；但是，如果数据包太大，导致IP碎片，那么如果任何碎片丢失，效率就会急剧下降[IP:9]。
Since it is guaranteed that any IP datagram that is larger than the MTU of the connected network will have to be fragmented to be received, implementations ignore the "greater than or" part of "SHOULD be greater than or equal to the MTU of the connected network(s)". Thus, the MSS value to be sent in an MSS option must be less than or equal to:
由于保证任何大于所连接网络的MTU的IP数据报都必须分段才能接收，因此实现忽略了“大于或部分”应大于或等于所连接网络的MTU。因此，在MSS选项中发送的MSS值必须小于或等于：
EMTU_R - FixedIPhdrsize - FixedTCPhdrsize
EMTU_R-固定phdrsize-固定cphdrsize
where FixedTCPhdrsize is 20, and FixedIPhdrsize is 20 for IPv4 and 40 for IPv6.
其中，FixedTCPhdrsize为20，FixedIPhdrsize为20（IPv4）和40（IPv6）。
Author's Address
作者地址
David Borman Quantum Corporation Mendota Heights, MN 55120
David Borman Quantum Corporation明尼苏达州门多塔高地55120
EMail: david.borman@quantum.com
EMail: david.borman@quantum.com