3、根因分析（上）：网络层问题（丢包、延迟、乱序）

好，咱们进入正题。重传风暴的根因，十有八九出在网络层。你想想看，TCP 重传的本质是什么？是发送方没收到确认，或者确认来得太晚。那为什么收不到确认？说白了，就是网络层出了问题。

我个人习惯，排查重传风暴时，先看网络层。为什么？因为应用层和传输层的问题，往往只是表象。网络层才是真正的“战场”。今天咱们就聊聊网络层的三大“杀手”：丢包、延迟、乱序。

3.1 丢包：最直接的“导火索”

丢包，就是数据包在传输过程中“消失”了。发送方没收到 ACK，自然就会重传。我在项目中遇到过最夸张的一次，丢包率高达 15%，整个业务几乎瘫痪。

丢包的原因，我总结了一下，主要有这么几个：

• 物理层问题： 网线老化、光模块故障、电磁干扰。嗯，这些听起来很“低级”，但确实最常见。我记得有一次，一个机房的交换机端口频繁丢包，最后发现是网线水晶头接触不良。
• 链路层问题： 交换机 MAC 地址表溢出、STP 收敛、环路。环路会导致广播风暴，直接打满链路。
• 网络层问题： 路由器路由表错误、ACL 过滤、MTU 不匹配。MTU 不匹配会导致分片，分片丢失会触发整个报文重传。
• 设备性能问题： 路由器/交换机 CPU 过载、内存不足、队列溢出。说白了，设备处理不过来，只能丢包。

3.2 延迟：重传的“催化剂”

延迟，就是数据包在网络上“磨蹭”的时间太长。TCP 有超时重传机制，如果 RTO（超时重传时间）到了还没收到 ACK，就会触发重传。延迟高了，RTO 也会跟着变高，但一旦延迟抖动超过 RTO，重传就来了。

延迟的来源，我列个表，大家看得更清楚：

你想想看，排队延迟是最“狡猾”的。它忽高忽低，导致 RTT（往返时间）剧烈抖动。TCP 的 RTO 计算虽然会考虑抖动，但总有“跟不上”的时候。一旦 RTT 突然飙升，RTO 还没更新，就会触发虚假重传。

3.3 乱序：被忽视的“帮凶”

乱序，就是数据包到达接收方的顺序，跟发送顺序不一致。TCP 接收方收到乱序包，会触发快速重传机制（发送重复 ACK）。

乱序的原因，我总结了一下：

• 多路径转发： ECMP（等价多路径）将同一个流的报文分发到不同路径，路径延迟不同，导致乱序。
• 链路聚合： 类似 ECMP，不同成员链路延迟不同。
• 设备内部处理： 多核 CPU 处理、不同队列调度，都可能导致乱序。
• 重传本身： 重传的报文可能走不同路径，反而加剧乱序。

乱序的危害，很多人低估了。3 个重复 ACK 就会触发快速重传，而快速重传又会发送新的数据包，进一步加剧乱序。这是一个典型的“正反馈”循环。

3.4 知识体系：网络层问题全景图

下面这张图，是我自己梳理的网络层问题全景图。它把丢包、延迟、乱序的根因、影响和关联关系都串起来了。你排查问题时，可以对照着看。

3.5 实战排查思路

说了这么多理论，咱们来点实际的。遇到重传风暴，怎么快速定位是网络层的问题？

1. 抓包分析： 在发送方和接收方同时抓包。看是否有重复的 ACK、超时重传的报文。这是最直接的方法。
2. 检查丢包率： 用 ping 或 mtr 工具，看中间节点的丢包情况。重点关注“突发性”丢包。
3. 测量延迟和抖动： 用 ping -f 或 iperf 测试 RTT 和抖动。如果抖动超过 RTO 的 1/4，就要警惕了。
4. 检查乱序： 在抓包文件中，看 TCP 序列号是否连续。如果出现大量乱序包，检查 ECMP 或链路聚合配置。
5. 查看设备日志： 检查路由器/交换机的 CPU、内存、队列丢弃计数。这些指标能直接反映设备是否“扛不住”了。