Page 322 - Web性能权威指南

端到端之间的丢包和延迟难以预测，会因当时的网络环境而变化。因此，对于重传
次数，或者超时间隔，并没有唯一的最优答案。为了通过不可靠信道达成最佳结果，
请尽量减少消息大小。

18.7 WebRTC使用场景及性能

实现低延迟、端到端的传输可不是件轻而易举的事，它涉及 NAT 穿越和连接检查、信
号发送、安全加密、拥塞控制及大量其他必须考虑到的细节。WebRTC 为我们处理了
上述所有这些， 而且还不止这些。正因为如此，WebRTC 自问世起就被人们追捧为对
Web 平台有史以来最重要的补充。关键在于，WebRTC 不仅是实现了这些功能，而且
保证了所有组件协同工作，为我们在浏览器中构建端到端应用提供了简单统一的 API。

不过，即便有了内置的服务，设计高效高性能的端到端应用仍然需要周密考虑和规
划：端到端本身并不代表高性能。如果说有什么不同，那就是端到端之间的带宽和
延迟越来越多变，对媒体传输的需求日益增长，以及不可靠交付的诸多特性反倒进
一步增加了这种应用的构建难度。

18.7.1 音频、视频和数据流

端到端的音频和视频流是 WebRTC 最主要的使用场景之一：getUserMedia API 可以
让应用获取媒体流，而内置的音频和视频引擎负责处理优化、错误恢复和流之间的
同步。不过不要忘了，即便经过十分激进的优化和压缩，音频和视频交付依旧可能
受到延迟和带宽的限制：

• 高清的流至少需要 1~2 Mbit/s 带宽，参见 18.2 节中的“音频（Opus）与视频（VP8）
比特率”；
• 截至 2013 年第一季度，全球平均带宽只有 3.1 Mbit/s，参见表 1-2；
• 高清的流至少要求 3.5G+ 的连接，参见表 7-2。

好消息是，世界平均带宽一直在稳步增长：用户正在向宽带转移，而 3.5G+ 和 4G
网络的应用速度也在加快。可是，就算乐观估计，也只能说高清流在今天是可行的，
还不能说有保证！类似地，延迟是一个老生常谈的问题，特别是对实时交付以及移
动客户端，延迟的问题更加严重。4G 当然好，但 3G 网络要退出历史舞台也不是一
朝一夕的事。

更严重的是，大多数 ISP 和移动运营商提供的连接并不对称：大多数用户
的下行吞吐量明显高于上行吞吐量。事实上，10∶1 的比例不在少数，也就
是说下载 10 Mbit/s，上传只有 1 Mbit/s。

312 ｜ 第 18 章