互联网视频是怎样送进千家万户的

前些天同学聚餐，有人提了个问题：很多人同时看电视不卡，同时看网上的视频直播为什么就卡呢？电视是广播（跟收音机本质一样），而互联网视频走的是点对点的 IP 网络，多一个人看视频，服务器就要多发一份数据。

互联网视频究竟是怎样送到千家万户的呢？我从通信领域顶级学术会议 SIGCOMM 2013 里窃取了一些科普知识与大家分享。

互联网视频的进化

第一阶段：1992 ~ 2004

这是互联网视频刚刚起步的年代，当时的视频主要是组织内部的，因此大家都在网络上做文章，用预留带宽、优化包调度算法之类的办法来保证视频的流畅。

对于多人视频会议这样的场景，研究者们早就想到了多一个人看视频就多一份数据的问题，于是有了 IP Multicast，视频服务器只发一个包，上面标着多个目标地址，网络设备就会把包复制若干份送到每个目标那里。

视频的分层结构就诞生于这个年代：

  1. 网络抽象层：视频传输协议或视频文件格式，如 RTP/IP 用于实时网络视频，MP4 用于视频文件存储，MMS 用于流媒体，MPEG-2 用于广播。视频文件的扩展名就是这一层的。
  2. 视频编码层：这一层决定视频流是如何被编码和压缩的，过程很复杂，这就是传说中的 codec 了，如 MPEG-2，MPEG-4 ACP，H.264/AVC，H.265/HEVC。一般越新的编码标准在相同质量的前提下压缩率越高，编码所需的计算资源也更多。如下图所示，codec 只规定了如何解码而没有规定如何编码。一般音频流和视频流是独立编码的。
    h264-1h264-1

这个年代 PC 市场刚刚起步，各公司纷纷推出私有视频标准抢占蓝海。Web 仍然是纯粹的网页浏览，视频还局限于客户端上。以 BitTorrent 为代表的 P2P 技术以整个文件的形式分发视频。

video1video1

第二阶段：2005 ~ 2011

2005 年 Youtube 创立，标志着互联网进入了在线视频时代。越来越多的传统电视台在互联网上播出，草根创作的视频打破了电视媒体的禁区。

这个年代，Flash 是互联网视频技术的事实标准。它可以在所有操作系统和浏览器上工作，使用 Adobe 的专有 RTMP 协议。Flash 也在不断改进，如 2006 年的 Flash Player 9.0 + ActionScript 3.0 采用了新的虚拟机和 JIT 编译器，提高了 Flash 执行速度10倍以上。

CDN（Content Delivery Network）技术在不断成熟，这样不用一台服务器往所有客户端发视频数据了，可以把视频数据发给 CDN 节点，再让 CDN 节点就近发给客户端，降低了单台机器的负载，更重要的是提高了用户访问视频的速度。

video4video4

第三阶段：2011 至今

2010 年，移动互联网的热潮袭来。iPhone 和 iPad 都不支持 Flash，Adobe 也在 2012 年宣布停止 Android 平台上 Flash 的支持。

现在，互联网视频要考虑四种不同的屏幕：PC、智能手机、平板、智能电视。不同的屏幕上用户行为和视频应用都有所不同。这还不说 Windows、Mac、GNU/Linux、Android、iOS、Windows Phone 等多个操作系统平台。

视频分发协议的进化

第一代：HTTP 下载

video3video3

最简单的方案是浏览器把视频下载完，再送给播放器播放。这样不仅不能直播，看一个视频还要先等很久。于是做了改进：

  1. 浏览器下载一个 meta file（元信息文件）
  2. 浏览器启动对应的播放器，把 meta file 交给它
  3. 播放器自己去跟 server 建立 TCP 连接下载视频文件，边下边播
    下面这段示例代码就是用的这种改进方案：
    <video poster="http://www.html5rocks.com/en/tutorials/video/basics/star.png" controls> <source src="http://www.html5rocks.com/en/tutorials/video/basics/Chrome_ImF.ogv" type='video/ogg; codecs="theora, vorbis"' /> </video>
    然而，简单的 HTTP 会尽可能快地下载。比如我的网速是 10Mbps，而视频的码率只有 1Mbps，则缓冲就会越积越多，浪费的系统资源和网络带宽。

此外，HTTP 下载的是一个固定码率的大文件，不能根据网络情况动态调整。如果网络条件很差，我宁愿看标清，也不愿意忍受着卡顿看高清。

第二代：专有流媒体协议

以 Adobe 的 RTSP 和 RTMP 为代表的专有流媒体协议基于 TCP 或 UDP，而非 HTTP。一般有一个控制连接，一个数据连接（就像 FTP 一样），控制连接为流媒体开始、复位、快进、暂停等提供了原生支持，不再需要用 HTTP Range Request 模拟了。

浏览器端的架构跟第一代的改进方案没有区别。服务器端维护着连接状态。

不过，专有流媒体服务器的授权价格高昂，而且所用的专有端口容易被防火墙封锁。

第三代：HTTP 流媒体

HTTP 流媒体相比第二代技术，除了端口号换成了 80，承载协议换成了 HTTP，最重要的区别是由客户端维护状态和控制逻辑，服务器无需维护状态。这本质上是 “瘦客户端” 与 “胖客户端” 之争，在服务器性能随着用户量增加越来越成问题、客户端计算资源过剩的大背景下，很多 Web 应用都把本来是服务器端做的事转移到客户端上，顺便还提高了操作的响应速度。

