家庭宽带 QoS 与 SQM 抗缓冲膨胀实战：用 OpenWrt CAKE 解决视频会议卡顿与游戏延迟

摘要：很多人家里千兆宽带，视频会议却频繁卡顿、打游戏 ping 飙到 200ms，罪魁往往不是带宽，而是"缓冲膨胀"（Bufferbloat）。本文用 OpenWrt 的 SQM（smart queue management）配合 CAKE 队列算法，给出一套可落地的根治方案，并附带测速验证方法。

一、什么是缓冲膨胀（Bufferbloat）

当路由器在上行或下行出口处堆积了大量待发数据包时，新数据包要排队等待，延迟就会随队列变长而线性上升。典型场景：家里有人在迅雷或 BT 满速下载，你的游戏数据包被堵在路由器队列里，ping 从 20ms 涨到 200ms 以上；或者上传占用打满时，视频会议的回传音频直接卡死。

问题根源是路由器的缓冲队列过大且无优先级调度。老式 qdisc（如默认的 FIFO）只会无脑缓存，不丢包也不排序，导致高负载下延迟爆炸。

二、先确认你家有没有缓冲膨胀

在浏览器打开 https://www.waveform.com/tools/bufferbloat ，做法：先空载跑一次测速记下延迟，再在测速过程中让另一台设备满速上传或下载。

判断标准：

• 空载延迟 20ms，满速上传时延迟涨到 80ms 以内，基本健康；
• 涨到 150 到 300ms，明显缓冲膨胀；
• 超过 400ms 且伴随丢包，严重，必须治理。

我家的千兆宽带空载 18ms，之前下载时上行延迟冲到 280ms，视频会议回音严重，就是典型的缓冲膨胀。

三、OpenWrt 上启用 SQM

SQM 是 OpenWrt 的官方软件包 sqm-scripts，底层用 fq_codel 或 CAKE 做主动队列管理（AQM），在队列填满前就主动重新调度，从源头限制总速率并公平分配。

安装：

opkg update
opkg install sqm-scripts luci-app-sqm

Web 界面：网络 → SQM QoS，勾选"启用"，选择 WAN 接口（通常是 eth1 或 pppoe-wan），队列算法选 cake，排队规则 piece_of_cake.qos。

四、关键参数与调优

最重要的是把"总速率"设成实测带宽的 90% 到 95%，不能填运营商标称值：

• 上行（Upload）：填实测上行乘以 0.95。我家标称 50M 上行，实测 48，填 45。
• 下行（Download）：填实测下行乘以 0.95。千兆实测 940，填 900。

为什么留 5% 余量？因为 SQM 必须在运营商限速之前就自己限住，才能把队列控制在你这一侧，否则队列又跑到光猫或运营商侧，前功尽弃。

高级选项里把 Egress Qdisc 和 Ingress Qdisc 都设为 cake，Overhead 填 44（PPPoE 典型值，若是 IPoE 直连填 0 到 22），Link Layer 选 None 或按实际 MTU。

保存并应用后，再跑一次 waveform 测试：我家的满速延迟从 280ms 降到 22ms，缓冲膨胀评分从 C 升到 A+。

五、游戏与视频会议优先：DSCP 与双重 CAKE

默认 piece_of_cake 已对 UDP（游戏和语音多为 UDP）做优先级，但如果你要更激进，可在防火墙里给视频会议或游戏端口打 DSCP 标记：

iptables -t mangle -A POSTROUTING -p udp --dport 443 -j DSCP --set-dscp-class CS5

CAKE 的 diffserv4 模式会据此区分金、银，铜流量。不过对多数家庭，默认 besteffort 或 diffserv3 已经足够，过度调 DSCP 反而容易把普通流量饿死，建议先观察一周再决定是否进阶。

六、小结

缓冲膨胀不是加带宽能解决的，而是调度问题。OpenWrt 加 SQM 加 CAKE 是开源且零成本的成熟方案，核心就三步：装包，填 95% 实测速率，跑波形测试验证。治理后满速下载时游戏延迟几乎不涨，视频会议回音消失。建议所有跑满千兆却卡顿的家庭都先测一次 bufferbloat，再决定要不要折腾。