7.1 拥塞控制与带宽估计

7.1 拥塞控制与带宽估计

调度台从测量班讲起。带宽估计是整个 QoS 闭环的源头：它输出一个数字——当前线路安全可用的发送速率——后续所有参数调整都以此为锚。本节讲这个数字怎么算出来、怎么升怎么降、错判了怎么自救。

为什么不能照搬经典拥塞控制

教科书式的拥塞控制靠丢包驱动：丢了就减、没丢就加。这套逻辑在文件传输里运行良好，搬到实时媒体上就失灵，原因在时间差：对实时链路而言，丢包是拥塞的晚期症状——队列先膨胀、延迟先恶化、最后才溢出丢包。等看到丢包再减速，用户已经卡了几百毫秒；而且实时编码器的发送量可升可降，照搬加性增窗会制造不必要的丢包。所以引擎的估计器把重心放在丢包之前的信号上：排队延迟的趋势。

原理可以用高速路讲清。你没法直接看到前方的车流，但你坐在车里能感觉到：与前车的间隔越来越小、车速越来越稳不下来——这就是队列积压的体感。网络里同理，链路即将拥塞时，包的排队延迟会持续上升；把每个包的到达间隔变化拟成趋势，在趋势抬头时先手降速，就能抢在丢包发生前把队列放空。这份"先手"正是实时体验的关键：降得早，用户只是画质轻降；降得晚，用户直接卡顿。

图：一次带宽爬坡与回落的完整时间线

升与降：不对称的两套节奏

升靠探测。估计器不靠"多发试试看"地爬坡，而是周期性发出短促的探测突发——以远高于当前速率的密度在极短时间内发一小簇包，量很小、间隔可控，然后量这一簇的通过率与延迟：畅通则说明余量至少有一簇的量，估计值抬一步。探测以倍增步长往上找顶，接近可疑区间后步子收紧。这套机制的好处是探顶过程本身不制造明显拥塞，代价是每一步都要等结果，升得克制。

降靠趋势、一步到位。延迟趋势抬头被确认后，估计器直接把速率压到趋势起点的水平附近——因为那个水平被证明是安全的——而不是慢慢往下磨。随后进入低位观察，确认队列放空、趋势转平，再按不对称原则缓慢恢复。降快升慢的全部理由都在用户体验里：降慢了卡顿可见，升快了反复震荡，两害相权，震荡更伤。

两条配套机制补全画面。其一，丢包路径仍作为兜底保留：丢包率越过阈值时无条件压速率，防止趋势判断失灵的极端场景。其二，探测式爬坡在会话初期尤其关键——刚接通时估计值从保守起点出发，探测快速把估计推到实际水平，这决定了"接通后多久达到最佳画质"这一首屏体验指标。

估计器的参数面与可观测面

把估计器的可调面与可观测面各收拢一次，便于工程化使用。可调面集中在三处：起始估计值（决定接通后的爬坡起点，接通慢的产品先看它）、降速保护系数（趋势确认的灵敏度，调太灵会跟着抖动误降）、丢包兜底阈值（7.2 的丢包路径启用点）。可观测面即 7.1 反复使用的三类事件：估计值序列、趋势判定结果、探测簇的收发记录。三者合起来，估计器的每一次决定都能被事后重放——这套可重放性是它最被低估的工程品质：调参不是玄学，是拿历史数据反复回放找最优的过程。

状态机层面，估计器在"保持、爬升、下降"三态间切换，状态由趋势判定与丢包路径共同驱动。把状态序列打出来看，是判读线路习性的最快方式：健康线路呈"爬升、巡航、偶发下降"的稀疏切换；劣化线路呈高频锯齿；竞争线路呈台阶下移后长巡航。状态序列形态与线路习性的对应关系，比任何单一指标都更有解释力——第八章的监控体系会把它纳入例行采集。

探测机制的细节与边界

探测是升速的唯一途径，值得把它的边界说透。探测簇的强度按当前估计值的倍数设计——首次探测按一点二五倍，连成两簇后按更高倍数逐级上探——这个倍增结构让探测在远离真实容量时步伐大、接近时步伐小，天然收敛。探测报文与媒体共用通道但在统计上独立记账，因此探测的代价可精确核算：每轮探测多花的字节、换来的估计增量，都是明账。

探测也有两种失效场景要认识。其一，链路浅缓冲：某些设备的队列极浅，探测簇一到就被丢，探测永远读不到"畅通"的信号，估计被压在低位。表现是"带宽明明够但画质上不去"，处置往往在链路层（换设备或换路径），引擎侧可调的是降低探测强度、以更长的爬坡时间换取更少的探测丢包。其二，非对称线路：上行探测的确认回包走下行，下行拥堵会误伤上行探测的读数。看到"下行卡顿同时上行画质降级"的组合，先查非对称，再怀疑估计器。

与编码器的握手协议

估计值到达分配器、分配器下发编码器，这条链路的"握手纪律"也值得交代。估计值以下调优先：任何一次下调都视为硬约束立即生效，编码器必须在下一个调度周期内压到新目标之下；上调则是软建议，编码器按自己的节奏（关键帧时机、量化回落）逐步兑现。这种不对称保证了"超发"窗口最小化——下行链路超发的代价是排队与延迟，正是 7.1 开篇的教训在执行端的延伸。

执行结果还有回执：编码器实际发送速率回传给估计器作对照，长期"压不下去"会被解读为估计过高而非执行力问题，估计器会自我修正。这套"指令分级加回执修正"的握手模式，是实时系统里处理"预测与执行"关系的通用范式，读其他控制类模块时可以拿它当参照系。

案例：还原一次会议室 Wi-Fi 干扰下的估计轨迹

背景。一间会议室的终端每天下午固定时段画质变差，而带宽套餐远高于会议所需，行政怀疑设备老化，IT 怀疑服务端限速，工单来回踢了两周。

操作。开启事件记录抓两个完整下午，把估计值、延迟趋势、丢包率三条曲线对齐时间轴。样本里上午的估计值平稳走高后巡航；下午两点起，延迟趋势开始周期性抬头，估计值随之锯齿状回落，而丢包率几乎为零——全程没有靠丢包路径出手。时间规律与该写字楼午后的微波炉与蓝牙耳机使用高峰吻合，根因指向无线信道干扰造成的速率波动。

结果。IT 把会议终端迁到独立信道并固定频段后，下午的锯齿消失，画质全天稳定。

解读。这个案例的诊断价值在于"零丢包的波动"这个特征：纯趋势驱动的估计在干扰型劣化下表现为锯齿回落，而拥塞型劣化往往伴随丢包兜底出手。两种形态指向完全不同的处置——前者动环境，后者动流量。没有估计曲线，这两者在外观上都是"画质变差"，只能靠猜。

变式。多路竞争场景是另一类样本：同线路另一台设备开始大文件上传时，本端估计会台阶式下移并稳定在新水平——竞争分走了物理容量，估计如实反映。此场景的正确处置不在引擎而在路由侧的流量整形，也再次说明：估计器是诚实的仪表，读懂读数之后，很多问题的解在系统之外。

要点回顾

本节要点：丢包是拥塞晚期症状，实时链路以延迟趋势为第一信号；升靠探测突发、步步为营，降靠趋势先手、一步到位；丢包路径仅作兜底；估计曲线的形态（锯齿、台阶、巡航）本身就是诊断材料。下一节处理线路里躲不掉的另一件事：包丢了，用什么补。