RFC66981：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 信托关于 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 [IGMPv1：IP 组播的主机扩展] 阐明了 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 节中）它通过说明结果是：
如果在IP或TCP报文头不是最小值，但可接收的最大IP数据报仍为576个八位字节的情况下使用TCP，则必须使用TCP最大段大小选项来减少TCP分片中允许的数据八位字节限制。
例如，如果使用 IP 安全选项（11 个八位字节）并且 IP 最大数据报大小保持在 576 个八位字节，则 TCP 应发送值为 525 (536-11) 的 MSS。
这是不正确的。更简单、更正确的说法是：
当在 IP 或 TCP 报文头不是最小的情况下使用 TCP 时，发送方必须将任何给定数据包中的 TCP 数据量减少 IP 和 TCP 选项使用的八位字节数。
3.2、 RFC 2385
RFC 2385 [RFC2385] 在第 4.3 节中错误地指出：
与添加到每个段的其他选项一样，MD5 选项的大小必须考虑到在连接协商期间提供给另一方的 MSS。具体来说，从 MTU 中减去的报文头大小（无论是传出接口的 MTU 还是 IP 的 576 字节的最小 MTU）现在至少大 18 字节。
这是不正确的。MSS 选项的值仅由固定 IP 和 TCP 报文头调整。
4、 TCP Large Windows Mailing List 的说明
最初的澄清在 1993 年被发送到 TCP 大型 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 Header Compression (ROHC) [RFC5795]。TCP 很想宣传最大可能的 MSS，以支持最有效地使用压缩负载。不幸的是，一些压缩方案偶尔需要传输完整的报文头（因此更小的有效载荷）以在其端点压缩/解压缩处重新同步状态。如果在 MSS 选项中使用最大 MTU 来计算要通告的值，则 TCP 重传可能会干扰压缩器重新同步。
因此，当接口的有效 MTU 变化时，TCP 应该使用接口的最小有效 MTU 来计算 MSS 选项中要通告的值。
5.3、 IPv6 乱码
为了支持 TCP over IPv6 jumbograms，实现需要能够发送大于 64K 的 TCP 分片。RFC 2675 [RFC2675] 定义值 65,535 被视为无穷大，并且 Path MTU Discovery [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 的定义见第 57 页的第 3.3.2 节：
MMS_R 由下式给出：
MMS_R = EMTU_R - 20
因为 20 是 IP 报文头的最小大小。
在第 56 页（也是第 3.3.2 节）：
我们指定可以由 EMTU_R 重组的最大数据报大小（“Effective MTU to receive”）；这有时称为“重组缓冲区大小”。EMTU_R 必须大于或等于 576，应该是可配置的或不确定的，并且应该大于或等于连接网络的 MTU。
这里需要注意的是，EMTU_R是可以重组的最大数据报大小，而不是可以不分片接收的最大数据报大小。从字面上看，由于大多数现代 TCP/IP 实现可以重新组装完整的 64K IP 数据包，因此对于 MSS 选项，实现应该使用 65535 - 20 - 20 或 65495。但不止于此。RFC 1122 在第 86 页还指出：
TCP 分片大小的选择对性能有很大的影响。较大的分片通过将报文头大小和每个数据报的处理开销分摊到更多数据字节来增加吞吐量；但是，如果数据包太大而导致 IP 分片，如果任何分片丢失，效率就会急剧下降 [IP:9]。
由于保证任何大于所连接网络的MTU的IP数据报都必须分片才能被接收，因此实现忽略了“大于或部分”应大于或等于所连接网络的MTU。因此，在MSS选项中发送的MSS值必须小于或等于：
EMTU_R - FixedIPhdrsize - FixedTCPhdrsize
其中 FixedTCPhdrsize 是 20，对于 IPv4，FixedIPhdrsize 是 20，对于 IPv6 是 40。
