根据许多估计，流媒体视频（streaming video）（包括 Netflix、YouTube 和 Amazon Prime）在 2020 年约占互联网流量的 80% [Cisco 2020]。 本节我们将概述流行的视频流服务是如何在当今的互联网中实现的。 我们将看到它们是使用应用程序级协议和服务器实现的，这些协议和服务器的功能类似于缓存。

2.6.1 互联网视频 Internet Video

在流式存储视频应用程序（streaming stored video applications）中，底层媒体是预先录制的视频，例如电影、电视节目、预先录制的体育赛事或预先录制的用户生成的视频（例如在 YouTube 上常见的视频）。 这些预先录制的视频放置在服务器上，用户向服务器发送请求以观看视频。 如今，许多互联网公司都提供流媒体视频，包括 Netflix、YouTube (Google)、亚马逊和 TikTok。
但在开始讨论视频流之前，我们应该首先快速了解视频媒体本身。 视频是一系列图像，通常以恒定速率显示，例如每秒 24 或 30 个图像。 未压缩的数字编码图像由像素阵列组成，每个像素被编码为若干位以表示亮度和颜色。 视频的一个重要特性是它可以被压缩，从而在视频质量与比特率之间进行权衡。 今天的现成压缩算法（off-the-shelf compression algorithms）可以将视频压缩到任何所需的码率（bit rate）。 当然，码率越高，图像质量越好，整体用户观看体验也越好。
从网络的角度来看，视频最显着的特征可能是其高码率。 压缩互联网视频的范围通常从 100 kbps 的低质量视频到超过 4 Mbps 的流式高清电影； 4K 流媒体设想的比特率超过 10 Mbps。 这可以转化为大量的流量和存储，特别是对于高端视频。 例如，一个持续时间为 67 分钟的 2 Mbps 视频将消耗 1 GB 的存储和流量。 到目前为止，流式视频最重要的性能指标是平均端到端吞吐量（average end-to-end throughput）。 为了提供连续播放，网络必须为流媒体应用程序提供至少与压缩视频的码率一样大的平均吞吐量。
我们还可以使用压缩来创建同一视频的多个版本，每个版本都具有不同的质量级别。 例如，我们可以使用压缩来创建相同视频的三个版本，速率分别为 300 kbps、1 Mbps 和 3 Mbps。 然后，用户可以根据他们当前的可用带宽来决定他们想要观看哪个版本。 拥有高速互联网连接的用户可能会选择 3 Mbps 版本； 使用智能手机通过 3G 观看视频的用户可能会选择 300 kbps 版本。

2.6.2 HTTP流和DASH HTTP Streaming and DASH

在 HTTP 流中，视频只是作为具有特定 URL 的普通文件存储在 HTTP 服务器上。 当用户想要观看视频时，客户端会与服务器建立 TCP 连接，并向该 URL 发出 HTTP GET 请求。 然后，服务器在底层网络协议和流量条件允许的情况下尽快在 HTTP 响应报文中发送视频文件。 在客户端，字节收集在客户端应用程序缓冲区中。 一旦该缓冲区中的字节数超过预定阈值，客户端应用程序就会开始播放——具体来说，流视频应用程序（streaming video application）会定期从客户端应用程序缓冲区抓取视频帧（video frames），解压缩这些帧，然后将它们显示在用户屏幕上。 因此，视频流应用程序正在显示视频，因为它正在接收和缓冲与视频的后面部分相对应的帧。
虽然 HTTP 流，如上一段所述，已在实践中广泛部署（例如，自 YouTube 成立以来），但它有一个主要缺点：所有客户端都会收到相同的视频编码，尽管在不同客户端之间以及同一客户端随着时间的推移，客户端可用的带宽量存在很大差异。 这导致了一种新型的基于 HTTP 的流媒体的开发，通常称为基于 HTTP 的动态自适应流媒体 (Dynamic Adaptive Streaming over HTTP，DASH)。 在 DASH 中，视频被编码成几个不同的版本，每个版本具有不同的码率，相应地，质量级别也不同。 客户端动态请求几秒长的视频片段块。 当可用带宽量很大时，客户端自然会从高速率版本中选择块； 当可用带宽较低时，自然会选择低速率版本。 客户端使用 HTTP GET 请求消息一次选择一个不同的块 [Akhshabi 2011]。
DASH 允许具有不同 Internet 访问速率的客户端以不同的编码速率流式传输视频。 具有低速 3G 连接的客户端可以接收低码率（和低质量）版本，而具有光纤连接的客户端可以接收高质量版本。 如果可用的端到端带宽在会话期间发生变化，DASH 还允许客户端适应可用带宽。 此功能对于移动用户尤其重要，他们通常会看到他们的带宽可用性随着他们相对于基站的移动而波动。
使用 DASH，每个视频版本都存储在 HTTP 服务器中，每个版本都有不同的 URL。 HTTP 服务器还有一个清单文件（manifest file），它提供每个版本的 URL 及其码率。 客户端首先请求清单文件并了解各种版本。 然后，客户端通过在 HTTP GET 请求报文中为每个块（chunk）指定 URL 和字节范围，一次选择一个块。 在下载块时，客户端还会测量接收到的带宽并运行速率确定算法（rate determination algorithm）来选择下一个要请求的块。 自然地，如果客户端缓冲了大量视频并且测量的接收带宽很高，它将从高比特率版本中选择一个块。 自然地，如果客户端缓冲的视频很少并且测量的接收带宽很低，它会从低比特率版本中选择一个块。 因此，DASH 允许客户端在不同质量级别之间自由切换。

