直接回答：MTU 是链路层单帧最大载荷（以太网 1500），MSS 是 TCP 声明的“我收的单段最大载荷”（= MTU - IP 头 20 - TCP 头 20，通常 1460），握手时双方取小。PMTUD（路径 MTU 发现）发 DF=1 的包探路径最小 MTU，靠 ICMP Fragmentation Needed 反馈收缩——ICMP 被防火墙误杀时发送方永远不知道要缩，大包全丢小包正常，症状就是“握手能成、网页能开一半、大文件传不动”。
展开解析：经典故障现场：PPPoE 拨号（MTU 1492，8 字节头）、VPN/IPsec/GRE 隧道（再剥几十字节）、云 VPC 的隧道封装（MTU 常 1450 或更小）——出口 MTU 1500 而隧道内实际 1400，没配 MSS clamping 就踩雷。排查路径：ping -f -l 阶梯测大包通不通（Windows -f 禁分片，Linux ping -M do -s）、traceroute --mtu 探测、抓包看大包是否只有去没有回。修复手段三层：MSS clamping（边界路由器把 SYN 里的 MSS 改小到安全值，最常用——iptables TCPMSS 或云厂商网关配置）；正确放行 ICMP type 3 code 4（别再把 ICMP 一刀切，PMTUD blackhole 的自作自受）；应用层兜底（分段下载、控制单次写入大小）。IPv6 的差异要记住：IPv6 没有路由器分片，只能源端分片，ICMPv6 Packet Too Big 是硬依赖，杀 ICMPv6 必炸。云服务实战：跨 VPC peering、专线接入、K8s overlay（VXLAN 减 50 字节）场景都要主动核对 MTU——overlay 网络 MTU 错配是容器网络“玄学丢包”的高发根因。收束口诀：MTU 是链路属性、MSS 是 TCP 属性、PMTUD 是发现机制、blackhole 是配置事故。
追问方向：为什么 UDP 没有 MSS 概念却更受 MTU 影响（DNS 切 TCP、QUIC 的 DPLPMTUD）？分片与重组的性能代价？
（约 500 字）