28、WebRTC标准演进：WebRTC NV、WebRTC Next、新特性展望、行业趋势

聊到WebRTC的标准演进，我得先坦白一件事——几年前我刚接触这个领域时，总觉得标准这东西离我太远。反正浏览器能跑就行，管它什么RFC不RFC的。直到有一次，我在一个跨国视频会议项目里，遇到了Chrome和Firefox的SDP协商不一致的问题……嗯，从那以后，我养成了跟踪标准草案的习惯。

说白了，WebRTC不是一成不变的。它一直在进化。今天我们就来聊聊它的过去、现在，以及未来可能的样子。

从WebRTC 1.0到WebRTC NV

先说说WebRTC NV。NV是“Next Version”的缩写。你可能觉得奇怪，1.0还没完全稳定，怎么就Next了？

其实，W3C和IETF一直在并行推进。WebRTC 1.0的核心API已经基本冻结，但有些东西——比如Simulcast的API、SVC的支持、更灵活的编码器控制——在1.0里要么没有，要么太粗糙。所以就有了WebRTC NV这个“增强版”。

我个人习惯把WebRTC NV看作“生产环境增强包”。它解决了很多我在项目中踩过的坑，比如：

• 无法动态切换编码参数（码率、分辨率）
• Simulcast的API需要自己拼SDP
• 没有统一的插入式流控制接口

WebRTC Next：更远的未来

再往后看，就是WebRTC Next了。这个阶段的目标更宏大——让WebRTC成为实时通信的“通用底座”，而不仅仅是浏览器里的一个API。

你想想看，现在的WebRTC其实挺“重”的。你要建一个连接，得先搞STUN/TURN，再搞ICE，再搞DTLS，再搞SRTP……每一步都可能出问题。我在一个IoT项目里，就因为TURN服务器配置不当，导致设备在弱网下频繁断连。

WebRTC Next想做的，就是把这些复杂性封装起来，提供更高级的抽象。比如：

• WebTransport：替代WebSocket + DataChannel，基于QUIC，延迟更低。
• Insertable Streams：允许开发者直接操作编码后的视频帧，实现端到端加密。
• RTCIceTransport 增强：更细粒度的ICE状态控制。

新特性展望：哪些值得关注？

下面这几个特性，我个人觉得会在未来2-3年内改变行业玩法：

特性	状态	我的看法
Insertable Streams (E2EE)	Chrome已支持	端到端加密的标配，我在金融类项目里已经用上了
Scalable Video Coding (SVC)	部分浏览器支持	比Simulcast更优雅，但编码器支持还不全
WebTransport	实验阶段	低延迟场景的终极方案，但生态还不成熟
RTP Extensions for Absolute Capture Time	已标准化	音画同步的救星，我建议所有项目都开启

为什么会这样？因为行业需求变了。以前WebRTC主要做“两个人视频聊天”，现在大家都在做“千人会议”、“直播连麦”、“远程医疗”。这些场景对延迟、质量、安全的要求，远高于1.0时代的设计目标。

行业趋势：WebRTC正在“下沉”

我观察到几个明显的趋势：

• 从浏览器走向原生：越来越多的App用WebRTC做底层通信，而不是用私有协议。比如Discord、Zoom的某些模块。
• 从P2P走向SFU：Mesh架构基本被淘汰了，SFU成了标配。WebRTC NV的API就是为SFU设计的。
• 从音视频走向数据：DataChannel + WebTransport的组合，正在替代传统的WebSocket，用于游戏同步、实时协作。
• 从公有云走向边缘：TURN服务器部署在边缘节点，减少最后一公里的延迟。

知识体系总览

下面这张图，是我梳理的WebRTC标准演进的核心脉络。你可以把它当作一个“路线图”来参考：

避坑指南：标准演进中的常见问题

最后，分享几个我踩过的坑：

• 不要假设所有浏览器实现一致：同样的API，Chrome和Safari的行为可能不同。我建议用Adapter.js做兼容层。
• 注意SDP的版本差异：WebRTC NV引入了新的SDP属性，老版本浏览器可能不识别。我曾经因为这个导致联调失败。
• Insertable Streams的加密要自己写：API只提供了“插入点”，加密逻辑得自己实现。别以为开箱即用。
• WebTransport目前只支持Chrome：别在生产环境全面铺开，先做技术验证。