1. WebRTC 流控概述：为什么需要流控？流控在实时通信中的核心地位
大家好，我是你们这趟 WebRTC 流控之旅的向导。今天咱们先聊聊最基础的问题——为什么需要流控？
你想想看，实时通信的本质是什么？说白了，就是让音视频数据在不可控的网络上，以可控的方式传输。网络是不可控的——带宽会波动、丢包会突发、延迟会抖动。而我们的任务，就是在这片「沼泽地」里，把数据稳稳当当地送到对端。
我个人习惯把流控比作「实时通信的刹车和油门」。没有它，你的通话要么卡成幻灯片，要么直接断线。我在项目中遇到过不少团队，功能都跑通了，一上弱网环境就崩，根源往往就是流控没做好。
1.1 流控到底在解决什么问题？
咱们先拆解一下，没有流控会怎样。假设你正在跟客户视频会议，网络突然变差——
- 发送端不管不顾：继续以 2Mbps 的码率往外推数据，但网络只剩 500Kbps 的吞吐。结果呢？路由器缓冲区爆满，延迟飙升到几秒，丢包率暴涨。
- 接收端被动挨打：收到的包要么延迟太高，要么残缺不全。视频解码器拿到的是一堆乱序帧，画面直接花掉。
- 用户体验归零：你说一句，对方 3 秒后才听到。这种通话，还不如挂断重拨。
流控要解决的，就是这三个核心矛盾：
- 发送速率 vs 网络容量——不能发太快，也不能发太慢。
- 编码质量 vs 流畅度——清晰度重要，还是不卡顿重要？得动态权衡。
- 延迟 vs 吞吐——想多传数据，就得忍受更高延迟；想低延迟，就得牺牲码率。
1.2 流控在实时通信中的核心地位
咱们用一张图来理解流控在整个 WebRTC 架构中的位置。你看，它就像中枢神经系统，连接着采集、编码、网络传输、解码、渲染每一个环节。
从这张图你能看到，流控引擎处于绝对的中心位置。它接收来自网络层的反馈（丢包率、RTT、接收端估计带宽），然后反过来控制编码器的码率、分辨率、帧率，以及网络发送的节奏。
我记得有一次调试一个跨国会议系统，用户抱怨「画面突然变模糊，然后又恢复」。我一看日志，发现流控引擎在 2 秒内把码率从 1.5Mbps 砍到了 300Kbps，然后又迅速拉回。这就是流控在起作用——它感知到网络拥塞，主动降质保流畅；等网络恢复，再提升质量。
1.3 流控的三大核心目标
咱们把流控的目标总结成三个词：公平、效率、稳定。
| 目标 | 含义 | 反面案例 |
|---|---|---|
| 公平 | 多条流共享同一网络时，各自分配合适的带宽，不抢占 | 一条视频流吃掉所有带宽，其他流卡死 |
| 效率 | 充分利用可用带宽，不浪费 | 网络明明有 2Mbps 余量，却只发 500Kbps |
| 稳定 | 码率变化平滑，避免频繁跳变影响体验 | 码率在 1Mbps 和 100Kbps 之间反复横跳 |
1.4 流控的两种基本模式
WebRTC 的流控机制，从大的方向分，有两种模式：
- 发送端流控（Sender-side BWE）：发送端根据接收端反馈的 REMB（Receiver Estimated Maximum Bitrate）或 Transport-CC（Transport-wide Congestion Control）信息，自己算带宽，自己调码率。
- 接收端流控（Receiver-side BWE）：接收端根据收到的包的时间戳、序列号等信息，估算带宽，然后通过 RTCP 告诉发送端「你该降速了」或「可以提速了」。
嗯，这里要注意——WebRTC 早期主要依赖接收端流控（REMB），后来逐渐转向发送端流控（Transport-CC）。为什么？因为发送端掌握的信息更全，响应更快。我个人的建议是：新项目直接上 Transport-CC，别走弯路了。
1.5 流控的挑战：为什么这么难？
你可能会问：流控不就是「带宽够就多传，不够就少传」吗？有什么难的？
其实难点在于：你永远无法准确知道当前的可用带宽。你只能通过一些间接信号去「猜」——丢包率、RTT、抖动、接收端反馈。而这些信号本身就有延迟和噪声。
举个例子：你发现丢包率突然升高了。这可能是网络真的拥塞了，也可能是某个路由器临时抽风，甚至可能是对端 CPU 满载导致处理不过来。你怎么判断？
这就是流控算法的核心挑战——在不确定中做决策。GCC（Google Congestion Control）、BBR、PCC 这些算法，本质上都是在解决「如何更准确地估计带宽，并做出合理的速率调整」这个问题。