11、带宽估计：基于延迟的带宽估计、基于丢包的带宽估计、混合带宽估计策略
带宽估计，说白了就是让通信双方动态感知当前网络能跑多快。我刚开始做WebRTC的时候，觉得这玩意儿不就是测个网速嘛，后来踩了坑才明白——网络是活的，带宽估计得跟着网络一起“呼吸”。
今天咱们聊聊三种主流策略：基于延迟的、基于丢包的，以及把两者揉在一起的混合方案。嗯，每个方案都有自己的脾气，咱们一个个说。
11.1 基于延迟的带宽估计（GCC的延迟模块）
基于延迟的带宽估计，核心思路是：延迟变化 = 网络拥塞信号。你想想看，如果网络开始堵了，数据包在队列里排队，RTT（往返时间）就会悄悄变大。这个变化，就是带宽估计的“眼睛”。
WebRTC里最经典的实现是Google Congestion Control（GCC）中的延迟模块。它的工作流程大致是这样的：
- 计算延迟梯度：接收端记录每个数据包的到达时间，和发送时间做差，得到一个“单向延迟”。
- 趋势检测：用卡尔曼滤波器或简单的过采样检测，判断延迟是在上升还是下降。
- 状态机切换：根据趋势，决定带宽是增加、保持还是减少。
我个人习惯把延迟梯度想象成“网络的心跳”。正常时它平稳跳动，一旦开始持续上升，就像心跳加速——网络在喊“我撑不住了”。
核心公式（简化版）：
延迟梯度 = (接收时间_i - 接收时间_{i-1}) - (发送时间_i - 发送时间_{i-1})
如果梯度 > 阈值 → 网络拥塞，降低带宽
如果梯度 < 阈值 → 网络空闲，增加带宽我在项目中遇到过一个问题：延迟梯度对“突发流量”特别敏感。有一次线上会议，用户突然打开了一个大文件下载，延迟梯度瞬间飙升，带宽被砍到只剩200kbps。其实网络只是短暂抖动，但算法反应过激了。后来我们加了平滑窗口，才解决了这个问题。
避坑指南：延迟梯度算法对时钟同步要求很高。我曾经因为发送端和接收端时钟不同步，导致延迟计算全是错的。建议用NTP或者相对时间戳来规避。
11.2 基于丢包的带宽估计
基于丢包的方法，思路更直接：丢包了 → 网络太挤 → 降速。WebRTC里用的是REMBB（Receiver Estimated Max Bitrate）算法，后来演变成了Transport-CC中的丢包反馈。
它的逻辑其实很简单：
- 接收端统计丢包率（比如每100个包丢了几个）。
- 如果丢包率 > 10%，带宽直接砍半（乘法减小）。
- 如果丢包率在2%~10%之间，带宽小幅下降。
- 如果丢包率 < 2%，带宽可以尝试增加（加法增加）。
说白了，这就是一个“痛了就缩手”的策略。但问题也在这里——丢包不一定是因为拥塞。无线网络、Wi-Fi干扰、甚至路由器缓存溢出，都会导致丢包。你想想看，如果因为Wi-Fi信号不好就疯狂降码率，那视频质量就彻底完蛋了。
注意：纯丢包策略在无线网络下表现很差。我见过一个案例，用户在咖啡厅用Wi-Fi开会，丢包率一直在5%左右徘徊，带宽被压到300kbps，视频糊成马赛克。其实网络带宽是够的，只是无线链路不稳定。
所以，现在WebRTC很少单独用丢包策略，而是把它和延迟策略结合起来——这就是咱们接下来要聊的混合方案。
11.3 混合带宽估计策略
混合策略，就是把延迟和丢包两套“眼睛”同时用上。GCC 2.0（也就是现在WebRTC默认的带宽估计器）就是这么干的。它的核心逻辑是：
- 延迟模块：负责检测“轻微拥塞”，提前降速，避免丢包。
- 丢包模块：负责检测“严重拥塞”，当延迟模块没来得及反应时，丢包模块兜底。
你可以把延迟模块想象成“预警系统”，丢包模块是“最后防线”。两者配合，才能在各种网络环境下都稳住。
具体实现上，GCC 2.0用了两个独立的带宽估计器，然后取最小值作为最终带宽：
最终带宽 = min(延迟估计带宽, 丢包估计带宽)为什么取最小值？因为“木桶效应”——网络能跑多快，取决于最差的那个指标。延迟说能跑2Mbps，丢包说只能跑1Mbps，那实际带宽就是1Mbps，不然丢包会继续恶化。
我个人的经验：混合策略在90%的场景下表现都很好。但有一个坑——当延迟和丢包信号冲突时（比如延迟很低但丢包很高），算法会陷入“震荡”。我曾经调试过一个案例，带宽在1Mbps和500kbps之间来回跳，视频一卡一卡的。后来发现是Wi-Fi的突发丢包触发了丢包模块，但延迟模块觉得网络很好，两个估计器在“打架”。
解决方案是什么？加一个“置信度”权重。如果丢包是突发的（比如瞬间丢3个包然后恢复），降低丢包模块的权重；如果丢包是持续的（比如每100个包丢5个），提高丢包模块的权重。嗯，这个逻辑说起来简单，调参的时候可费了不少功夫。
11.4 三种策略对比
| 策略 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 基于延迟 | 提前预警，响应快 | 对时钟同步敏感，突发流量误判 | 有线网络、稳定环境 |
| 基于丢包 | 实现简单，直接有效 | 无线网络误判多，反应滞后 | 有线网络、丢包率低的环境 |
| 混合策略 | 综合两者优点，鲁棒性强 | 实现复杂，参数调优困难 | 所有场景（推荐默认使用） |
11.5 知识体系图
下面这张图展示了三种带宽估计策略的核心逻辑和关系。你可以看到，延迟和丢包是两条独立的检测路径，最终在“带宽决策”处汇合。
从图中可以看到，延迟和丢包是两条并行的检测路径。延迟模块负责“微调”，丢包模块负责“大砍”。混合策略就是那个“裁判”，谁说的更可信就听谁的——但最终取最小值，确保网络不崩溃。
实战建议：如果你在调WebRTC的带宽估计参数，建议先从混合策略开始。默认的GCC参数对大多数场景都够用。如果遇到特定问题（比如Wi-Fi丢包率高），可以适当调整丢包模块的阈值，比如把“丢包率 > 10% 砍半”改成“丢包率 > 15% 砍半”，给延迟模块更多反应时间。
好了，关于带宽估计的三种策略，咱们就聊到这儿。记住一句话：没有完美的算法，只有适合场景的策略。延迟、丢包、混合，选哪个？看你的网络环境说话。