带宽 100% 跑满、丢包却是 0：用 fq_codel 把排队延迟从 480ms 压回 25ms 的一次实战

结论先行：很多「网络变慢」根本不是丢包、不是带宽不够、更不是链路断了，而是发送侧把接收侧的缓冲灌满了——队列越积越长，RTT 从 5ms 涨到 480ms，丢包率却是 0。这类故障在 ping、iperf 的带宽测试里全都「正常」，只有 P99 延迟在尖叫。解法不是买更粗的带宽，而是把发送端的队列深度限制住：用 fq_codel 替代默认 pfifo_fast，把目标延迟锁在 5ms，实测 P99 从 480ms 回到 25ms。

一、现象与背景：吞吐满格，但 P99 抖到 480ms

去年我们把一个 10G 上联做成了多业务共享：一条物理链路上同时跑着实时行情推送（对延迟敏感，预算 <30ms）和批量文件同步（吞吐敏感，能容忍秒级延迟）。

接入批量同步后，实时业务的 P99 从基线 18ms 一路涨到 480ms，峰值甚至到 1.2s。但诡异的是：

• ping 到对端 RTT 始终 3–5ms，丢包 0；
• iperf3 单测带宽能稳定跑到 9.6Gbps，几乎没有抖动；
• 交换机端口无 CRC 错包、无光衰告警；
• 应用层 GC、后端 P50 都正常。

按常理「带宽够、不丢包、CPU 不高」就该排除了网络，但实时业务的超时率从 0.02% 飙到了 11%，客户直接报障。这就是典型的 bufferbloat：带宽和丢包这两个指标，全都测不出队列延迟。

二、原理与根因：瓶颈不在链路，在发送端的队列

根因一句话：批量同步把链路打满后，发送侧内核的发送队列（以及交换机出端口队列）开始无限制地堆积，排队时间全部折算成了 RTT。

机制拆开看：

1. TCP 的发送窗口是「越多越好」的：拥塞窗口（cwnd）只会在丢包或 RTT 增大时收缩。只要不丢包，cwnd 就一路涨，把对端接收缓冲和中间设备队列塞到最大。
2. 队列延迟 = 队列里的字节数 ÷ 链路速率。10Gbps 链路，只要队列里堆了 6MB 数据，排队延迟就是 6MB / 10Gbps ≈ 4.8ms；堆到 60MB 就是 48ms；我们实测峰值队列深度到了 550MB 量级，对应排队延迟 440ms+，和 P99 完全对得上。
3. 为什么丢包是 0：因为队列「够长」，包只是排队、还没溢出，所以没有任何一个包被丢。丢包是队列的「上限保护」，不是「延迟信号」——等到丢包发生，延迟早就爆表了。

这就是 bufferbloat 的反直觉核心：「不丢包」恰恰是延迟失控的原因，因为不丢包 = 队列不收缩 = 延迟无限膨胀。

三、具体做法：用 fq_codel 把「目标延迟」锁死

思路：不要等丢包来限制队列，直接让拥塞控制以「延迟」为信号。Linux 内核对应的队列调度器是 fq_codel（Fair Queuing + CoDel）。CoDel 的判据是「包在队列里排队时间 > 目标值（默认 5ms）且持续至少 10 个往返」，满足就主动丢弃一个包——注意，它丢的只是极少数的包，目的是给 TCP 一个「该收缩 cwnd 了」的信号，从而把队列长度稳定压在一个很小的水位。

步骤（在发送侧、瓶颈上游的那台机器上做，这是关键，见第四节的坑）：

# 0) 先看清当前队列调度器和深度基线
tc -s qdisc show dev eth0
# 典型输出：qdisc pfifo_fast ... limit 1000p   <-- 默认调度器，深度按"包数"限，不控延迟

# 1) 把 eth0 的 qdisc 换成 fq_codel
#    target=5ms 是目标排队延迟，interval=100ms 是采样周期
#    quantum=1514 保证单包流至少能发一个 MTU 包（公平性）
tc qdisc replace dev eth0 root fq_codel target 5ms interval 100ms quantum 1514

