RFC6691：TCP Options and Maximum Segment Size (MSS)，July 2012
梗概
本备忘录讨论了与 TCP 最大分片大小 (Maximum Segment Size，MSS) 选项一起使用的值，并更新了 RFC 879 和 RFC 2385。
本备忘录的状态
本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准；请参阅 RFC 5741 的第 2 节。
有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6691。
版权声明
版权所有 (c) 2012 IETF Trust 和确定为文档作者的人员。版权所有。
本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。
1、 介绍
在使用 IP 和 TCP 选项时，对于 TCP MSS 选项使用什么值存在一些混淆。RFC 879 [RFC879] 指出：
MSS 只计算段中的数据八位字节，它不计算 TCP 报头或 IP 报头。
该声明不清楚如何处理 IP 和 TCP 选项，因为它们是报文头的一部分。RFC 1122 [RFC1122] 阐明了 MSS 选项，这在附录 A 中进行了讨论，但似乎仍然存在一些混淆。
1.1、 术语
本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是按照 RFC 2119 [RFC2119] 中的描述进行解释。
2、 简短声明
在计算放入 TCP MSS 选项的值时，MTU 值应该仅减少固定 IP 和 TCP 报文头的大小，并且不应减少以考虑任何可能的 IP 或 TCP 选项；相反，发送方必须减少 TCP 数据长度以说明它在发送的数据包中包含的任何 IP 或 TCP 选项。本文档的其余部分仅阐述了该声明，其目标是避免 TCP 数据包的 IP 级分片。
TCP固定头大小为20字节[RFC793]，IPv4固定头大小为20字节[RFC791]，IPv6固定头大小为40字节[RFC2460]。确定应该使用什么 MTU 值，尤其是在多宿主主机的情况下，超出了本文档的范围。
3、 其他 RFC 中的 MSS
3.1、 RFC 879
RFC 879 [RFC879] 讨论了 MSS 选项和其他主题。在引言中，它指出：
TCP 最大分片大小是 IP 最大数据报大小减去40。
在第 13 节中，它指出：
MSS 选项的定义可以表述为：
在没有 IP 头选项的 IP 数据报中传输的没有 TCP 头选项的 TCP 段中，此 TCP 选项的发送方可以接收的最大数据八位字节数。
这些都是正确的。然而，在下一段——在第 14 节中——它通过声明结果是：
当 TCP 用于 IP 或 TCP 报头不是最小但可以接收的最大 IP 数据报仍然是 576 个八位字节的情况下时，必须使用 TCP 最大分片大小选项来减少对数据8位字节的限制TCP 段。
例如，如果使用 IP 安全选项（11 个八位字节）并且 IP 最大数据报大小保持在 576 个八位字节，则 TCP 应发送值为 525 (536-11) 的 MSS。
那是不正确的。更简单、更正确的说法是：
当 TCP 用于 IP 或 TCP 报文头不是最小的情况时，发送方必须将任何给定数据包中的 TCP 数据量减少 IP 和 TCP 选项使用的八位字节数。
3.2、 RFC 2385
RFC 2385 [RFC2385] 在第 4.3 节中错误地指出：
与添加到每个段的其他选项一样，MD5 选项的大小必须考虑到在连接协商期间提供给另一端的 MSS 中。具体来说，要从 MTU 中减去的报文头大小（无论是传出接口的 MTU 还是 IP 的最小 MTU 576 字节）现在至少要大 18 字节。
这是不正确的。MSS 选项的值仅由固定 IP 和 TCP 报文头调整。
4、 来自 TCP 大型 Windows 邮件列表的澄清
最初的澄清于 1993 年发送到 TCP Large Windows 邮件列表 [Borman93]；本节基于该消息。
要在 MSS 选项中发送的 MSS 值应等于有效 MTU 减去固定 IP 和 TCP 报文头。通过在计算 MSS 选项的值时同时忽略 IP 和 TCP 选项，如果数据包中有任何 IP 或 TCP 选项要发送，则发送方必须相应地减小 TCP 数据的大小。原因如下表所示：
目标是不发送必须分片的 IP 数据包，并且发送带有此网格右下方约束的数据包将导致 IP 分片。由于发送方不知道接收到的 MSS 选项是否被调整为包含选项，因此保证数据包不会太长的唯一方法是数据发送方将 TCP 数据长度减少 IP 和 TCP 选项的大小.因此，由于发送方在发送 IP 和 TCP 选项时将调整 TCP 数据长度，因此无需在 MSS 值中包含 IP 和 TCP 选项长度。
另一个反对在确定 MSS 值时包含 IP 或 TCP 选项的论点是 MSS 是一个固定值，而且就其本质而言，IP 和 TCP 选项的长度是可变的，因此 MSS 值永远无法准确反映所有可能的 IP和 TCP 选项组合。唯一确定任何给定数据包中有多少 IP 和 TCP 选项的是发送者；因此，发送方应该调整 TCP 数据长度以考虑任何 IP 和 TCP 选项。
5、 其他注意事项
5.1、 路径 MTU 发现
TCP MSS 选项指定可以接收的数据包大小的上限。因此，将 MSS 选项中的值设置得太小会影响路径 MTU 发现找到更大路径 MTU 的能力。有关路径 MTU 发现的更多信息，请参阅：
“路径 MTU 发现”[RFC1191] “路径 MTU 发现的 TCP 问题”[RFC2923] “分组层路径 MTU 发现” [RFC4821]
5.2、 具有可变 MSS 值的接口
有效 MTU 有时可能会有所不同，如与可变压缩一起使用时，例如 RObust 报文头压缩 (RObust Header Compression，ROHC) [RFC5795]。TCP 想要通告最大可能的 MSS，以支持最有效地使用压缩的有效载荷是很诱人的。不幸的是，一些压缩方案偶尔需要传输完整的报头（以及较小的有效载荷）以重新同步其端点压缩器/解压缩器的状态。如果最大 MTU 用于计算 MSS 选项中要通告的值，则 TCP 重传可能会干扰压缩器重新同步。
因此，当接口的有效 MTU 变化时，TCP 应该使用接口的最小有效 MTU 来计算 MSS 选项中要通告的值。
5.3、 IPv6 跳转
为了支持 TCP over IPv6 jumbograms，实现需要能够发送大于 64K 的 TCP 段。RFC 2675 [RFC2675] 定义了 65,535 的值被视为无穷大，并且路径 MTU 发现 [RFC1981] 用于确定实际的 MSS。
5.4、 避免分片
太长的数据包将被分割或丢弃。如果数据包被分片，中间防火墙或中间设备可能会丢弃分片的数据包。在任何一种情况下，当数据包被丢弃时，连接都可能失败；因此，最好避免生成分片。
6、 安全考虑
本文档阐明了如何确定应该为 MSS 选项使用什么值，并且没有引入任何新的安全问题。
7、 参考文献
7.1、 规范参考
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC879] Postel, J., "The TCP Maximum Segment Size and Related Topics", RFC 879, November 1983. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
7.2、 参考资料
[Borman93] Borman, D., "TCP MSS & Timestamps", Message to the tcplw mailing list, January 7, 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. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
附录 A、 来自 RFC 793 和 RFC 1122 的详细信息
RFC 793 [RFC793] 将 MSS 选项定义如下：
最大分片大小选项数据：16 位
如果存在此选项，则它会在发送此段的 TCP 处传达最大接收段大小。该字段只能在初始连接请求中发送（即，在设置了 SYN 控制位的段中）。如果未使用此选项，则允许任何段大小。
RFC 1122 [RFC1122] 在第 85-86 页的第 4.2.2.6 节中提供了额外的说明。首先，当 MSS 选项不存在时，它会更改默认行为：
如果在连接建立时没有收到 MSS 选项，TCP 必须假定默认发送 MSS 为 536 (576-40) [TCP:4]。
然后，它阐明了如何确定要在 MSS 选项中使用的值：
在 MSS 选项中发送的 MSS 值必须小于或等于：
MMS_R - 20
其中 MMS_R 是可以接收（和重组）的传输层消息的最大大小。TCP从IP层获取MMS_R和MMS_S；请参阅第 3.4 节中的通用调用 GET_MAXSIZES。
RFC 1122 中暗示但未明确说明的是 20 是固定 TCP 报文头的大小。MMS_R 的定义见第 3.3.2 节，第 57 页：
MMS_R 由下式给出：
MMS_R = EMTU_R - 20
因为 20 是 IP 报文头的最小大小。
第 56 页（也是第 3.3.2 节）：
我们指定了可以由 EMTU_R（“有效 MTU 接收”）重新组装的最大数据报大小；这有时称为“重组缓冲区大小”。EMTU_R 必须大于或等于 576，应该是可配置的或不确定的，并且应该大于或等于所连接网络的 MTU。
这里需要注意的是，EMTU_R是可以重组的最大数据报大小，而不是不分片可以接收的最大数据报大小。从字面上看，由于大多数现代 TCP/IP 实现可以重新组装完整的 64K IP 数据包，因此实现应该使用 65535 - 20 - 20 或 65495 作为 MSS 选项。但还有更多。RFC 1122 还在第 86 页上指出：
TCP 段大小的选择对性能有很大的影响。更大的段通过在更多的数据字节上分摊报头大小和每个数据报的处理开销来增加吞吐量；然而，如果数据包太大导致 IP 分片，如果任何分片丢失，效率就会急剧下降 [IP:9]。
由于保证任何大于连接网络的 MTU 的 IP 数据报都必须被分片才能被接收，因此实现忽略了“应该大于或等于连接网络的 MTU”的“大于或”部分网络”。因此，要在 MSS 选项中发送的 MSS 值必须小于或等于：
EMTU_R - FixedIPhdrsize - FixedTCPhdrsize
其中 FixedTCPhdrsize 是 20，FixedIPhdrsize 是 IPv4 的 20 和 IPv6 的 40。
