Page 325 - Web性能权威指南
P. 325
WebRTC 把发信功能留给应用实现，这意味着应用最低限度也要实现两端的消息发
送和接收逻辑。发信数据量因用户数量、协议、数据编码和更新频率而异。类似地，
发信服务的延迟对“呼叫建立”时间（尤其是使用增量 ICE 的时候）及其他发信交
换性能影响极大。
• 使用低延迟的传输方案，比如 WebSocket 或基于 XHR 的 SSE。
• 估计并提供足够的容量，以满足所有应用必需的信号发送速率。
• 可选地，建立连接后，各端可以切换到 DataChannel 来发信。这样可以转移中心
服务器必须处理的发信流量，也会减少发信过程的延迟。
由于 NAT 和防火墙的广泛存在，大多数 WebRTC 应用都将需要 STUN 服务器来执
行 IP 查找，从而建立端到端连接。好在，只有连接设置阶段才需要 STUN 服务器，
但无论如何，它都必须采用 STUN 协议且随时可用，以处理必要的查询。
• 除非 WebRTC 应用只在同一内部网络中使用，否则始终都要在 RTCPeerConnection
对象中提供 STUN 服务器；不然，大多数连接会直接失败。
• 与发信服务器可以使用任何协议不同，STUN 服务器必须响应 STUN 请求。可以
选择一台公共服务器，也可以自己配置；stund 就是一个流行的开源实现。
即便有了 STUN，8%~10% 的端到端连接也可能由于网络策略存在的各种问题而失
败。比如，网络管理员可能会屏蔽网络中所有用户的 UDP 数据报（参见 3.2.3 节中
的“现实中的 STUN 和 TURN”）。为此，要保证用户体验，应用可能还需要一台
TURN 服务器在端与端之间转发数据。
• 转发数据是一种次优选择：转发就会导致多余的网络跳跃，而在每个流占用 1
Mbit/s 带宽的情况下，任何服务都可能很快被耗尽带宽。所以，TURN 应该是没
有办法的办法，实在不行才用，而且即便用，也要仔细对待容量规划问题。
多方服务可能需要集中式基础设施来辅助优化多个流的交付，从而成为 RTC 体验的
一部分。很多时候，多方网关会扮演与 TURN 相同的角色，但这里的需求不同。话
虽如此，但与 TURN 服务器充当简单的分组代理不同，这些“智能代理”在向各端
转发最终输出前，可能要占用更多 CPU 和 GPU 资源来处理每一个流。
18.7.4 数据效率及压缩
WebRTC 音频和视频引擎会根据端与端之间的网络条件动态调整媒体流的比特率。
应用可以设置和更新媒体约束（比如，视频的解析度、帧速率，等等），剩下的事交
给引擎就好了——这一块很简单。
WebRTC ｜ 315
