QoS 与 SQM：解决延迟膨胀，而不迷信测速数字

带宽够快，为什么通话仍卡

当上行或下行链路接近满载时，设备和运营商队列可能积累大量数据包，导致交互流量排队数百毫秒，这种延迟上升常被称为缓冲膨胀。测速只展示某一时段的吞吐，不一定揭示满载延迟、抖动和丢包。视频通话、游戏和远程桌面依赖低延迟，而云备份或下载则更关注吞吐。QoS 的目标是让拥塞队列更可控，在高负载时保护关键流量，而不是无条件让所有设备都变快。

SQM 的工作思路

智能队列管理会在可控位置整形带宽，并使用公平排队和主动队列管理降低队列延迟。整形速率通常略低于真实瓶颈，确保队列在路由器可管理的位置形成；速率过低会浪费带宽，过高则拥塞仍留在上游不可控队列。CAKE 等队列算法可结合流公平、主机公平和 DiffServ 分类，但配置复杂度和硬件负载也要考虑。具体参数要根据链路类型、峰值变化、全双工/半双工和硬件性能测量。

调优过程

先测空闲时延、满载上下载时延、丢包、抖动和实际吞吐，至少在不同时间段重复。分别测试有线和无线，避免把 Wi-Fi 干扰误判为 WAN 队列问题。启用 SQM 后逐步调整整形速率，从较保守值开始，每次只改上行或下行一项，使用相同的测试方法观察延迟与吞吐变化。对于非对称宽带、DOCSIS、PPPoE 或移动宽带，瓶颈和性能行为不同。测速服务器本身也可能成为限制，需换多个目标和服务验证。

规则与硬件取舍

基于端口或应用分类容易过时，现代流量常使用 HTTPS 或 QUIC，应用识别并非总能准确。简单的每主机公平队列可能已能改善体验，复杂优先级策略反而容易被错误标记滥用。启用 SQM 后，路由器 CPU 可能成为瓶颈，特别是关闭硬件流量卸载后；要监测单核利用率、温度、丢包和吞吐。路由器标称千兆转发能力不代表开启整形、加密和复杂防火墙后仍可千兆。

测试图

形成可复用的配置

把目标写成可检验的体验，例如“满载时延增幅低于某范围且吞吐保持在可接受比例”，而不是追求一个孤立测速峰值。记录原始数值、连接类型、设备和测试时段。对 SQM 失效时设置容易关闭的回退方案，并在系统升级后复测。QoS 不能修复信号差、路由错误、服务端拥塞或过载 CPU；先定位瓶颈，再选择队列算法。家庭成员更在意通话稳定还是大文件下载，需要共同确定取舍。

深入实践：体验指标与可重复调优

把工作日通话、多人视频、游戏和云备份作为不同负载场景，分别记录空载、下载满载和上传满载延迟。选择多台可靠探测目标，排除单一测速服务器异常。SQM 速率应与持续可用的真实带宽相匹配，并关注晚高峰变化；如果链路速率随时间大幅波动，静态整形可能需要保守设置或分时策略。每次调整留下数据表和当前配置，成功后观察数日再固化。若性能不佳，比较 CPU、无线信号、上游拥塞和队列指标，确定瓶颈后再决定换设备或改算法。

调优实战：先定位队列在哪形成

测试时同时观察本地路由器 CPU、接口吞吐和延迟。若路由器 CPU 已满，进一步降低整形速率或关闭某些功能可能改变表现；若设备负载很低而上游延迟仍飙升，瓶颈可能在运营商或光猫缓冲区。上下行分别形成瓶颈，家庭上行速度常远低于下载，上传云备份容易拖慢视频通话。测量应在有线设备进行，并用不同目标重复，以避免 Wi-Fi 干扰或远端服务器限速造成误导。

算法与分类的实际限制

公平队列可以避免单个大流量会话完全挤占其他用户，但不能创造额外带宽。基于 DSCP 或应用端口分类容易过时，现代流量常加密，客户端标记也未必可信；过度优先会让低优先级业务长期饥饿。选择默认公平策略通常比复杂的手工分类更容易维护。VoIP、游戏和互动视频的包很小，关键是控制拥塞延迟，而非给予无限带宽。若家庭成员同时上传大文件和开会，实际测试比规则推演更有价值。

持续验证与用户体验

在工作日高峰和空闲时段比较数据，记录路由器系统版本、SQM 算法、上下行速率及硬件加速状态。升级后重新做满载延迟测试，因为内核、驱动和队列规则可能改变。设置一个容易关闭的配置备份，如果开启整形后吞吐下降过多或路由器重启，应快速恢复。向家庭成员确认通话、游戏、下载实际体验，指标应服务于真实使用。若链路质量变化频繁，考虑联系运营商、调整光猫或排查无线环境，而非不断提高 QoS 规则复杂度。