换了件还是慢：一次 OTA 下载速度慢问题的排查复盘

一台车 OTA 下载只有 200 KB/s 出头，同批次的其他车能跑满限速。ICM（车机）换过，IDM（智驾域控）也换过，问题照旧。最后是 iperf3 的一次反向压测把方向定了下来——根因在硬件，而排查的价值在于把范围缩到硬件同事能直接接手的地方。

一、现象

去年 12 月，项目里的一台车（下称 A 车）报 OTA 下载慢。慢到什么程度：3 GB 左右的升级包，正常车半小时能下完，它要接近四个小时。抓包看速率是 1.75 Mbps，也就是 200 KB/s 出头；链路限速是 15 Mbps，正常车基本能跑满。

下载链路是这样的：

先把几个设备交代清楚，后面会反复出现：

ICM：车机，座舱侧的主机，负责车内交互和业务，同时也是这台车上连接外部网络的中间节点。
IDM：域控制器，基于 J6 芯片，OTA 客户端就装在上面，是下载的发起方。
Tbox：车载通信模块，负责与云端建立连接，是车辆对外网络的门户。

下载时数据从云端经 Tbox 到 ICM，再由 ICM 转发给 IDM。有一点得先记住：在这条流里 IDM 是收数据的一方，ICM 是发数据的一方。后面所有指标都要按这个方向读，读反了会得出完全不同的结论。

这台车有三个特征：

同样的软件装在别的车上正常；
同批次硬件，只有两三台车有问题；
问题车上必现，不是偶发。

三条凑在一起挺矛盾。软件不像，批量硬件也不像，那只能是个别车的个别环节。当时没人往"整批硬件都有问题、只是这几台车把问题暴露了出来"这个方向想。

二、第一轮：能排的都排了

一开始都是常规动作：刷不同软件版本、分别用限速和非限速端口下载、绕开 OTA 应用直接用 curl / wget 下、讨论防火墙白名单，最后换件。

动作	结果
刷不同软件版本	仍复现
限速端口 / 非限速端口分别测	都慢
在 ICM 上本地下载 OTA 包	正常
curl / wget 绕过 OTA 应用直连下载	仍慢
清空 nftables 规则、排查白名单	不是配置问题
换一颗 ICM	仍复现
换一颗 IDM	仍复现

做完这些，该排的都排了，问题还在，方向没了。

这张表里有两条信息后来最有用。一条是 ICM 本地下载正常——它说明云端到 ICM 这一段是好的，问题只可能出在 ICM 到 IDM 这一跳。另一条是换件复现，当时被我们顺手当成了"不是硬件问题"的证据，正好用反了。这两条放到后面说。

三、抓包：先定方向，再看指标

12 月 15 日，在 IDM 和 ICM 两侧同时抓下载流量。A 车和一台正常车（下称 B 车）对比如下：

指标	IDM 侧（收方）	ICM 侧（发方）	B 车
速率	1750 kbps	1807 kbps	15 Mbps
重传率	3.74%	9.15%	0.23%
重复 ACK	0%	8.17%	—
乱序率	14.3%	0%	—

这组数据能看出几件事。

第一，速率差了一个数量级。B 车跑到 15 Mbps，基本贴着限速；A 车 1.75 Mbps，连八分之一都不到。这不是"稍微慢点"，是 TCP 已经被丢包拖垮了。

第二，两侧的异常其实是同一件事。IDM 侧乱序 14.3%，因为它收到的段不连续；ICM 侧重复 ACK 8.17%，因为 IDM 在反复催同一段。链条是：IDM 收到乱序段，回重复 ACK，ICM 统计到重复 ACK，触发重传 9.15%。三个数字串起来是一个循环，不是三个毛病。如果分开查，严重程度还会被重复算一遍。

第三，B 车的重传率只有 0.23%，说明链路健康的时候是干净的。不能说"车载以太网本来就这样"。

到这里可以确定：不是应用层，不是端口配置，是 ICM → IDM 方向在持续丢包。

四、iperf3：一次压测把范围砍掉一半

抓包能证明丢包，但说不清丢在哪、往哪个方向丢。12 月中做双向压测，是整件事的转折点。

结果很干脆：

方向 / 协议	结果
IDM → ICM（TCP）	932~948 Mbps，Retr = 0
ICM → IDM（TCP）	3~8 Mbps
ICM → IDM（UDP）	94 Mbps，丢包 4.5%~7.2%

反方向能跑满千兆、零重传，说明物理链路本身没坏，问题只出在 ICM 发出的方向。慢的方向又正好是 OTA 数据流的方向。

这里有个坑：如果只跑默认方向的 iperf3，结论会是"链路 940 Mbps，完全正常"，问题直接被误判掉。压测方向必须和业务方向对齐，否则测了等于没测。

UDP 能推到 94 Mbps，但丢 4.5%~7.2%；TCP 一遇到丢包就降速重传，吞吐掉到个位数。这也解释了为什么现象是"慢"而不是"断"——链路不是坏了，是在漏。

范围到这里从"整车网络"缩成了"ICM → IDM 这一跳，ICM 发出的方向"。

一条没走通的分支

12 月 16 日有人看 ICM 侧代理的 RTT 指标偏高，怀疑是代理慢。这个怀疑不算错，下载确实走代理。但 iperf3 是 IDM 和 ICM 直连，不经过代理，也不经过云端，照样复现单向慢。这条证据把代理排除了。

线没走通，但我们把它记了下来。排查里走弯路正常，走完不留痕才麻烦——下次有人提同样的怀疑，得从头再验证一遍。

五、网卡层：查不到错误也是信息

按分层往下看链路层：

结果是 rx_errors 这类计数没有明显增长，收发统计也正常，速率协商没问题。

