Page 323 - Web性能权威指南

最终结果就是，仅仅一条端到端的音频和视频流，就会占用大部分的用户带宽，而
移动客户端就是更如此了。那如果是多方流呢？肯定需要对可用带宽有一个明确的
把握：

• 移动客户端或许可以下载高清流（1 Mbit/s 以上），但囿于上行吞吐量，或许只能
发送低品质流，即不同通信端接收和发送流的比特率不同；
• 音 频 和 视 频 流 可 能 需 要 与 其 他 应 用 和 数 据 传 输 服 务 共 享 带 宽， 比 如 多 个
DataChannel 会话；
• 带宽和延迟一直在变，与连接类型（有线或无线）或者第几代网络无关，因此应
用必须能适应这些变化。

好在 WebRTC 的音频和视频引擎会与底层的网络传输组件协同，去探测可用带宽，
从而优化媒体流的交付。可是，DataChannel 还需要额外的应用逻辑：应用必须监
控缓冲区中的数据量，随时准备按需作出调整。

在采集音频和视频流时，一定要将视频约束设置为与使用场景匹配，参见
18.2 节中的“通过 getUserMedia 获取音频和视频”。

18.7.2 多方通信架构

一个双向发送高清媒体流的端到端连接，很容易耗尽用户的带宽。为此，对于多方
通信的场景，就更应该仔细考虑其架构了（图 18-17），特别是单个流如何汇聚，以
及如何在端与端之间分发。

ມၠࢬঢ ຺ၠࢬঢ ຺ၠࢬঢ ຺ၠࢬঢ
኱૶ ྪጒྪஏ ႓ႚྪஏ णዐݴ݀

图 18-17：N 向呼叫的分布式架构

WebRTC ｜ 313