Page 321 - Web性能权威指南
P. 321
➐ 乱序不可靠交付（UDP）
➑ 使用指定的配置初始化 DataChannel
初始化 DataChannel 之后，应用可以访问 maxRetransmits 和 maxRetrans-
mitTime 这两个只读属性。同样，为方便起见，DataChannel 也提供了一
个 reliable 属性，只要使用了部分可靠策略，这个属性就会返回 false。
每个 DataChannel 可以使用不同的自定义参数（可靠性及是否有序）来配置，每一
端可以打开多个信道，这些信道都是通过对相同的 SCTP 关联多路复用实现的。结
果，信道之间相互独立，可以分别用于传输不同类型的数据。比如，可靠有序的信
道可用于聊天，部分可靠且乱序的交付可用于传输瞬时或低优先级的应用更新。
18.6.3 部分可靠交付与消息大小
要使用部分可靠的信道，需三思而后行。尤其是，应用必须密切关注消息大小：应
用传输的数据可能很大，因此会被分段封装到多个分组中，而这很可能导致难以接
受的结果。为说明这个问题，假设有以下场景。
• 两端协商好了一个乱序不可靠的 DataChannel。
信道的 maxRetransmits 为 0，即纯粹是 UDP。
• 丢包率大约为 1%。
• 其中一端想要发送一个 120 KB 的大消息。
WebRTC 客户端将 SCTP 分组的最大传输单位设置为 1280 字节，这是针对 IPv6 分
组推荐的 MTU。但我们也必须考虑到 IP、UDP、DTLS 和 SCTP 协议的开销，分别
是 20~40 字节、8 字节、20~40 字节和 28 字节，加起来大约为 130 字节。这样每个
分组就剩下大约 1150 字节给数据净荷。因此，120 KB 应用消息总共需要 107 个分
组（120×1024/1150）。
现在还看不出有问题，但每个分组丢失的概率为 1%。如果我们通过不可靠信道发
送全部 107 个分组，那么极有可能在中途会丢失其中一个！这会导致什么结果呢？
即使仅仅丢失一个分组，整个消息也会被抛弃。
为解决这个问题，应用有两个选择：可以使用重传策略（计数或超时），或者减少消
息大小。事实上，为了获得最佳结果，应该双管齐下。
• 在使用不可靠信道时，理想情况下，每个消息都应该可以封装到一个分组中。换
句话说，消息应该小于 1150 字节。
• 如果消息不能封装到一个分组中，则需要使用重传策略，以提高交付消息的成功率。
WebRTC ｜ 311
