摘要

  • Tobias Fiebig 在 RIPE 93 讲的慢速下载，起初像是接入网络限流。服务器放行相关 ICMP 后问题依旧；抓包与虚拟机对照才揭出两块虚拟网卡并不一样。
  • 故障 VM 的 RTL8139 TCP offload 固守 1500 字节，路由查询却已发现路径只有 1420。把更具体路由锁到 1320 后，传输恢复。

分析

一次大文件下载慢到足以让人怀疑运营商。可包不会写投诉信：Tobias Fiebig 在 RIPE 93 展示的抓包，最后把调查带进了虚拟机内部，指向一块老式网卡的仿真实现。

出问题的传输只在较小 MTU 的路径上磨蹭。附近另一台虚拟机却能正常工作，于是接入网络看起来像嫌疑人。服务器端还检查了 ICMP，防火墙规则也允许“packet too big”这类反馈。改完之后，吞吐仍旧慢。防火墙确实改了，只是它不是这条故障链的终点。

Fiebig 在客户端查路由，得到的路径 MTU 是 1420 字节。主机已经知道路径比本地 1500 字节接口窄。按理，路径上的设备发回“包太大”信号，发送端便该缩小数据包。可 TCP 仍不断重传。Fiebig 又加了一条更具体的路由，把 MTU 锁到 1320，下载随即恢复。这里有两个不同的数字：1420 是路由查询测出的路径值；1320 是现场有效的绕行设置，不是路径测量结果。

复现实验反而一度把人带错方向。新建虚拟机，装同一套软件，发送同一个测试包，问题消失。再看虚拟硬件，差别才出现：故障客体使用 QEMU 仿真的 Realtek RTL8139，测试客体使用另一种虚拟网卡。软件看起来一样，网络接口却不一样；复现不出来，是因为复现漏了真正的变量。

Fiebig 沿代码追到 QEMU 的 net/hw/8139.c，找到 TCP offload 使用固定 1500 字节 MTU 的处理。QEMU 官方问题记录也描述了这条故障链：客户端路径低于 1500 时吞吐下降、PMTUD 被忽略、出现重传，降低客体 MTU 可缓解。Fiebig 在演讲中说相关代码可追溯到 2006 年，并提到 2016 年已有讨论和补丁提议。他列出的处理办法还包括关闭 TCP offload；该案例最终换成 VirtIO，故障随之消失。

路径 MTU 发现的任务，是让端点适应路径上最窄的一段。RFC 1191写明 IPv4 的路径发现机制；RFC 2923记录了 TCP 在 ICMP 反馈缺失或处理不当时遇到的黑洞。这解释了为什么防火墙最先被怀疑。直到放行规则没有改变结果，调查才必须继续追到客体网卡。

这次排错最有价值的顺序，是先抓到实际包，再核对路由学到的 MTU、虚拟网卡型号和 offload 状态。公开材料没有给出故障客体的 QEMU 精确版本和 offload 配置；这两项能改变我们对同类部署规模的判断。

来源

RIPE 93 闭幕全会文字记录；QEMU 问题 1312；RFC 1191；RFC 2923；TU Wien 的 Tobias Fiebig 个人页; RIPE 93 场次页面。