把 2% 丢包、120ms 抖动变成可控实验：用 tc netem 在本地复现线上网络故障，验证降级与熔断到底有没有用

作者视角：15 年网络工程，长期盯系统稳定性与可观测性。这篇文章不教你「怎么排查网络」，而是讲一个更被低估的能力——在你自己机器上把「网络坏了」这件事精确地造出来，用来验证你的超时、熔断、降级、重连逻辑是不是真的按设计工作。全文给可复现的 tc 命令、参数预算和一张故障矩阵。

一、现象与背景：降级代码写了三年，从没被真实触发过

先摆数字。我们一组 32 个 Java 微服务，Nginx 网关 4 台，跨机房 RTT 基线 4.2ms，核心链路峰值 QPS 约 6800。每个服务都写了「下游超时 800ms → 熔断 → 走降级返回兜底数据」的逻辑，代码评审也过了。

但直到去年一次真实的机房上联抖动（持续约 9 分钟），我们才发现这套逻辑从没跑通过：

• 业务 P99 从基线 60ms 飙到 8.7s，持续 6 分钟；
• 熔断器 3 分钟内跳闸 214 次，half-open 探测用了 31s 才放回，远超我们 SLO 里写的「5s 内恢复」；
• 更糟的是，降级返回的兜底数据里有 3 个服务读的是本地缓存，缓存 40 分钟没刷新，等于给用户返回了 40 分钟前的价格。

复盘时一句话点醒我们：我们验证过「网络好时功能对」，但从来没验证过「网络坏时行为对」。降级、熔断、重连这些代码平时不跑，等于一直在腐化。问题不是「没有容错」，而是「容错从未被压测」。而线上故障你没法主动制造、没法复现、没法回滚——这正是我接下来要用 tc netem 解决的。

二、原理：为什么 ping / iperf 都正常，你却测不出真实风险

要理解「为什么需要故障注入」，得先理解「为什么常规测试会骗人」。

1）丢包会被内核指数放大，而不是线性放大。 哪怕链路只有 2% 丢包，ping P99 可能还是 5ms、iperf3 还能跑 9Gbps，值班同学会说「网络没问题」。但内核的 RTO 是指数退避的（Jacobson 算法，tcp_rto_min 默认 100ms，每次超时 RTO 翻倍），2% 丢包完全能把 P99 打到 10 秒级——这不是「网络慢」，是内核在替你重试。所以应用超时如果设成 800ms，而内核退避到第 3 次要 1.6s 起步，你等的其实是内核，不是响应。

2）带宽打满 ≠ 延迟正常，队列才是元凶。 发送端把接收端缓冲灌满，队列越积越长，RTT 能从 5ms 涨到 480ms，而丢包率是 0——ping、iperf 的带宽测试全「正常」，只有 P99 在尖叫。这类 bufferbloat 用「跑满带宽」是复现不出来的，你得精确地控制丢包率、时延、抖动，而不是粗暴地打满。

3）真实链路故障是「相关性」的，不是独立伯努利的。 现实里丢包是成簇出现的（bursty），一个坏帧后面往往跟着几个坏帧；重排序、时延是带分布的（均值 + 方差），不是固定值。如果你只写 netem loss 2%，你造的是一个「每包独立 2% 概率丢」的理想模型，它低估了真实链路的冲击，也会高估某些重试逻辑的恢复速度。

tc netem 的价值，就是让你把上面这三件事参数化、可复现、可回滚地在本地复现——它工作在网卡 qdisc 层，能精确模拟 loss / delay / reorder / corrupt / duplicate / 抖动分布，而不需要真的去拉断一根光纤。

三、具体做法：可复现的 netem 注入与验证脚本

以下在 Linux（kernel 5.15 / iproute2 5.15.0）上验证过。核心原则：只对自己、只对自己那条链路、随时可回滚。

1）最简注入：2% 丢包 + 120ms 均值 / 40ms 方差的时延

# 在出向 qdisc 挂 netem（root 需要 sudo）
sudo tc qdisc add dev eth0 root netem \
    loss 2% \
    delay 120ms 40ms distribution normal

# 验证已生效
tc -s qdisc show dev eth0
# 一键回滚（记住这条，演练结束必跑）
sudo tc qdisc del dev eth0 root

distribution normal 让时延按正态分布抖动，比固定 delay 120ms 更接近真实链路。

2）逼近真实故障的完整注入（含相关性 + 重排序）

sudo tc qdisc add dev eth0 root netem \
    delay 120ms 60ms distribution normal \
    loss 2% correlation 25 \
    reorder 25% gap 30% \
    corrupt 0.5% \
    duplicate 1%

• correlation 25：让丢包成簇出现（每 25 个包左右一个坏帧带一串），复现 bursty 丢包；
• reorder 25% gap 30%：30% 的包被重排、平均错 25 个包——这是 TCP 乱序、快恢复被触发的真实诱因；
• corrupt / duplicate：复现 CRC 错、重复 ACK。

3）只打某个应用 / 某个目的，别污染整机（关键安全做法） 用 cgroup2 net_cls 把 netem 限定到指定进程，而不是全网卡：

# 建 cgroup 并把目标服务放进去（net_cls 只对 TCP 生效）
sudo cgcreate -g net_cls:/drill
echo 0x00100001 | sudo tee /sys/fs/cgroup/net_cls/drill/net_cls.classid >/dev/null
echo <pid> | sudo tee /sys/fs/cgroup/net_cls/drill/cgroup.procs >/dev/null

