摘要

  • MSS 选项为 Kind 2、长度 4，只能在 SYN 中发送，表示选项发送方愿意在一个 TCP 段中接收的最大 TCP 数据量。
  • 两个方向彼此独立。该数值不包括 IP 和 TCP 首部；发送方还必须根据实际首部和路径限制构造数据包。

两个 SYN，两个接收边界

把它称作“协商”容易造成误解。A 的声明描述 A 的接收能力，B 的声明描述 B 的接收能力。因此，即使数值不同，也不代表双方存在分歧：它们约束的是相反方向的流量。

RFC 9293 对格式和含义都有明确规定：Kind 2、Length 4，随后是 16 位 MSS 值。MSS 属于 TCP 必须支持的选项集合。该选项可以出现在带 SYN 的初始连接请求中，不应出现在后续普通报文里。它在连接建立时形成约束，而不是持续更新的容量报告。

MSS 计算的是 TCP 数据字节，不包含 IP 和 TCP 首部。它不是 IP 数据报大小、接口 MTU，也不是应用写入大小。发送方把对端的声明作为一个限制，同时还要考虑路径信息和实际添加的首部。

RFC 879 在 1983 年已经指出，把 MSS 称为“协商”往往是不准确的。接收方说明自己能接受什么；发送方据此并结合自身知识形成数据包。

为什么默认值是 536

RFC 879 描述的 IPv4 默认情形要求主机能够重组 576 字节的 IP 数据报。减去最小的 20 字节 IPv4 首部和 20 字节 TCP 首部后，剩下 536 字节 TCP 数据。

这是一种兼容性计算，不是对实际路径的测量。它并不证明每条路径的 MTU 都是 576，也不说明某种链路提供了普遍答案。

MSS 也不同于路径 MTU 发现。PMTUD 试图了解路径属性，而路径属性可能变化；MSS 在连接开始时交换，描述的是某个端点的接收能力。

关于选项空间的修正

一些实现会为了预留未来的 IP 或 TCP 选项空间而降低所公布的 MSS。RFC 6691 澄清，这样做并不正确：接收方应公布自己能够重组的最大 TCP 负载，而不是扣除假定的首部空间。

发送方在构造每个具体数据包时，再根据实际存在的选项和适用的 IP 大小限制调整数据量。较大的 MSS 不允许发送超过路径能力的数据包；较小的 MSS 也不能证明每一跳都支持某个特定 MTU。

中间设备能改写什么

中间设备可以在 SYN 中改写 MSS，例如为隧道开销留出空间。这样做改变的是呈现给对端的接收约束，并不会把 MSS 变成经过认证的路径容量测量。

抓包只能证明观察点看到的值。该值可能已被改写，不能单独揭示原始声明、所有后续路径 MTU 或发送较小数据包的原因。

历史经验是分清职责边界：接收方声明自己的限制，发送方负责构造，路径仍是外部约束。

来源