Page 326 - Web性能权威指南

可惜的是，对于传输任意数据的 DataChannel 而言就没有那么简单了。与 WebSocket
类似，DataChannel API 可以接收二进制或 UTF-8 编码的应用数据，但它不能压缩
数据：优化二进制净荷和压缩 UTF-8 数据是 WebRTC 应用的事。

此外，WebSocket 运行在可靠有序的传输协议之上，而 WebRTC 应用必须考虑 UDP、
DTLS 和 SCTP 协议产生的额外开销，以及在部分可靠的连接上交付数据的各种问
题（参见 18.6.3 节“部分可靠交付与消息大小”）。

WebSocket 有一个协议扩展，支持对传输数据的自动压缩。然而，WebRTC
没有类似的扩展。因此，应用提供什么消息，它就传输什么消息。

18.8 性能检查表

端到端的架构对应用设计提出了独特的挑战。直接、一对一的通信相对简单，而参
与端越多，问题就越复杂，至少对性能来说如此。最后，我们给出有助于提高端到
端 WebRTC 应用性能的一些注意事项。

• 发信服务
Œ 使用低延迟传输机制；
Œ 提供足够的容量；
Œ 建立连接后，考虑使用 DataChannel 发信。
• 防火墙和NAT穿越
Œ 初始化 RTCPeerConnection 时提供 STUN 服务器；
Œ 尽可能使用增量 ICE，虽然发信次数多，但建立连接速度快；
Œ 提供 STUN 服务器，以备端到端连接失败后转发数据；
Œ 预计并保证 TURN 转发时容量足够用。
• 数据分发
Œ 对于大型多方通信，考虑使用超级节点或专用的中间设备；
Œ 中间设备在转发数据前，考虑先对其进行优化或压缩。
• 数据效率
Œ 对音频和视频流指定适当的媒体约束；
Œ 优化通过 DataChannel 发送的二进制净荷；
Œ 考虑压缩通过 DataChannel 发送的 UTF-8 数据；
Œ 监控 DataChannel 缓冲数据的量，同时注意适应网络条件变化。

316 ｜ 第 18 章