# 用 tc filter 把 classid 路由到一条 netem 链
sudo tc qdisc add dev eth0 root handle 1: htb default 10
sudo tc class add dev eth0 parent 1: classid 1:10 htb rate 10gbit
sudo tc qdisc add dev eth0 parent 1:10 handle 10: netem loss 2% delay 120ms 40ms distribution normal
sudo tc filter add dev eth0 parent 1: protocol ip u32 \
    match "ip src 0.0.0.0/0" flowid 1:10  # 配合 cgroup 命中目标进程

注意：cgroup classid 的高位段要落在 0xffff 约定区间，且 net_cls 只影响 TCP，UDP/QUIC 不走这条路——演练时别以为「全打上了」。

4）CI / 演练里跑：定时 + 自动回滚，绝不留尾巴

#!/usr/bin/env bash
set -euo pipefail
DEV=eth0
DRILL_SECONDS="${1:-180}"
sudo tc qdisc add dev "$DEV" root netem loss 2% delay 120ms 40ms distribution normal
echo "drill start: $(date -Is)"
# 后台到期自动回滚，防止脚本中途崩了网还挂着
( sleep "$DRILL_SECONDS"; sudo tc qdisc del dev "$DEV" root ) &
trap 'sudo tc qdisc del dev "$DEV" root' EXIT
# 期间跑你的验收：
./run_acceptance_suite.sh   # 期望：P99<800ms 走熔断，兜底数据新鲜度<60s

把「到期自动 tc qdisc del」放进后台子进程，是防止一次演练把测试机网搞挂后忘了回滚的保命措施。

5）验证时看什么（可观测性埋点）

• nstat -az | grep -E 'TcpRetransSeg|TcpTimeouts|TcpInErrs'：重传、超时、错误的增量；
• ss -ti dst <对端IP>：看单条连接的 rto、retrans、cwnd 实时值；
• 应用侧：熔断跳闸次数、half-open 恢复到放回的耗时、兜底数据的新鲜度时间戳——这三项才是降级「真的有用」的证据。

四、踩过的坑 / 反直觉之处

1. tc 规则不持久化，重启即失效。 qdisc 挂在运行时内存里，机器一重启就没了。想常驻演练环境，要写成 systemd 服务或交给 systemd-networkd 的 .netdev/.network 管，别指望它跨重启。
2. netem loss 2% 是「每包独立伯努利」，会低估真实冲击。 真实丢包是相关性的，务必加 correlation，否则你的熔断恢复时间会被高估、兜底逻辑会被「假性验证通过」。
3. 只测了「网络慢」，没测「网络断」，是最常见的漏项。 慢链路会触发超时；但「断链 + 半开连接」会留下僵尸连接——Linux 默认 tcp_keepalive_time=1800s，NAT 空闲超时 300s、LB idle 120s 之下，这些死连接能赖在连接池里 40 分钟。断连演练要直接 tc qdisc add ... netem loss 100%，看你的连接池能不能在 NAT 超时前把死连接踢掉。
4. 别在生产网关上直接挂 netem。 正确姿势是「旁路镜像 + 影子链路」：把镜像流量引到一台演练机，在那台机器上注入，观察影子服务的行为，生产链路不受影响。
5. delay 是加在 qdisc 出向的，别把它当成「RTT」。netem 的 delay 是单向排队延迟，一次 RTT 是去 + 回两段；你加 120ms 单向，端到端 RTT 增加的是约 240ms（往返都要过这段），换算 SLO 时别只算一头。

五、结论与可复用清单

结论： 网络相关的容错代码（超时 / 熔断 / 降级 / 重连 / 连接池驱逐）不是「写了就算对」，而是必须在受控、可复现、可回滚的坏网络下被真实触发过一次才算验证。tc netem 就是这个「坏网络」的开关——它让你把线上 9 分钟的灾难，压缩成本地 180 秒、随时可回滚的实验。

故障矩阵（建议每次发版前过一遍，每项都有期望行为 + 验证命令）：

| 注入 | netem 参数 | 期望行为 | 验证 | |---|---|---|---| | 轻丢包 | loss 2% correlation 25 | P99 仍 < SLO，或走熔断 | nstat 重传增量 + 熔断计数 | | 高时延抖动 | delay 120ms 60ms distribution normal | 触发超时降级，兜底新鲜度 <60s | 兜底数据时间戳 | | 重排序 | reorder 25% gap 30% | 快恢复生效，无大面积 RTO | ss -ti 的 rto/retrans | | 完全断连 | loss 100% | NAT 超时前驱逐死连接 | 连接池 ESTAB 数 + keepalive | | 慢恢复 | delay 800ms 300ms distribution normal | 熔断 half-open 恢复 <5s | half-open 到放回耗时 |

可复用清单：

1. 把「降级/熔断/重连」纳入发版验收单，判据是坏网络下的行为，不是好网络下的功能；
2. 注入必带 distribution normal 与 correlation，别用固定值 / 独立伯努利建模真实链路；
3. 用 cgroup net_cls + tc filter 把注入限定到目标进程，别污染整机；
4. 演练脚本必须「到期自动回滚 + trap EXIT 兜底」，防止 netem 残留；
5. 断连场景单列，专门验证僵尸连接驱逐，别只测「慢」；
6. 生产侧用「旁路镜像 + 影子链路」注入，绝不在生产网关上直接挂 netem。

参考：内核重传退避把 2% 丢包放大成 12s 的机制、以及「带宽打满但 P99 在尖叫」的 bufferbloat 案例，我在这两篇里都读到过，本文的「为什么常规测试会骗人」一节即受其启发。