2.6.3 内容分发网络 Content Distribution Networks

如今，许多互联网视频公司每天都在向数百万用户分发点播多 Mbps 流。 例如，YouTube 拥有数亿个视频库，每天向世界各地的用户分发数亿个视频流。 将所有这些流量传输到世界各地，同时提供连续播放和高交互性显然是一项具有挑战性的任务。
对于互联网视频公司来说，提供流媒体视频服务最直接的方法可能是建立一个单一的海量数据中心，将所有视频存储在数据中心，然后将视频从数据中心直接传输到全球客户。 但是这种方法存在三个主要问题。 首先，如果客户端远离数据中心，服务器到客户端的数据包将跨越许多通信链路并可能通过许多 ISP，其中一些 ISP 可能位于不同的大陆。 如果这些链路之一提供的吞吐量低于视频消耗速率（video consumption rate），则端到端吞吐量也将低于消耗速率，从而导致用户恼人的冻结延迟（freezing delays）。（回忆第 1 章，流的端到端吞吐量受瓶颈链路的吞吐量控制。）这种情况发生的可能性随着端到端路径中链路数量的增加而增加。 第二个缺点是流行的视频可能会通过相同的通信链路多次发送。 这不仅浪费了网络带宽，而且 Internet 视频公司本身也将向其提供商 ISP（连接到数据中心）支付费用，以便一遍又一遍地将相同的字节发送到 Internet。 此解决方案的第三个问题是，单个数据中心代表单点故障（single point of failure）——如果数据中心或其与 Internet 的链接出现故障，它将无法分发任何视频流。
为了应对向分布在世界各地的用户分发大量视频数据的挑战，几乎所有主要的视频流公司都使用内容分发网络 (Content Distribution Networks，CDNs)。 CDN 管理分布在多个地理位置的服务器，在其服务器中存储视频（以及其他类型的 Web 内容，包括文档、图像和音频）的副本，并尝试将每个用户请求定向到将提供最佳用户体验的 CDN 位置。 CDN可以是私有CDN（private CDN），即由内容提供商自己拥有； 例如，谷歌的 CDN 分发 YouTube 视频和其他类型的内容。 CDN也可以是代表多个内容提供商分发内容的第三方CDN（third-party CDN）； Akamai、Limelight 和 Level-3 都运营第三方 CDN。 现代 CDN 的一个非常易读的概述是 [Leighton 2009; 尼格伦 2010]。
CDN 通常采用两种不同的服务器放置理念之一 [Huang 2008]：

• 深入（Enter Deep）。 Akamai 首创的一种理念是深入（enter deep）互联网服务提供商（Internet Service Providers）的接入网络，通过在全球接入 ISP 中部署服务器集群。 （访问网络在 1.3 节中进行了描述。）Akamai 在数千个位置的集群中采用了这种方法。 目标是接近最终用户，从而通过减少最终用户与其接收内容的 CDN 服务器之间的链路和路由器数量来改善用户感知的延迟和吞吐量。 由于这种高度分布式的设计，维护和管理集群的任务变得具有挑战性。
• 带回家（Bring Home）。 Limelight 和许多其他 CDN 公司采用的第二个设计理念是通过在较少数量（例如数十个）站点上构建大型集群（cluster）来将 ISP 带回家。 这些 CDN 通常不会进入接入 ISP 内部，而是将其集群放置在 Internet 交换点 (Internet Exchange Points，IXP) 中（请参阅第 1.3 节）。 与深入设计理念相比，带回家设计通常会导致更低的维护和管理开销，可能会以更高的延迟和更低的最终用户吞吐量为代价。

