CoDel：路由器怎么知道排队太久，而不是只看队伍多长？

家里网络卡顿时，很多人会先怀疑带宽不够。但有时测速显示链路并不慢，视频会议却因路由器缓存排队而延迟很高。这种现象叫 bufferbloat：大缓存把数据包留得太久，吞吐看似稳定，交互却变迟钝。CoDel（Controlled Delay）是一种主动队列管理方法，核心关注“包等了多久”。

队伍人数不如等待时间重要

传统直觉容易把队列长度当作拥塞指标：缓存里包多，就认为网络堵。但同样数量的数据包，在高速链路上可能很快发完，在慢速链路上却会让后续流量等很久。CoDel 观察数据包从进入队列到离开的 sojourn time（驻留时间），更直接地估计用户感受到的排队延迟。

CoDel 会关注一段时间内的最低驻留时间，而不是只看某个瞬间的尖峰。短暂突发可能是正常现象：路由器先接住一批包，稍后就迅速清空；持续很久的低延迟基线抬高，则更像长期积压。算法结合目标延迟、观察区间和控制循环，在持续排队时逐渐丢包，或在支持时用 ECN 标记，提醒发送端减速。

这像超市收银台：突然来了一群顾客，不代表柜台长期失灵；但如果每个人都排很久，即便队伍看上去不算长，也说明服务系统有持续压力。CoDel 不是看到一阵拥挤就清空队伍，而是尝试识别长期延误。

CoDel 控制的是队列导致的额外延迟，不会提高物理链路速率，也不能直接修复无线信号差、路由绕远或服务器过载。它需要部署在真正能控制瓶颈排队的位置；如果拥塞发生在别的设备或运营商网络里，本地算法很难改变那里的队列。

RFC 8289 将 CoDel 描述为实验性队列管理框架。实践中它常与公平排队组合，例如 FQ-CoDel，让不同流量不至于互相拖累。具体体验仍受接入链路、设备实现、流量类型及上行与下行瓶颈影响。

理解 CoDel 的重点是：网络性能不止看“带宽够不够”，还要看数据包排队造成的等待时间。它通过管理持续队列，努力在链路利用率和交互延迟之间取得平衡；它不是加速器，而是避免缓存把本该快速抵达的数据困在路上的交通调度员。