1. WebRTC 流控概述：什么是流控、为什么需要流控、WebRTC 流控体系概览

各位同学，欢迎来到《WebRTC流控调试从入门到精通》的第一章。

咱们开门见山。流控，全称是流量控制。说白了，就是管住数据发送的节奏。你想想看，网络就像一根水管，粗细有限。你一股脑往里灌水，水管就爆了。数据包也是一样，发太快了，网络就堵了。

我刚开始接触WebRTC时，觉得流控就是个“限速器”。后来踩了坑才发现，它远比我想象的复杂。它不仅要管“发多快”，还要管“发什么”、“什么时候发”、“发不动了怎么办”。

1.1 什么是流控？

流控，就是一套动态调整数据发送速率和发送策略的机制。它的目标是：在有限的网络带宽下，尽可能保证通话质量。

具体来说，流控做三件事：

• 探测带宽：实时测量当前网络能承载多少数据。
• 分配带宽：把测到的带宽分给音频、视频、数据通道。
• 调整发送：根据分配结果，控制编码器输出码率，或者丢帧、降分辨率。

举个例子。你开视频会议，网络突然变差。流控会怎么做？它会先降低视频码率，画面可能变模糊，但通话不会断。如果网络继续恶化，它会进一步降分辨率，甚至暂时停掉视频，只保留音频。这就是流控在起作用。

1.2 为什么需要流控？

这个问题，我当年也问过自己。不做流控行不行？答案是：不行。原因有三。

1. 网络不可靠：互联网是“尽力而为”的。带宽、延迟、丢包率随时在变。没有流控，就像闭着眼睛开车。
2. 用户体验敏感：视频卡顿、声音断续，用户30秒就跑了。流控能保证“烂网络下也能用”。
3. 资源竞争：一个WebRTC连接里，音频、视频、数据通道在抢带宽。没有流控，音频可能被视频饿死，导致听不见对方说话。

你想想看，如果没有流控，会发生什么？

• 发送端拼命发数据，网络缓冲区被填满，延迟飙升。
• 路由器开始丢包，接收端收不到完整数据，画面花屏。
• 发送端发现丢包，重传更多数据，网络更堵。恶性循环。

这就是所谓的“拥塞崩溃”。流控就是避免这种情况的。

1.3 WebRTC 流控体系概览

WebRTC的流控体系，不是单一算法，而是一套组合拳。我把它分成三个层次：

层次	核心组件	主要职责
传输层	RTP/RTCP、ICE、DTLS	建立连接、传输数据、反馈网络状态
拥塞控制层	GCC (Google Congestion Control)	探测带宽、检测拥塞、调整发送速率
媒体层	编码器、码率控制器、帧率控制器	根据带宽分配结果，调整编码参数

这三个层次是联动的。传输层提供“路况信息”，拥塞控制层做“决策”，媒体层执行“调整”。

咱们重点说说拥塞控制层。WebRTC目前主流的拥塞控制算法是GCC。它有两个版本：

• 基于延迟的GCC：通过观察数据包延迟变化，判断网络是否开始拥堵。延迟增加，说明队列在堆积，要降速。
• 基于丢包的GCC：通过观察丢包率，判断网络是否过载。丢包率超过阈值，立刻降速。

实际使用中，两者是配合的。延迟算法更灵敏，能提前发现拥塞。丢包算法更保守，作为兜底。

下面这张图，展示了WebRTC流控的核心流程。我画了很久，希望能帮你建立整体认知。

嗯，这张图里，最关键的就是那条从接收端回到发送端的虚线。它代表了RTCP反馈。没有这条反馈，发送端就是“盲人摸象”。

最后，我总结一下WebRTC流控体系的几个特点：

• 闭环控制：发送→传输→接收→反馈→调整，形成一个持续循环。
• 多维度探测：同时使用延迟和丢包两个信号，互相补充。
• 分层协作：传输层、拥塞控制层、媒体层各司其职，又紧密配合。
• 实时性要求高：反馈周期通常在100ms以内，否则调整跟不上网络变化。