1. WebRTC 流控全景：从端到端延迟说起
做实时通信的人，最怕听到的一句话是什么？
「你那边卡了。」
嗯，就这么简单四个字，能把一个架构师逼疯。我入行头两年，一直在跟延迟和卡顿较劲。那时候我天真地以为，只要带宽够大，一切问题都能解决。后来被现实狠狠教育了一顿——带宽再大，流控没做好，该卡还是卡。
1.1 端到端延迟：流控的起点
咱们先搞清楚一件事：WebRTC 里的「延迟」到底指什么？
不是网络延迟，也不是编码延迟。我说的是端到端延迟——从摄像头采集到对端屏幕显示，这中间经过的所有环节的总耗时。
| 延迟环节 | 典型耗时 | 可控性 |
|---|---|---|
| 采集延迟 | 10-30ms | 低（依赖硬件） |
| 编码延迟 | 5-50ms | 中（可调编码器参数） |
| 网络传输延迟 | 20-300ms | 高（流控核心战场） |
| 抖动缓冲延迟 | 30-200ms | 中（自适应算法） |
| 解码渲染延迟 | 5-20ms | 低 |
你看，网络传输和抖动缓冲这两块，占了延迟的大头。而这两块，恰恰是流控能发挥最大作用的地方。
核心观点：流控不是单纯地「限制码率」，而是在延迟、质量、流畅度之间找一个动态平衡点。说白了，就是让用户在「稍微模糊但流畅」和「清晰但卡顿」之间，永远选前者。
1.2 流控到底在控什么？
我经常被问到：「流控不就是控制发送码率吗？」
对，但不全对。WebRTC 的流控体系，至少管三件事：
- 发送端码率控制——编码器该压到多少比特率？
- 接收端拥塞控制——网络是不是快撑不住了？要不要降速？
- 延迟与丢包的权衡——是重传丢包，还是直接跳过？
这三件事互相影响。我曾经在一个项目中，只调了发送端码率上限，结果接收端缓冲区爆炸，延迟从 100ms 飙到 800ms。用户反馈说「画面不卡，但像在看慢放」——这比卡顿还难受。
1.3 流控的核心组件
WebRTC 的流控不是单一算法，而是一套组合拳。我习惯把它拆成四个模块：
- GCC（Google Congestion Control）——基于延迟和丢包的拥塞控制器，是流控的大脑。
- Pacer（平滑发送器）——把突发数据打散，避免网络抖动。
- FEC（前向纠错）——丢包后不用重传，直接恢复数据。
- NACK（重传请求）——丢了就喊重传，但会引入额外延迟。
这四个组件怎么配合？我画了张图，你看一眼就明白了。
我的经验：调试流控时，别一上来就调 GCC 参数。先看 Pacer 有没有正常工作。Pacer 如果没把数据打散，GCC 再聪明也救不了。我曾经花了两天查一个卡顿问题，最后发现是 Pacer 队列溢出——丢包率不到 1%，但延迟直接炸了。
1.4 延迟、抖动、丢包：流控的铁三角
做流控，本质上是在跟三个变量打交道：
- 延迟——数据从 A 到 B 的时间。高了就卡。
- 抖动——延迟的变化幅度。大了就忽快忽慢。
- 丢包——数据在路上丢了。多了就花屏。
这三个变量互相牵制。你想想看：为了降低延迟，你可能减少抖动缓冲，但抖动一来，丢包率就上去了。为了降低丢包，你开 FEC，带宽占用增加，延迟又上去了。
这就是流控的难点——没有银弹。
| 场景 | 优先目标 | 流控策略 |
|---|---|---|
| 视频会议 | 低延迟（< 200ms） | 激进降码率，减少缓冲 |
| 直播连麦 | 低丢包（< 1%） | 适度增加 FEC，容忍一定延迟 |
| 远程桌面 | 高清晰度 | 动态码率，优先保证关键帧 |
避坑指南：我曾经在一个项目中，为了追求低延迟，把抖动缓冲压到 30ms。结果网络一波动，丢包率从 0.5% 飙到 8%，画面直接变成马赛克。后来我学乖了——抖动缓冲不能低于网络抖动的 2 倍标准差，这是底线。
1.5 流控的终极目标
说了这么多，流控到底要达成什么？
我个人理解就一句话：让用户在可接受的延迟范围内，获得尽可能好的体验。
这个「可接受」因人而异。视频会议用户能忍 300ms，但游戏直播用户 100ms 就骂娘了。所以流控策略不能一刀切，得根据场景动态调整。
嗯，这就是流控的全景。从端到端延迟切入，理解 GCC、Pacer、FEC、NACK 怎么配合，再掌握延迟、抖动、丢包之间的权衡——后面所有章节，都是围绕这个框架展开的。
记住：流控不是算法，是哲学。它教会你一件事——在资源有限的世界里，如何做出最优取舍。