28、WebRTC拥塞控制标准化进展：IETF RMCAT工作组、RFC 8888、未来方向
聊到WebRTC的拥塞控制，很多人第一反应就是GCC（Google Congestion Control）。确实，GCC是目前应用最广的算法。但你知道吗？它背后有一个庞大的标准化组织在推动——IETF的RMCAT工作组。今天我们就来聊聊这个。
我个人习惯把拥塞控制的标准化进程分成三个阶段：早期探索、核心定型、未来演进。RMCAT工作组正好贯穿了这三个阶段。
28.1 RMCAT工作组：拥塞控制的“立法者”
RMCAT的全称是“RTP Media Congestion Avoidance Techniques”。说白了，就是一群网络专家聚在一起，给实时音视频通信定规矩。
这个工作组2012年左右开始活跃。我记得当时我刚接触WebRTC，看到一堆RFC文档头都大了。但后来发现，这些文档其实是宝藏。
RMCAT主要干了三件事：
- 定义评估标准：什么样的拥塞控制算法才算好？不能光看吞吐量，还得看延迟、公平性、友好性。
- 提出算法框架：不是具体实现，而是给出设计思路。比如基于延迟的检测、基于丢包的检测，这两种信号怎么融合。
- 推动互操作性：不同厂商的实现要能一起工作。你想想看，Chrome和Safari用的拥塞控制算法不一样，但它们得能正常通话。
核心观点：RMCAT不规定你必须用哪种算法，它只规定“好算法应该长什么样”。这给了开发者很大的自由度。
28.2 RFC 8888：拥塞控制的“反馈通道”
RFC 8888的全称是“RTP Control Protocol (RTCP) Feedback for Congestion Control”。名字很长，但作用很简单——它定义了一种标准化的反馈机制。
为什么会需要这个？
在WebRTC里，接收端需要告诉发送端：“我这边网络状况怎么样”。以前各家用自己的私有格式，互不兼容。RFC 8888统一了这件事。
具体来说，RFC 8888定义了两种关键反馈：
- ECN反馈：显式拥塞通知。路由器可以直接告诉接收端“我快撑不住了”，接收端再转告发送端。
- 丢包和延迟反馈：接收端统计丢包率和到达时间，打包成标准格式发回去。
我在项目中遇到过一个问题：某厂商的终端只支持RFC 8888，但我们的服务器用的是老版GCC。结果就是拥塞控制完全失效，通话质量一塌糊涂。后来我们升级了反馈解析模块才解决。
避坑指南：如果你在开发WebRTC网关或SFU，一定要确认两端的反馈格式是否兼容。我曾经因为没注意这个，线上出了大问题。
28.3 未来方向：从“单打独斗”到“协同作战”
拥塞控制的未来，我个人认为有三个趋势：
- 机器学习辅助：传统算法基于数学模型，但网络环境太复杂了。用ML预测带宽变化，已经在一些实验性项目中验证了效果。
- 跨层协同：应用层、传输层、网络层一起做决策。比如应用层知道当前是视频会议还是直播，传输层知道RTT和丢包率，网络层知道队列深度。三者协同，效果远好于单打独斗。
- SCReAM和NADA的演进：这两个是RMCAT工作组提出的候选算法。SCReAM基于延迟和丢包，NADA基于网络辅助。它们都在持续迭代中。
下面这张图展示了拥塞控制标准化的演进脉络：
28.4 标准化对开发者的影响
说了这么多，标准化到底对我们这些写代码的人有什么影响？
嗯，这里要注意。标准化不是束缚，而是解放。
- 互操作性：你的WebRTC应用可以跟任何符合标准的终端互通。不用再为兼容性头疼。
- 可维护性：基于标准实现的代码，团队新人上手更快。我见过太多私有协议的项目，维护成本高得吓人。
- 可扩展性：标准框架下，你可以替换核心算法而不影响其他模块。比如从GCC切换到SCReAM，只需要改拥塞控制模块。
注意：标准化不等于“所有实现都一样”。RFC 8888只规定了反馈格式，没规定你怎么用这些反馈。你完全可以基于同样的反馈数据，实现自己的拥塞控制逻辑。
28.5 实战建议
如果你正在开发WebRTC相关的产品，我的建议是：
- 优先支持RFC 8888：这是目前最成熟的标准化反馈机制。你的接收端和发送端都应该支持。
- 关注SCReAM和NADA：这两个算法代表了未来方向。虽然还没成为正式标准，但已经在很多场景中验证了效果。
- 预留扩展接口：你的拥塞控制模块应该设计成可插拔的。这样未来新算法出来，你只需要写一个新插件。
我在一个视频会议项目中，就采用了这种可插拔设计。当时用的是GCC，后来想试试SCReAM，只改了一个配置文件就切换了。这种灵活性，就是标准化带来的好处。
好了，关于标准化进展就聊到这里。记住，标准是工具，不是目的。真正重要的是你的产品在真实网络中的表现。
公众号:蓝海资料掘金营，微信deep3321