一、数据通道的标准化之路
聊到数据通道的扩展与未来，我得先说说它的「根」。
很多人用 WebRTC 数据通道，却不知道它背后站着两个关键文档：RFC 8831 和 RFC 8832。这两个 RFC 在 2021 年正式发布，把数据通道从「实验性功能」推向了「正式标准」。
我个人习惯把 RFC 8831 叫做「数据通道的骨架」，它定义了数据通道的核心协议——也就是数据怎么打包、怎么传输、怎么保证可靠性。而 RFC 8832 呢？它更像「数据通道的神经系统」，专门负责数据通道的建立流程，也就是我们常说的 SCTP 关联的建立。
嗯，这里要注意：RFC 8831 和 RFC 8832 其实是把之前零散的标准整合到了一起。我在项目中遇到过不少团队，他们用的 WebRTC 库版本比较老，结果发现数据通道的行为跟新标准对不上。说白了，就是踩了「标准演进」的坑。
1.1 RFC 8831：数据通道的传输基石
RFC 8831 的全称是「WebRTC 数据通道协议」。它规定了数据通道必须基于 SCTP（流控制传输协议） 来构建。为什么选 SCTP？因为它同时支持可靠传输和部分可靠传输，还能做到消息边界保留。
你想想看，TCP 虽然可靠，但它是流式的，没有消息边界。UDP 有消息边界，但不可靠。SCTP 正好结合了两者的优点——它既有消息边界，又能选择可靠或不可靠模式。
我在项目中遇到过这样一个场景：一个实时协作工具，需要传输 JSON 格式的操作指令。如果用 TCP，消息可能会粘包，需要自己拆包。用 SCTP 就简单了，每条消息天然独立，直接收就行了。
RFC 8831 还定义了两种数据通道类型：
- 数据通道（Data Channel）：基于 SCTP 的流（Stream），每个数据通道对应一个 SCTP 流。
- 数据通道的建立：通过带外（SDP）或带内（数据通道协议）方式协商。
1.2 RFC 8832：数据通道的建立流程
RFC 8832 定义了数据通道的建立协议，也就是 DCEP（数据通道建立协议）。它解决了一个核心问题：两个浏览器之间怎么协商数据通道的参数？
DCEP 使用了一种叫「带内协商」的方式。什么意思呢？就是数据通道的建立消息直接在 SCTP 连接内部传输，不需要通过信令服务器。
我记得第一次看 DCEP 的规范时，觉得它设计得很巧妙。它定义了四种控制消息：
| 消息类型 | 用途 | 我的经验 |
|---|---|---|
| DATA_CHANNEL_OPEN | 发起方请求建立数据通道 | 注意消息中的通道类型字段，决定了后续行为 |
| DATA_CHANNEL_ACK | 接收方确认建立 | 如果没收到 ACK，数据通道会一直处于 connecting 状态 |
| DATA_CHANNEL_OPEN | 重新打开已关闭的通道 | 这个用得少，但某些场景下很有用 |
| DATA_CHANNEL_CLOSE | 关闭数据通道 | 一定要发送，否则对端不知道通道已关闭 |
为什么会这样设计？因为带内协商可以避免信令服务器的延迟。你想想看，如果每次建立数据通道都要经过信令服务器，那延迟就大了。DCEP 直接在 SCTP 连接内部搞定，快得多。
二、WebRTC NV 新特性
说完了标准，咱们聊聊未来。WebRTC NV（Next Version）是 WebRTC 的下一个重大演进。它带来了一些让人兴奋的新特性，尤其是对数据通道的增强。
我个人觉得，最值得关注的有三个方向：
- 更灵活的 SCTP 配置：允许开发者自定义 SCTP 参数，比如最大消息大小、重传次数等。
- 数据通道的优先级：可以为不同的数据通道设置优先级，高优先级的消息优先发送。
- 数据通道的流控制：更精细的流控制机制，避免数据拥塞。
2.1 更灵活的 SCTP 配置
在现有的 WebRTC 实现中，SCTP 的参数是固定的。比如最大消息大小是 64KB，重传次数是 5 次。但在某些场景下，这些默认值并不合适。
举个例子：如果你在传输大文件，64KB 的限制意味着你需要自己分片。如果 WebRTC NV 允许你调整这个参数，那就可以直接传输更大的消息，省去分片和组装的麻烦。
我在项目中遇到过类似的问题：一个远程桌面应用，需要传输屏幕截图。每张截图大概 200KB，但数据通道一次只能发 64KB。没办法，我只能自己写分片逻辑。如果 WebRTC NV 支持更大的消息，那就省事了。
2.2 数据通道的优先级
这个特性我特别期待。在现有的数据通道中，所有消息的优先级是一样的。但在实际应用中，有些消息比另一些更重要。
比如一个在线游戏：玩家的操作指令需要低延迟，而游戏资源的加载可以容忍稍高的延迟。如果数据通道支持优先级，就可以把操作指令设为高优先级，资源加载设为低优先级。
WebRTC NV 可能会引入一个 priority 属性，取值范围从 0 到 255，数值越高优先级越高。高优先级的消息会在低优先级消息之前发送。
2.3 数据通道的流控制
流控制是数据通道的一个老大难问题。现有的实现中，如果发送方太快，接收方来不及处理，就会导致数据积压，甚至丢包。
WebRTC NV 可能会引入更精细的流控制机制，比如基于 SCTP 的接收窗口大小动态调整发送速率。说白了，就是让发送方知道接收方「吃不吃得消」，然后自动调整发送速度。
我记得在做一个视频会议的白板功能时，就遇到了这个问题。多个用户同时画图，数据通道瞬间被塞满，结果后面的消息全丢了。如果当时有流控制，就不会这么狼狈了。
三、知识体系总览
说了这么多，我画了一张图来总结本章的知识体系。你可以把它当作一个「地图」，方便后续深入学习。
四、总结与思考
数据通道的标准化和未来演进，说白了就是让开发者用起来更顺手、更强大。RFC 8831 和 RFC 8832 把基础打牢了，WebRTC NV 则是在这个基础上加「翅膀」。
我个人觉得，作为开发者，你现在就应该开始关注这些变化。不是因为它们马上就会落地，而是因为你可以提前规划你的架构。比如，如果你现在就开始用 SCTP 的流概念来组织数据，未来迁移到 WebRTC NV 就会很平滑。
最后，我想说一句：技术总是在演进，但核心原理不会变。理解了 SCTP、DCEP 这些底层机制，不管标准怎么变，你都能快速跟上。
公众号:蓝海资料掘金营，微信 deep3321