# 2) 验证：跑一次 iperf 打满带宽，同时看队列深度
#    发送侧另开一个终端持续采样
watch -n 0.2 'tc -s qdisc show dev eth0 | grep -E "dropped|sent"'

# 3) 看实时业务的 P99 是否回落（从应用 metrics 或抓包算 RTT）
#    tcpdump -i eth0 -s 96 -nn 'tcp port 443' -w /tmp/rtt.pcap
#    用 tshark 统计 SYN->ACK 的 RTT 分布
tshark -r /tmp/rtt.pcap -Y 'tcp.flags.syn==1 && tcp.flags.ack==0' \
       -T fields -e frame.time_relative -e ip.src

实测效果（同一台机器、同样的业务配比）：

| 指标 | pfifo_fast（改前） | fq_codel（改后） | |---|---|---| | 实时业务 P99 | 480ms | 25ms | | 实时业务超时率 | 11% | 0.03% | | 批量同步吞吐 | 9.6Gbps | 9.2Gbps（-4%） | | 队列深度峰值 | ~550MB | < 40MB | | 丢包率 | 0 | 0.15%（CoDel 主动丢，符合预期） |

用 4% 的批量吞吐，换回实时业务 P99 从 480ms 到 25ms，这笔账对延迟敏感业务是绝对划算的。

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

1. 装错位置 = 完全无效。fq_codel 必须装在瓶颈上游的发送侧（谁在灌队列，就在谁的出口上装）。一开始我们装在了接收侧和对端交换机上，P99 纹丝不动。后来把批量同步那台机器的 eth0 出口换成 fq_codel，立刻见效。教训：控制延迟要在「制造队列的人」身上做。
2. 它会产生「丢包」，这不是故障。改完后监控里丢包率从 0 变成 0.15%，值班同学差点当故障上报。要提前把「CoDel 主动丢包」写进 runbook，否则会被当成链路劣化去排查光模块。
3. target=5ms 不是越小越好。我们把 target 调到 1ms 做实验，结果实时 P99 只降到 22ms（收益几乎没了），但批量吞吐掉到 7.1Gbps（-26%），因为丢包信号太频繁、cwnd 收缩太狠。5ms 是吞吐和延迟的平衡点，再往下是拿吞吐硬换延迟，多数场景不划算。
4. 默认 pfifo_fast 的深度单位是「包数」不是「字节」。limit 1000p 意思是最多 1000 个包，但每个包 1500B，1000 包 ≈ 1.5MB 起步，而交换机出端口队列往往是按字节配、动辄几十 MB——真正的队列深度是「发送侧 + 交换机端口」两段之和，只调 Linux 侧、交换机端口队列还是 64MB 的话，改善会被稀释。这次我们把交换机出端口队列也一起砍到了 16MB，延迟才彻底稳住。
5. ping 和 iperf 都是「坏证据」。它们分别只测小包 RTT 和纯带宽，都不反映「高负载下的排队延迟」。判断 bufferbloat 要看高负载时的 P99 RTT，而不是空闲 RTT。

五、结论与可复用清单

• 现象指纹：带宽够、丢包 0、空闲 RTT 正常，但高负载时 P99 延迟暴涨 → 优先怀疑 bufferbloat，而不是链路。
• 诊断三板斧：① tc -s qdisc show dev <iface> 看当前调度器与队列深度；② 高负载时抓包算 P99 RTT（不是空闲 RTT）；③ 对比「发送侧队列 + 交换机出端口队列」两段深度之和。
• 止血动作：瓶颈上游发送侧 tc qdisc replace dev <iface> root fq_codel target 5ms interval 100ms quantum 1514；同时把交换机出端口队列砍到合理水位（本次 16MB）。
• 预期代价：吞吐掉 4% 左右、丢包率出现 0.1% 量级的「CoDel 主动丢包」，都要提前写进 runbook 避免误报。
• 调参原则：target 默认 5ms 起步，别盲目调小；每调一档都同时看实时 P99 和批量吞吐两条曲线。
• 一句话：不丢包不等于健康，队列在涨、延迟就在涨；把「延迟」变成拥塞信号（fq_codel/CoDel），比把带宽加粗有效得多。