一旦其集群就位，CDN 就会跨集群复制内容。 CDN 可能不想在每个集群中放置每个视频的副本，因为有些视频很少被查看或仅在某些国家/地区流行。 事实上，许多 CDN 不会将视频推送到其集群，而是使用简单的拉取策略（pull strategy）：如果客户端从还没有存储所指定的视频的集群请求视频，则该集群检索视频（从中央存储库或另一个集群) 并在本地存储副本，同时将视频流式传输到客户端。 类似的 Web 缓存（参见第 2.2.5 节），当集群的存储空间已满时，它会删除不经常请求的视频。

CDN运作 CDN Operation

确定了部署 CDN 的两种主要方法后，现在让我们深入了解 CDN 的运作方式。 当用户主机中的浏览器被指示检索特定视频（由 URL 标识）时，CDN 必须拦截（intercept）该请求，以便它可以 (1) 确定一个适合该客户端的CDN服务器集群，以及 (2 ) 将客户端的请求重定向到该集群中的服务器。 我们将很快讨论 CDN 如何确定合适的集群。 但首先让我们检查拦截和重定向请求（intercepting and redirecting a request）背后的机制。
大多数 CDN 都利用 DNS 来拦截和重定向请求； [Vixie 2009] 对 DNS 的这种使用进行了有趣的讨论。 让我们考虑一个简单的例子来说明 DNS 通常是如何参与的。 假设内容提供商 NetCinema 聘请第三方 CDN 公司 KingCDN 将其视频分发给其客户。 在 NetCinema 网页上，每个视频都被分配了一个 URL，其中包含字符串“video”和视频本身的唯一标识符； 例如，变形金刚 7 可能指定为 http://video.netcinema.com/6Y7B23V。 然后发生六个步骤，如图 2.25 所示：

Figure 2.25 ♦ DNS redirects a user’s request to a CDN server