服务器将视频内容预先转换成不同的码率，分好块，每块都以关键帧（key frame）开始，这样块与块之间就是互相独立的。客户端通过一个 “反馈循环” 动态决定该采用怎样的码率。根据一块的下载速度估计带宽（下图左上角橙色块），选择当前带宽下最高可行的码率（绿色）。客户端决定需要下载新块的时候（蓝色），就会去下载当前码率的下一个块。

video5video5

视频为什么会卡

video2video2

大家都知道互联网视频是有 “缓冲” 的。开始看视频时，首先缓冲一定时间的内容，然后一边下载新内容一边播放，如果播放的速度高于下载速度，没有可播放的内容时，就会暂停下来下载内容，直到又缓冲了一定时间的内容，再恢复播放。

video6video6

上面提到，客户端会通过 “反馈循环” 动态调整码率。可惜的是，实验结果显示，这种反馈不会使各客户端的码率趋向平衡，而是出现了像下图一样的抖动（横坐标时间，纵坐标码率，三条线是三个客户端，黑框圈起来的是抖动剧烈的部分）

video7video7

另一个问题是客户端间的公平性。按说不论何时开始下载，得到的码率应该都差不多。但考虑如下的情况，客户端 A、B 同时开始下载，客户端C在另一个时刻开始下载。理想情况下，A、B 的下载速度永远是 1Mbps，C 的下载速度永远是 2Mbps，根据 “反馈循环” 算法，A、B 看到的码率永远比 C 低。

video8video8

究其原因，一方面是采用了高层的 HTTP 协议，只知道一个视频块的整体下载时间，而无从得知每个包的延迟；另一方面是每个客户端 “各自为政”，没有中心协调。因此，基于 HTTP 的无状态协议不是万灵药，有得必有失。

衡量视频分发的质量

传统的视频分发质量测试是计算视频的信噪比，再发一大堆调查问卷请观众打分，看这两组数据间的相关性；互联网时代，发调查问卷过时了，采用的是更加客观的指标，比如视频被播放的时长（如果视频质量不好，用户就会中途退出）；也不用信噪比这种学术味浓厚的指标了，代之以缓冲时间、平均码率等用户实际感受得到的指标。

事实上，主流视频网站都会悄悄上传一些统计信息，包括开始播放失败的次数、开始播放的缓冲时间、卡播比（播放过程中缓冲时间的比例）、缓冲速度、平均码率、显示帧率等。

video9video9

用视频被播放的时长比例作纵轴，用各种指标作横轴，就得到了如下图所示的曲线：

video10video10

显然，卡播比（Buffering Ratio）对用户体验的影响最大，也就是比开始播放时间、码率、显示帧率等都更重要。另一项研究显示，卡播比每增加 1%，用户播放时间就会降低 3 分钟。

video14video14

当然，相关不意味着因果。是否有可能是某些因素的组合比任何单个因素都重要呢？这些因素之间是否有相关性呢？可以用 information gain 等方法来深入探究。（让我想起了概率论与数理统计课程……）

该用哪个 CDN 节点？

在天朝这种运营商互联互通极差的环境里，CDN 显得尤为重要。简单想想也是，就近下载肯定比从远处下载要好。问题是，大型视频网站会在多地、多个 ISP 部署 CDN 节点，如何决定哪个节点是 “就近” 呢？

互联网由于管理的需要，将 IP 地址划分为数千个 “自治区域”（Autonomous System），每个自治区域有一个唯一的编号（ASN）。一个自治区域一般归属一个组织，例如科大就是一个自治区域。如果两个客户端位于同一个自治区域，则基本可以肯定它们属于同一运营商。

只根据自治区域号（ASN）还是不够的，因为同一个自治区域有可能横跨大江南北，这样不同地理位置理应访问地理上比较近的 CDN 节点。因此，还需要基于 GeoIP 数据库，划分若干目标用户区域（Designed Market Area，DMA）。

对每个（ASN，DMA，CDN）三元组，统计卡播比、开始播放时间、失败率等指标，得出如下所示的图（左右两侧各是一个 CDN 节点）：

video11video11 video12video12

对每个（ASN，DMA）组合，取出最优的 CDN 节点，就得到了想要的 CDN 分发方案。当然，这里没有讨论时间的影响，有些地区白天和晚上的网络情况还不一样，此时可以做更细粒度的分析。

video13video13

互联网视频的生态系统

几个月前，几家运营商联合宣称微信要收费，引发了一场舆论风暴。事实上，我们应该从一个生态系统的角度看待这个问题，因为链条中的任何一个环节都不可能做亏本生意。例如互联网视频就是由版权提供商、平台提供商、CDN 提供商、网络运营商、最终用户、广告商等多种实体构成的生态系统。

video15video15

随着视频占据互联网流量越来越大的比例（如今已经达到一半以上，还在不断增长），互联网视频对整个互联网基础架构的压力再也不能等闲视之了。生态系统中的各方共同进化，将是互联网视频发展的必然趋势。

本文回顾了互联网视频的进化、视频分发协议的进化，讨论了视频卡顿背后的原因和解决方案，以及如何选择 CDN 节点。我们也看到了越来越多样化的客户端平台、越来越大的视频市场，以及现有网络架构给视频分发带来的一系列问题。本人才疏学浅，也不是专业做这个的，欢迎批评指正 和/或 深入讨论。

References

  1. Internet Video: Past, Present and Future. http://conferences.sigcomm.org/sigcomm/2013/ttliv.php
  2. Overview of the H.264/AVC video coding standard. http://ip.hhi.de/imagecom_G1/assets/pdfs/csvt_overview_0305.pdf

Comments

▲