当时挺困惑：抓包明明一堆丢包和重传，网卡坚持说自己没出错。后来才想明白，ethtool -S 统计的是 MAC 和驱动层的错误，物理层信号层面的误码丢帧不一定进这些计数器。计数器看不到错误，和链路上没发生错误，是两回事。

软件侧能做的到此为止。我们把结论整理成可以直接交接的材料：

方向：ICM → IDM 单向慢，反方向正常；
证据：IDM 侧乱序 14.3%，ICM 侧重复 ACK 8.17%、重传 9.15%；
复现：A 车必现，B 车正常；
已排除：软件版本、端口限速、应用层、代理、单颗 ICM、单颗 IDM。

12 月底交给供应商和硬件同事。

六、换件复现，到底排除了什么

这是整件事里最容易骗人的一步。

换件在排查里通常算强证据，潜台词是：故障跟着车走、不跟着件走，那这个件就没问题。但这个推理靠两个前提——换上去的件是确认好的，故障件的缺陷不是整批的。

这次两个前提都不成立。换 ICM 换的是同批次的 ICM，如果这一批 PHY 都有过温问题，换上去的还是个有问题的件，现象当然复现。换 IDM 则更说明不了什么：IDM 本来就不是问题所在，最多证明不是这一颗 IDM 坏了。

所以准确的说法是：换件复现排除的是个体故障，排除不了批次缺陷。 这两件事在直觉上很像，在结论上完全相反。

至于同批次硬件为什么只有两三台车出问题，这里得分清事实和推测。

事实是：供应商确认该批次 ICM 的以太网 PHY 存在过温缺陷；A 车必现；换件后仍复现。

推测是：这几台车的整车热环境或使用条件，更容易让 ICM 持续处于高温，把批次缺陷暴露出来。这个推测能解释"批次缺陷但只有少数车暴露"，但没做过失效分析，不能当结论写。

七、根因

2026 年 1 月 5 日的供应商会议确认了根因：ICM 以太网 PHY 存在过温设计缺陷，整批次都有。高温下以太网 switch 工作异常，严重时直接停止工作，导致 ICM 与外部网络通讯中断或异常。

把根因和观察到的现象接起来，链条是完整的：

两个当时看着别扭的现象也对上了。

一是为什么是慢不是断：PHY 不是彻底坏掉，是半死不活，能发但误码和丢帧率高，TCP 靠重传勉强撑着。

二是为什么 ethtool 查不出错误：丢帧发生在物理层信号层面，MAC 层的计数器不一定感知得到。

"过温主要影响发送方向"这一点和 iperf3 的单向结果吻合，但具体的失效机理还是以供应商的失效分析为准。我们确认的事实只有两条：单向慢，以及 PHY 过温缺陷。

八、复盘

这次前后拖了一个多月，而真正定方向的那个动作——反向 iperf3——只花了十分钟。几件事值得记下来。

双向压测应该第一个做。 遇到"某条链路慢"，先跑 iperf3 -R 和 UDP 丢包，加起来不到半小时，就能把范围砍掉一半：是整条链路慢还是单方向慢，是断了还是在丢包。我们把它排在抓包、换件、排查配置之后，绕了将近一个月。顺序错了，成本是数量级的差别。

每个排除项都要写清楚它排除了什么。 curl 排除的是应用层，不是网络层；换件排除的是个体故障，不是批次缺陷；ICM 本地下载正常，排除的是云端到 ICM，把范围压到 ICM 到 IDM。排查表如果只写"已排除"、不写前提，后面的判断很容易被误用。这次"换件复现"被当成"不是硬件"，就是范围用错了。

抓包先写一句数据从谁发往谁。 同一段丢包，发送端看到的是重复 ACK 和重传，接收端看到的是乱序。不先确定方向，很容易把一件事算成三个问题，越查越乱。

换件实验要设计干净的对照。 至少确认替换件的批次、它在别的车上是否验证正常、故障件换到别的车上是否复现。只做"换上去看看"，结论可能正好反过来。

软件团队的价值，不一定是找到最终根因。 根因在 PHY，超出了软件手段能到的地方。但把问题从"OTA 下载慢"缩到"ICM → IDM 单向丢帧"，并附上证据和已排除项，供应商拿到就能直接奔着 PHY 和热设计去查。能把问题收敛到可交接的最小范围，本身就是排查能力的一部分。

九、时间线

时间	动作	结果
11 月底	讨论端口白名单和防火墙	排除端口配置
12 月 15 日	IDM、ICM 两侧 tcpdump	发现重传和乱序异常
12 月 16 日	curl 复现，怀疑代理	排除应用层，代理待验证
12 月中	iperf3 双向压测	定位 ICM → IDM 单向慢
12 月中下	ethtool / ip 查网卡错误	无异常，软件手段用尽
12 月底	整理证据，交接供应商	交付单向丢帧结论
1 月 5 日	供应商会议	确认 PHY 过温缺陷

十、附：本次用到的命令

写在最后

这次最深的体会不是某个工具怎么用，而是排查里最危险的往往不是"没查到"，而是"查到了一个看起来对的错误结论"。

"换了件还复现，所以不是硬件"，这个推理在大多数场景下成立，所以几乎没人去质疑它。最后把它推翻的，是 iperf3 一条简单到不能再简单的证据：只有一个方向慢，而慢的方向正好是业务数据的方向。

如果重来一次，我会在第一天就做三件事：确认业务流方向、跑一次反向 iperf3、把"ICM 本地下载正常"这条线索单独拎出来。这三步不需要任何额外条件，能把一个月的排查压到一周以内。

根因在硬件。但排查做到这一步，才算把该我们做的部分做完了。