Page 102 - Web性能权威指南

对视频而言，资源可能会使用多种比特率编码和存储，然后切割为多个部分（比
如，YouTube 视频会分成多个 5~10 s 的块）。然后，在客户端下载视频流期间，客
户端或服务器可以监控每个视频块的下载速度，必要时根据带宽的变化调整要下
载的下一个视频块的比特率。事实上，现实中的视频服务，开始一般是低比特率
的视频块，以便视频播放能更快开始。然后，再根据可用带宽的动态变化调整后
续视频块的比特率。
每个资源要分别创建多少个比特率版本呢？取决于你的应用！不过，我可以告诉
你，Netflix 为适应不同的屏幕大小和可用带宽，为每个视频流都创建了超过 120
个版本！让用户有流畅感、实时感，可真不是件简单的事儿。

6.4.3 适应可变的延迟时间

Wi-Fi 既不保证带宽，也不保证第一跳的延迟时间。如果要经过不止一跳（比如使
用无线网桥作为接入点时），那预测延迟时间就更困难了。

理想情况下，如果没有干扰并且网络不满载，那么第一跳的延迟时间不会超过 1 ms，
而且非常稳定。然而，现实当中，特别是高密度的城区或办公楼环境下，几十个
Wi-Fi 接入点和客户端会形成激烈的频率争用局面。

结果，第一跳中值 1~10 ms，后续中继的延迟时间 10~50 ms 都是合理的。在比较糟
糕的情况下，高达几百毫秒也并非不可能。

如果你的应用最怕高延迟，那就要考虑在通过 Wi-Fi 运行时怎么调整其行为。事
实上，有时候使用提供不可靠 UDP 传输的 WebRTC 倒不失为一个明智的选择。
当然，传输方式的切换不能挽救无线网络，但却有助于降低协议和应用导致的延
迟时间。

86 ｜ 第 6 章