首页/网络/协议速查/MSS 协商与 TCP 分段
TCP 与 UDP54 条

MSS 协商与 TCP 分段

MSS 是单个 TCP 段的最大数据长度,握手时双方各报自己的 MSS(典型 1460 = 1500 MTU - 20 IP - 20 TCP)。

协议速查网络更新于 2026-10-13

MSS 是什么

MSS(最大报文段长度)是单个 TCP 段里能装的最大数据字节数,不含 TCP 与 IP 头。双方在握手的 SYN 与 SYN+ACK 里各报自己的 MSS,实际发送时取两个值中较小的一个。它的意义在于让 TCP 主动把数据分成路径能通过的尺寸,从而避免交给 IP 层分片——IP 分片只要丢一片就要重传整个数据报,代价高得多。

基本信息

协商方式SYN / SYN+ACK 中的 MSS 选项,取双方较小值
典型取值以太网默认 1460 = 1500 MTU − 20 IP 头 − 20 TCP 头
无选项默认IPv4 为 536 字节,IPv6 为 1220 字节
相关机制PMTUD 负责发现路径 MTU,MSS 随之下调
调整手段两端网卡 MTU、路由器 MSS clamp、tcp_mtu_probing 兜底

典型使用场景

  • 排查「能 ping 通但大页面打不开」:MSS 与路径 MTU 不匹配是首要怀疑对象
  • 部署 IPsec、GRE、VXLAN 隧道前,计算外层封装开销并下调内层 MTU
  • 检查实际生效的 MSS,确认中间设备是否悄悄做了 clamp
  • 验证抓包中 SYN 包是否携带 MSS 选项,判断对端实现是否精简
  • 跨运营商链路出现大量重传时,确认是否因路径 MTU 更小导致大段频繁丢失
  • 容器或 Overlay 网络下排查吞吐异常,确认 veth 与隧道设备的 MTU 是否被统一调整
  • 核对负载均衡健康检查大包超时的原因,判断是否被中间设备按 MTU 丢弃

最小示例

最小示例
ss -tin | grep -i mss                       # 看已建立连接的 MSS
ip link show eth0 | grep mtu                # 查看网卡本地 MTU
tcpdump -nn -v 'tcp[tcpflags] & tcp-syn != 0' -c 2 | grep -i mss  # 抓握手看协商值
ip link set eth0 mtu 1400                   # 下调本地 MTU 适配隧道
sysctl net.ipv4.tcp_mtu_probing             # 0 关闭,1 仅在黑洞时探测,2 始终探测
sysctl -w net.ipv4.route.min_pmtu=1400      # 让内核不缓存过小的 PMTU

常见 MTU 与 MSS 对照

链路类型典型 MTU对应 MSS
标准以太网15001460
PPPoE 拨号14921452
GRE 隧道1476 或更低1436
IPsec 隧道模式约 1400约 1360
IPv6 最小要求12801220
VXLAN Overlay1450 左右1410 左右
临时验证可以把网卡 MTU 调小(例如 1400)再测大包是否通:如果立刻恢复正常,就能确认问题出在路径 MTU 而不是应用。
MSS 只在握手时协商一次。链路中间若出现更小的 MTU,只能靠 PMTUD 反馈或中间设备的 MSS clamp 修正,因此隧道两端都下调 MTU 才是稳妥做法。

易错点

  • 隧道场景不调内层 MTU:小包正常、大包静默丢弃,表现为「网页打不开但 ping 通」,且抓包看不到任何拒绝信息
  • 只看本机 MTU 就断定没问题:路径上任何一跳的 MTU 都可能更小,必须用 DF 置位的大包实测
  • 依赖 MSS clamp 当成根治手段:它只对 TCP 生效,UDP、QUIC 等流量依然会被黑洞吞掉
  • 两端 MTU 不一致(一端 1500 一端 1400):大包方向性失败,容易出现「下载正常、上传卡死」这类难排查现象

数据来源与参考

  • RFC 9293 §3.7.1
  • RFC 6691(MSS 计算)

相关工具

​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