真实世界中的 PMTUD
内容提要
本文讨论了在MSS协商失败的情况下，为什么curl https://x.com可以访问，但是curl https://accounts.google.com不可以。作者通过实验发现，这些网站可能实现了PMTUD（Path MTU Discovery），即在TCP握手时根据本地网卡信息协商MSS。作者还尝试了在虚拟机中模拟MTU最大为800的环境，并通过iptables丢弃超过800字节的包。实验结果显示，对于accounts.google.com，服务器一直尝试发送大小为1400的包，但被丢弃并重发，最终发送成功。作者还尝试了发送ICMP消息，但结果与之前相同。作者推测可能是公网发送ICMP消息的问题。
延伸解读
PMTUD 的实际行为差异
文章通过抓包对比了不同网站的 PMTUD 行为。x.com 在丢包后从 512 字节开始尝试，逐步增大到 936 字节，失败后退回；facebook.com 首次尝试 1024 字节，失败后退到 512；而 accounts.google.com 则一直重发 1400 字节的大包，没有主动减小包大小。这表明不同服务端对 PMTUD 的实现策略存在差异，有的能较快适应链路 MTU，有的则依赖 ICMP 反馈。
ICMP 黑洞对 PMTUD 的影响
作者在虚拟机中发送 ICMP type 3 code 4 消息，但 accounts.google.com 并未据此调整包大小，仍从 512 字节开始尝试。而在本地简单网络环境中，服务端收到 ICMP 后立即改用 800 字节发送。这暗示公网中 ICMP 消息可能被丢弃或路由到错误的设备，导致 PMTUD 失败。Cloudflare 的文章也提到 ECMP 可能导致 ICMP 被错误路由，需广播到所有负载均衡器。
实验环境搭建的关键点
为了模拟 MTU 限制，作者使用 iptables 丢弃超过 800 字节的包，并关闭网卡的 TSO、GSO、GRO 等 offload 功能，避免网卡合并小包导致误丢。这些步骤对于准确复现 PMTUD 行为至关重要。此外，使用 scapy 发送 ICMP 消息时，filter 设置为 greater 815 是因为 libpcap 的 greater 基于 Ethernet 层大小，需加上 14 字节的以太网头。
Q&A
为什么在MSS协商失败时，curl https://x.com可以访问，但curl https://accounts.google.com不可以？
因为x.com实现了PMTUD（路径MTU发现），当发送的大包被丢弃后，会尝试发送小包以探测链路MTU，从而成功通信；而accounts.google.com没有实现PMTUD，一直尝试发送大包，导致连接失败。
PMTUD是什么？它的工作原理是什么？
PMTUD（Path MTU Discovery）是一种用于发现路径上最小MTU的机制。其原理是：当发送的包因过大被丢弃时，发送方会尝试发送更小的包，如果收到ACK，则说明链路MTU较小，后续就使用较小的包发送。
如何通过实验验证PMTUD的行为？
可以在虚拟机中设置iptables规则丢弃超过800字节的包，并关闭网卡的GRO等offload功能，然后使用tcpdump抓包观察。例如，对accounts.google.com发起请求，可以看到服务器反复发送1400字节的包被丢弃，最终发送小包成功。
在PMTUD实验中，为什么需要关闭网卡的offload功能？
因为如果不关闭GRO等offload功能，网卡可能会将收到的小包合并成大包，导致被iptables规则丢弃，从而干扰实验结果的准确性。
ICMP type 3 code 4消息在PMTUD中起什么作用？
ICMP type 3 code 4表示“需要分片但设置了DF位”，用于通知发送方包过大，需要减小包尺寸。在PMTUD中，中间设备通过发送此消息来告知发送方链路的MTU。
为什么在公网发送ICMP消息可能无法帮助PMTUD？
因为公网可能存在ICMP黑洞问题，即ICMP消息被丢弃或无法正确路由到发送方。例如，由于ECMP，ICMP消息可能被路由到错误的负载均衡器，导致发送方无法收到，从而PMTUD失败。
不同网站（如x.com、accounts.google.com、facebook.com）的PMTUD行为有何差异？
x.com在发送大包被丢弃后，会尝试发送512字节的小包，然后逐步增大到936字节，失败后再退回512字节，最终成功；accounts.google.com则一直尝试发送1400字节的包，不减小尺寸；facebook.com第一次尝试1024字节，然后退到512字节。