1. 用户在NetCinema访问Web页面。
2. 当用户点击链接http://video.netcinema.com/6Y7B23V时，用户的主机发送一个针对video.netcinema.com的DNS查询。
3. 用户的本地 DNS 服务器 (LDNS) 将 DNS 查询中继到 NetCinema 的权威 DNS 服务器，该服务器观察主机名 video.netcinema.com 中的字符串“video”。 为了将 DNS 查询“交给”KingCDN，NetCinema 权威 DNS 服务器不返回 IP 地址，而是将 KingCDN 域中的主机名返回给 LDNS，例如 a1105.kingcdn.com。
4. 从此，DNS 查询进入 KingCDN 的私有 DNS 基础设施。 然后用户的 LDNS 发送第二个查询，现在是 a1105.kingcdn.com，KingCDN 的 DNS 系统最终将 KingCDN 内容服务器的 IP 地址返回给 LDNS。 因此，在这里，在 KingCDN 的 DNS 系统中，指定了客户端将从其接收其内容的 CDN 服务器。
5. LDNS 将内容服务 CDN 节点的 IP 地址转发到用户主机。
6. 一旦客户端收到 KingCDN 内容服务器的 IP 地址，它就会与该 IP 地址的服务器建立直接 TCP 连接，并发出视频的 HTTP GET 请求。 如果使用 DASH，服务器将首先向客户端发送一个清单文件，其中包含一个 URL 列表，每个版本的视频都有一个，客户端将从不同版本中动态选择块。

   集群选择策略 Cluster Selection Strategies

   任何 CDN 部署的核心都是集群选择策略（cluster selection strategy），即一种将客户端动态定向（dynamically directing）到 CDN 内的服务器集群或数据中心的机制。 正如我们刚刚看到的，CDN 通过客户端的 DNS 查找来得知（learns）客户端 LDNS 服务器的 IP 地址。 CDN得知这个IP地址后，需要根据这个IP地址选择合适的集群。 CDN 通常采用专有的集群选择策略（proprietary cluster selection strategies）。 我们现在简要调查几种方法，每种方法都有其自身的优点和缺点。
   一种简单的策略是将客户端分配到地理位置最近（geographically closest）的集群。使用商业地理位置数据库（commercial geo-location databases）（例如 Quova [Quova 2020] 和 Max-Mind [MaxMind 2020]），将每个 LDNS IP 地址映射到一个地理位置。当收到来自特定 LDNS 的 DNS 请求时，CDN 会选择地理位置最近的集群，即距离 LDNS 公里数最少的集群。这样的解决方案对于大部分客户来说都可以很好地工作 [Agarwal 2009]。然而，对于某些客户端，该解决方案可能表现不佳，因为就网络路径的长度或跳频数（number of hops）而言，地理上最近的集群可能不是最近的集群。此外，所有基于 DNS 的方法固有的一个问题是，一些最终用户被配置为使用位于远程的 LDNS [Shaikh 2001; [Mao 2002]，在这种情况下，LDNS 位置可能远离客户端的位置。此外，这种简单的策略忽略了 Internet 路径随时间的延迟和可用带宽的变化，始终将相同的集群分配给特定的客户端。
   为了根据当前流量状况为客户端确定最佳集群，CDN 可以改为对其集群和客户端之间的延迟和丢包性能进行定期实时测量（real-time measurements）。 例如，CDN 可以让其每个集群定期向全球所有 LDNS 发送探测（probes）（例如，ping 报文或 DNS 查询）。 这种方法的一个缺点是许多 LDNS 被配置为不响应此类探测。

   2.6.4 案例研究：Netflix和YouTube Case Studies: Netflix and YouTube

   我们通过查看两个非常成功的大规模部署来结束对流式存储视频（streaming stored video）的讨论：Netflix 和 YouTube。 我们将看到这些系统中的每一个都采用了非常不同的方法，但采用了本节中讨论的许多基本原则。

   Netflix

   截至 2020 年，Netflix 是北美领先的在线电影和电视剧服务提供商。 正如我们在下面讨论的，Netflix 视频分发有两个主要组成部分：亚马逊云和它自己的私有 CDN 基础设施。
   Netflix 拥有一个处理多种功能的网站，包括用户注册和登录、计费、用于浏览和搜索的电影目录以及电影推荐系统。 如图 2.26 所示，该网站（及其关联的后端数据库）完全运行在亚马逊云中的亚马逊服务器上。 此外，亚马逊云处理以下关键功能：

• 内容摄取（Content ingestion）。 在 Netflix 向其客户分发电影之前，它必须首先摄取和处理电影。 Netflix 接收电影的制片厂主版本（studio master versions）并将它们上传到亚马逊云中的主机。
• 内容处理（Content processing）。 亚马逊云中的机器为每部电影创建许多不同的格式，适用于在台式计算机、智能手机和连接到电视的游戏机上运行的各种客户端视频播放器。 为这些格式中的每一种创建不同的版本并以多种码率，允许使用 DASH 通过 HTTP 进行自适应流媒体。
• 将版本上传到其 CDN（Uploading versions to its CDN）。 创建电影的所有版本后，亚马逊云中的主机会将版本上传到其 CDN。

Figure 2.26 ♦ Netflix video streaming platform
当 Netflix 于 2007 年首次推出其视频流服务时，它聘请了三个第三方 CDN 公司来分发其视频内容。 自那以后，Netflix 创建了自己的私有 CDN，现在它可以从中流式传输所有视频。 为了创建自己的 CDN，Netflix 在 IXP 和住宅 ISP 中都安装了服务器机架。 Netflix 目前在 200 多个 IXP 地点拥有服务器机架； 请参阅 [Bottger 2018] [Netflix Open Connect 2020] 以获取容纳 Netflix 机架的 IXP 的当前列表。 还有数百个 ISP 站点安装 Netflix 机架； 另请参阅 [Netflix Open Connect 2020]，Netflix 向潜在 ISP 合作伙伴提供有关为其网络安装（免费）Netflix 机架的说明。 机架中的每台服务器都有几个 10 Gbps 以太网端口和超过 100 TB 的存储空间。机架中的服务器数量各不相同：IXP 安装通常有数十台服务器并包含整个 Netflix 流媒体视频库，包括支持 DASH 的多个版本的视频。 Netflix 不使用拉缓存（第 2.2.5 节）在 IXP 和 ISP 中填充其 CDN 服务器。 相反，Netflix 通过在非高峰时段将视频推送到其 CDN 服务器来进行分发。 对于那些无法容纳整个库的位置，Netflix 仅推送最热门的视频，这些视频是每天确定的。 YouTube 视频 [Netflix Video 1] 和 [Netflix Video 2] 中详细描述了 Netflix CDN 设计； 另见 [Bottger 2018]。
在描述了 Netflix 架构的组件之后，让我们仔细看看客户端与电影交付中涉及的各种服务器之间的交互。 如前所述，用于浏览 Netflix 视频库的网页由 Amazon 云中的服务器提供。 当用户选择要播放的电影时，运行在亚马逊云中的 Netflix 软件首先会确定其 CDN 服务器中的哪一个拥有该电影的副本。 在拥有电影的服务器中，软件为该客户端请求确定“最佳”服务器。 如果客户端使用的住宅 ISP 在该 ISP 中安装了 Netflix CDN 服务器机架，并且该机架具有所请求电影的副本，则通常会选择该机架中的服务器。 如果没有，通常会选择附近 IXP 的服务器。
一旦 Netflix 确定了交付内容的 CDN 服务器，它就会向客户端发送特定服务器的 IP 地址以及清单文件，其中包含所请求电影的不同版本的 URL。 然后客户端和 CDN 服务器使用 DASH 的专有版本直接交互。 具体来说，如第 2.6.2 节所述，客户端使用 HTTP GET 请求报文中的字节范围报头（byte-range header）来请求来自不同版本电影的块。 Netflix 使用大约 4 秒长的块 [Adhikari 2012]。 在下载块时，客户端测量接收到的吞吐量并运行速率确定算法来确定要请求的下一个块的质量。
Netflix 体现了本节前面讨论的许多关键原则，包括自适应流媒体（adaptive streaming）和 CDN 分发。 但是，由于 Netflix 使用自己的私有 CDN，该 CDN 只分发视频（而不是网页），因此 Netflix 能够简化和定制其 CDN 设计。 特别是，Netflix 不需要使用 DNS 重定向，如第 2.6.3 节所述，将特定客户端连接到 CDN 服务器； 相反，Netflix 软件（在亚马逊云中运行）直接告诉客户端使用特定的 CDN 服务器。 此外，Netflix CDN 使用推送缓存而不是拉取缓存（第 2.2.5 节）：内容在非高峰时间的预定时间推送到服务器，而不是在缓存未命中期间动态推送。

YouTube

每分钟有数百小时的视频上传到 YouTube，每天有数十亿次视频观看，YouTube 无可争议地是世界上最大的视频共享网站。 YouTube 于 2005 年 4 月开始提供服务，并于 2006 年 11 月被 Google 收购。虽然 Google/YouTube 的设计和协议是专有的，但通过几次独立的测量工作，我们可以对 YouTube 的运作方式有一个基本的了解 [Zink 2009; 托雷斯 2011; 阿迪卡里 2011a]。 与 Netflix 一样，YouTube 广泛使用 CDN 技术来分发其视频 [Torres 2011]。 与 Netflix 类似，谷歌使用自己的私有 CDN 来分发 YouTube 视频，并在数百个不同的 IXP 和 ISP 位置安装了服务器集群。Google 从这些位置并直接从其庞大的数据中心分发 YouTube 视频 [Adhikari 2011a]。 然而，与 Netflix 不同的是，Google 使用拉缓存（如第 2.2.5 节所述）和 DNS 重定向（如第 2.6.3 节所述）。 大多数时候，谷歌的集群选择策略将客户端引导到客户端和集群之间 RTT 最低的集群； 然而，为了平衡集群之间的负载，有时客户端会（通过 DNS）被定向到更远的集群 [Torres 2011]。
YouTube 使用 HTTP 流媒体，通常为视频提供少量不同版本，每个版本具有不同的码率和相应的质量级别。 YouTube 不采用自适应流媒体（例如 DASH），而是要求用户手动选择一个版本。 为了节省重新定位或提前终止会浪费的带宽和服务器资源，YouTube 使用 HTTP 字节范围请求来限制在预取目标数量的视频后传输的数据流。
每天有数百万个视频上传到 YouTube。 YouTube 视频不仅通过 HTTP 从服务器流式传输到客户端，而且 YouTube 上传者还通过 HTTP 从客户端将视频上传到服务器。 YouTube 处理它收到的每个视频，将其转换为 YouTube 视频格式并以不同的码率创建多个版本。 此处理完全在 Google 数据中心内进行。（请参阅第 2.6.3 节中关于 Google 网络基础设施的案例研究。）