弱网 QoS 引擎（抖动缓冲 / 丢包恢复 / 码率自适应）
内容提要
本文介绍用Claude Code构建实时音视频弱网对抗QoS引擎，针对抖动、丢包、带宽波动三类问题：Jitter Buffer按RFC 3550估算抖动并动态缓冲；FEC异或冗余与NACK重传恢复丢包；基于丢包率和RTT的AIMD算法自适应码率。三者协同保证弱网流畅，并附踩坑记录与效果对比。
延伸解读
抖动缓冲的延迟与平滑权衡
文章采用RFC 3550估算抖动，目标缓冲设为baseDelay + 4×jitter，并限制在40ms到500ms之间。4倍抖动是经验值，能覆盖99.9%的抖动情况，但缓冲越大延迟越高。实时通话场景下，作者建议宁可牺牲一点平滑度也要压低延迟，因此加入了dropIfTooSlow机制，当缓冲超过目标两倍时主动丢帧追赶，避免延迟无限累积。
FEC与NACK的适用场景与代价
FEC通过异或冗余包恢复丢包，每4个包加1个冗余包带来25%的带宽开销，适合丢包率高于10%的场景。NACK则请求重传，在丢包率低于5%时更省带宽，但需限制重传次数和间隔以避免NACK风暴。文章还提到Opus的带内FEC能在语音场景中利用低码率冗余实现纠错，是一种更高效的补充手段。
码率自适应的AIMD策略与防振荡
码率控制器基于丢包率和RTT，采用AIMD算法：丢包率超过10%时乘性下降，网络良好时每次加性增加8%。为避免码率振荡，降档后会强制进入hold状态观察一段时间再考虑升档。此外，监听网络切换事件（如WiFi切4G）会立即将码率重置到最小值，防止因带宽骤降导致断流。
踩坑记录揭示的工程细节
文章总结了六个典型问题：缓冲永远不满源于jitter初值为0，需用滑动平均收敛；延迟累积因缺少追赶机制，需加入丢帧逻辑；FEC冗余过高应随丢包率动态开关；码率振荡需降档后观察期；切网断流需监听网络变化并重置码率；NACK风暴需限制重传次数、间隔并批量聚合。这些细节是构建稳定QoS引擎的关键。
Q&A
弱网环境下实时音视频面临哪些主要问题？
弱网环境下实时音视频面临三个主要问题：抖动（包到达时间不稳定，导致播放卡顿）、丢包（UDP不重传，包丢失导致花屏、断音）、带宽波动（网络切换或拥塞，固定码率导致卡顿）。
Jitter Buffer是如何动态调整缓冲时长的？
Jitter Buffer使用RFC 3550的抖动估算公式计算网络抖动，目标缓冲时长 = 基础延迟 + 4 × 抖动值，并限制在最小40ms、最大500ms之间。当缓冲时间超过目标2倍时，会丢弃最旧的包以追赶，避免延迟累积。
FEC和NACK在丢包恢复中分别适用什么场景？
FEC通过发送冗余包（如每4个包加1个冗余包）来恢复丢失的包，适合丢包率高于10%的场景，但会增加25%的带宽开销。NACK通过请求重传丢失的包来恢复，适合丢包率低于5%的场景，更节省带宽。两者可结合使用。
码率自适应算法是如何根据网络状况调整码率的？
码率自适应采用AIMD算法：当丢包率超过10%时，乘性降低码率（如乘以0.5~0.9）；当RTT超过300ms时，保持当前码率；当网络良好时，加性增加码率（每次增加8%）。降档后会强制保持一段时间再尝试升档，避免振荡。
在实现QoS引擎时有哪些常见的坑？
常见坑包括：缓冲永远不满（初始jitter估算为0导致目标太小）、延迟累积（缓冲只增不减）、FEC冗余过高（固定group_size不随丢包率变化）、码率振荡（降档后立即升档）、WiFi切4G断流（未重置码率）、NACK风暴（未限制重传次数和间隔）。
QoS引擎中抖动缓冲、丢包恢复和码率自适应三者如何协同工作？
三者协同工作：抖动缓冲吸收网络抖动，输出平滑的包序列；丢包恢复通过FEC或NACK修复丢失的包；码率自适应根据网络状况调整发送码率。单独使用任一技术只能解决一类问题，三者叠加才能保证弱网下的流畅体验。
