TCP MSS

TCP MSS（Maximum Segment Size，最大段大小） 是 TCP 协议中用于控制数据传输效率的重要参数，它定义了单个 TCP 段（Segment）中可以承载的最大数据量（不包括 TCP 头部和 IP 头部）。

如何确定 MSS 值

• 协商过程 ：在 TCP 三次握手阶段，通信双方通过 TCP 选项字段 （Option Field）交换各自的 MSS 值。
  • 例如：主机 A 发送 SYN 包时，附带 MSS=1460，表示希望接收的每个 TCP 段数据部分不超过 1460 字节。
  • 主机 B 回应 SYN-ACK 时，也会附带自己的 MSS 值（如 MSS=1420）。
• 最终值 ：双方取 较小值 作为本次连接的 MSS。例如，若一方 MSS=1460，另一方=1420，则实际使用 1420。

MSS 与 MTU 的关系

• MTU（Maximum Transmission Unit）：网络层（IP 层）单次传输的最大数据包大小（包括 IP 头部和 TCP 头部）。

• 公式：

MSS=MTU−IP 头部长度（通常 20 字节）−TCP 头部长度（通常 20 字节）

• 例如：以太网 MTU=1500 字节 → MSS=1500-20-20=1460 字节。

为什么需要 MSS

• 避免 IP 分片 ：
  • 如果 TCP 段数据过大（超过路径中最小 MTU），IP 层会分片传输，增加丢包和重组开销。
  • MSS 确保 TCP 段大小适配网络路径的最小 MTU，减少分片。
• 提高传输效率 ：
  • 过小的 MSS 会增加头部开销（头部占比高），降低有效数据传输率。
  • 过大的 MSS 可能因丢包导致重传大量数据，降低效率。

例如跨网络通信场景中，客户端通过 Wi-Fi（MTU=1500）连接路由器，再通过 PPPoE 拨号上网（MTU=1492）。此时 MSS 会协商为 1452（1492-40）；高延迟网络（如卫星链路）可能使用更大的 MSS 以减少往返次数。

MSS的协商与约束

• MSS的协商机制 ：TCP通过三次握手协商MSS。客户端在SYN包中声明自己的MSS（如1460），服务器在SYN-ACK中声明自己的MSS（如1470）。最终双方应使用较小的MSS值（即1460）作为实际传输的段大小上限。这是RFC 879明确要求的，目的是避免分段超限。
• 超限段的合法性 ：服务器若实际发送大于1460的段（如1470），从协议角度属于违规。根据RFC，接收方有权丢弃超限段并可能发送ICMP"需要分片"消息（若路径MTU允许），或触发TCP重传机制。

操作系统与网络的容忍度

• 现代操作系统的处理 ：
  • Linux/Windows等系统 ：通常 对超限段采取容忍策略 ，不会直接丢弃，而是正常接收并处理。这是因为：
    • MSS协商是"建议值"而非严格强制约束，实际传输中可能因路径MTU、GSO/TSO硬件加速等因素动态调整段大小。
    • 网卡驱动或TCP栈可能自动处理分段（如GSO合并小包），导致实际发送的段大于协商的MSS。
  • 例外情况：若超限段导致IP层分片（如路径MTU小于1470+IP头+TCP头），且DF位（不分片标志）被设置，路由器会丢弃包并返回ICMP"需要分片"错误，触发TCP的PMTU发现机制，最终可能缩小段大小。
• 网络设备的干预 ：
  • 防火墙、负载均衡器等中间设备可能基于安全策略（如严格匹配MSS）丢弃超限段，但这种情况较少见。

所以有些项目中，应用层发送大MSS的TCP包（超过MTU）时，通过内核IP层分片以提高吞吐量，即可通过牺牲分片开销换取传输层效率提升。

分片与吞吐量的权衡

1. 分片机制的作用
   • 当TCP段的MSS超过路径MTU时，IP层会将数据包分片为多个小包传输。每个分片独立封装IP头（20字节），但共享原始TCP段的序列号和确认号。
   • 分片开销：若原始MSS为3000字节（MTU=1500），则需分片为3个包（1480+1480+40字节），增加2个额外IP头（40字节×2=80字节）。
2. 吞吐量提升的来源
   • 减少TCP层交互 ：大MSS减少了TCP段的数量，从而降低：
     • 确认应答（ACK）频率：接收方需发送的ACK数量减少，节省带宽。
     • 重传开销：单个段丢失时，重传的数据量更大，但大MSS下段数量少，可能减少重传次数（若丢包率低）。
   • 传输层效率 ：TCP协议头（20字节）占整体数据包的比例降低。例如：
     • MSS=1460时，头占比=20/(1460+20)=1.35%；
     • MSS=3000时，头占比=20/(3000+20)=0.66%。

分片带来的负面影响

1. 分片丢失的灾难性后果
   • 若任一分片丢失，整个原始TCP段需重传（因TCP重组依赖所有分片）。例如：
     • 3个分片中丢失1个，需重传3000字节（而非仅丢失的1480字节），导致带宽浪费。
   • 丢包率敏感：在高丢包率网络中，分片策略会显著降低吞吐量。
2. 中间设备处理瓶颈
   • 防火墙/NAT：部分设备可能丢弃分片包（因需重组后检查内容，消耗资源）。
   • 路由器分片队列：分片可能被不同队列处理，导致乱序到达，增加接收方重组延迟。
3. PMTU发现失效
   • 若路径中存在MTU较小的链路（如VPN隧道），且未启用PMTU发现，持续分片会导致：
     • ICMP不可达消息被丢弃：防火墙可能拦截ICMP Type 3 Code 4消息，使发送方无法感知路径MTU变化。
     • 黑洞路由：数据包因分片超限被静默丢弃，连接中断。

具体怎么使用，还是结合实际情况为妙。