数据通道的可靠性与模式：可靠 vs 不可靠传输、ordered vs unordered、maxRetransmits 与 maxPacketLifeTime 配置
聊到 WebRTC 数据通道，很多人第一反应是「哦，就是那个能传文件的」。但真正用起来，你会发现坑不少。尤其是可靠性这块，配置错了，轻则丢数据，重则整个业务逻辑崩掉。
我个人习惯把数据通道的配置比作「快递服务」。你可以选顺丰（可靠、按顺序送达），也可以选普通快递（可能丢件、可能乱序）。WebRTC 给了你完全的控制权，但前提是——你得懂每个参数到底在干什么。
可靠 vs 不可靠：你要不要保证数据一定到达？
先说最核心的区别。可靠传输，说白了就是「不丢包」。底层用的是 SCTP 协议，配合重传机制，确保每个数据包都到达对端。不可靠传输呢？丢了就丢了，不重传。
我在项目中遇到过这样一个场景：做一款实时协作的白板工具。笔迹数据必须可靠，一笔一划都不能丢，否则画出来的图形是残缺的。但光标位置数据呢？丢了就丢了，下一帧马上补上，用不可靠传输反而更流畅。
你想想看，如果视频聊天里每一帧画面都要可靠传输，那卡顿得没法用。但文件传输你敢用不可靠吗？不敢。所以选哪种，完全看业务场景。
ordered vs unordered：数据到达的顺序重要吗？
ordered 模式，数据按发送顺序到达对端。unordered 模式，谁先到谁先处理，顺序不重要。
嗯，这里要注意：ordered 不等于可靠。你可以配置「可靠 + ordered」，也可以配置「不可靠 + unordered」，甚至「可靠 + unordered」也行。这四个组合，覆盖了绝大多数场景。
| 模式组合 | 适用场景 | 我踩过的坑 |
|---|---|---|
| 可靠 + ordered | 文件传输、聊天消息 | 大文件分片传输时，如果某一片重传，后续所有片都得等，体验很差 |
| 可靠 + unordered | 游戏状态同步 | 每个状态包独立，不需要等前面的包，但必须保证每个包都到 |
| 不可靠 + ordered | 实时字幕、日志流 | 这个组合其实很少用，因为不可靠还要保证顺序，逻辑上有点拧巴 |
| 不可靠 + unordered | 音视频数据、光标位置 | 最常用的组合，延迟最低，丢几个包无所谓 |
我曾经做过一个联机小游戏，角色移动指令用了「可靠 + ordered」。结果网络波动时，玩家按了三次方向键，第三个指令因为前两个还没重传成功，一直卡在那。角色原地不动，玩家气得摔手机。后来改成「不可靠 + unordered」，反而流畅了——偶尔丢一两个指令，下一帧补上就行。
maxRetransmits 与 maxPacketLifeTime：两个关键参数
这两个参数，是控制「不可靠」到底有多不可靠的。很多人搞混，我当年也栽过跟头。
maxRetransmits： 最大重传次数。比如设为 3，表示最多重传 3 次，还失败就放弃。注意，这个参数只在不可靠模式下生效。
maxPacketLifeTime： 数据包的最大存活时间，单位毫秒。超过这个时间还没送达，直接丢弃。比如设为 1000，表示 1 秒内没送到就不要了。
为什么不能同时设置？我简单解释一下：重传次数和时间是两个维度的控制。如果同时设，协议不知道以哪个为准。比如重传了 2 次但时间已经超了，是继续重传还是放弃？逻辑上会打架。所以 Chrome 和 Firefox 的实现都强制互斥。
我个人习惯：对延迟敏感的场景用 maxPacketLifeTime，对可靠性要求稍高的用 maxRetransmits。举个例子——
// 不可靠 + unordered + 最大存活时间 500ms
const dc = peerConnection.createDataChannel('cursor', {
ordered: false,
maxPacketLifeTime: 500
});
// 不可靠 + unordered + 最多重传 3 次
const dc2 = peerConnection.createDataChannel('gameState', {
ordered: false,
maxRetransmits: 3
});你看，代码写起来很简单，但背后的逻辑要想清楚。我见过有人把 maxRetransmits 设成 0，以为这样就是「不可靠不重传」。结果呢？设成 0 表示「不重传」，但数据还是会尝试发送一次。如果网络不好，直接就丢了。这其实等价于「尽力而为的一次性投递」。
一张图看懂数据通道的配置逻辑
说了这么多，我画了张图帮你理清思路。从创建数据通道开始，到选择可靠/不可靠，再到 ordered/unordered，最后到两个参数的取舍——整个决策路径一目了然。
实际项目中的配置建议
说了这么多理论，来点实际的。我整理了几种常见场景的推荐配置，你可以直接参考：
- 文件传输： 可靠 + ordered。别想别的，文件丢一个字节都不行。
- 实时游戏状态： 不可靠 + unordered + maxRetransmits=2。允许丢少量包，但尽量抢救一下。
- 光标/鼠标位置： 不可靠 + unordered + maxPacketLifeTime=200。200ms 没送到就不要了，下一帧马上来。
- 聊天消息： 可靠 + ordered。消息顺序错了会闹笑话的。
- 日志流： 不可靠 + ordered + maxPacketLifeTime=1000。日志可以丢，但顺序尽量保持。
嗯，最后提醒一句：配置不是越可靠越好。我见过有人把所有数据通道都配成「可靠 + ordered」，结果视频通话的体验反馈数据把网络堵死了。该丢的就让它丢，这是 WebRTC 的精髓。