来源：DEMUXED 2021 演讲者：Zac Shenker 内容整理：胡经川 本文从多 CDN 切换入手，介绍 HLS 中一些新特性，包括内容转向的新规范以及插页式广告规范，并总结了这两项规范未来的部署前景。
目录
- 多 CDN 切换
- 基于 DNS 的 CDN 切换
- 基于清单(Manifest)的 CDN 切换
- 基于客户端的 CDN 切换
- HLS 内容转向规范
- 插页式（interstitial）广告规范
- 设备支持
多 CDN 切换
随着用户的增多，许多媒体公司从很多不同的角度需要多 CDN。在许多区域，对于冗余和故障转移，或者在许多高并发的大型活动中，多 CDN 可以分配和缓解负载。在多 CDN 体系结构中，流媒体服务的内容（图像、视频文件等）在不同地理区域的多个 CDN 提供商之间缓存。借助于智能负载均衡算法和在传输管道的不同点收集的数据，客户端的传入流量分布在这些多个 CDN 提供商之间，从而提供了更大的冗余和性能优势。
数据通常是通过 QoE/QoS 分析供应商收集的，或通过专有的方式测量网络性能（例如，下载虚拟文件所需的时间）。所有这些数据都被一个中央规则引擎或服务器使用，以决定多个 CDN 中的哪一个应该为来自某个地区的请求提供服务。
多 CDN 切换并不是 HLS 标准生态中原生的部分，有许多不同的实现方式，各有各的优缺点，以下是一些最常见的实现方式。
基于 DNS 的 CDN 切换
在这种方法中，DNS 系统用于为不同的客户端提供不同的 DNS 连接，以便不同的客户端使用不同的 CDN。通过一个域名引导所有内容请求，该域名实时动态地处理流量分布。因此，如果域中的所有流量都需要从 CDN-A 重定向到 CDN-B，那么 DNS 将指向 CDN-B。这项技术很简单，非常容易部署并且支持全平台，许多公司都走这条技术路线。
但它不是很有效，因为 DNS 传播非常耗时，并且需要几分钟才能通过网络传播。在随后的时间内，最终用户可能会通过错误的 CDN 向内容服务器发送许多请求，如果处理不当，最多会导致性能下降或所有请求的服务中断。
这就导致不同的 ISP 解析器或不同的客户端并不总能很好地遵守 DNS 的 TTL。因此，这可能意味着您无法真正细粒度地控制不同客户端何时在不同 CDN 之间切换。
基于清单(Manifest)的 CDN 切换
CDN 切换的另一种技术是实时更新清单，在这种方法中，决策服务器根据切换规则和因素重新更新清单以指向不同的 CDN。这需要加载（或重新加载）清单，以便应对变化。虽然这似乎是一个简单的策略，但它需要设置一个服务器，在更新后重新提供清单（没有被缓存）。这种服务的一个变种还在清单中记录了一个 CDN 的列表，在其中一个 CDN 失败的情况下，用户可以切换到这个列表其他的 CDN。
虽然这种技术看起来很容易，但在 HLS 播放列表中如何指定 URL，播放器在直播与 VOD 场景下如何频繁请求新的清单等方面都存在问题。
目前主要有两种方法，第一个是基于冗余流的方法，还有一个是基于 per-segment 的切换方法, 后者主要适用于直播流。
基于客户端的 CDN 切换
在客户端交换中，交换机制被集成到了客户端，这就允许了许多细粒度的控制，但是很难在所有平台上集成。由于基于 HTTP 的流媒体的性质以及 HLS 中独立可解码切片的使用，用户可以从不同的 CDN 中独立获取每个切片。此外，用户还拥有有关网络状况、延迟和其他因素的“最新”信息，这些因素都可以成为决策节点。
但是这种方法存在许多缺点。首先你需要将额外的程序嵌入到客户端中，以便与维护所有规则和切换因素的外部服务器进行通信，而且你需要为所有平台的客户端（HTML5、Android、iOS、Roku、智能电视、Xbox 等）编写、测试和维护 SDK，这是一个艰巨的任务。此外，在客户端中改变流的 URL 需要访问客户端的源代码或 API。在无法获得这种级别的代码支持的平台上，你将无法在客户端实现流媒体的切换。
在了解了实现多 CDN 切换的不同技术后，你现在一定已经意识到，没有一个放之四海而皆准的方法。相反，公司可以根据他们的需求、基础设施能力、设计、预算和规模采用不同的策略。
HLS 内容转向规范
内容转向规范为客户端提供了一种可以频繁地从远程服务器获取和更新 CDN 选择的方法。
到目前为止，HLS 中的内容转向规范的最新版本号为 1.2b1，这是此规范的第三个版本，每一个版本都是向后兼容的。这个规范定义了 master 播放列表的语法，允许内容供应商指定客户如何优先访问其内容的不同路径，这是使用一个由用户定期重新加载的外部转向清单实现的。所有的 CDN 都应该在这个 master 清单中指定。
有一些新的内容被添加到这个版本的规范中。首先是 #EXT-X-CONTENT-STEERING，它主要有两个属性，SERVER-URI 和 PATHWAY-ID。
- SERVER-URI 属性是一个指向内容转向清单的 URI，如果转向服务器需要 asset 标识符来产生转向清单，SERVER-URI 就可能包含 asset 标识符。它可以使用数据 URI 方案，在 master 播放列表中提供在线清单; 在这种情况下，可以使用 RELOAD-URI 参数将随后的清单重载重定向到远程转向服务器。
- PATHWAY-ID 属性标识了必须由客户端应用的 pathway，直到获得初始的转向清单。它的值必须是一个合法的 pathway ID，如 "Steering Manifest" 部分所规定的。
图 1：语法标签实例 1
此外，还有一些转向服务器查询参数，客户端发送一个带有转向清单 URI 的请求，以获得转向清单。它可以在 URI 上添加以下查询参数。
- _HLS_pathway: 当前使用的 pathway 的 ID
- _HLS_throughput: THROUGHPUT 是每秒的整数位数。它表示客户端对应用的 Pathway 所做的下载吞吐量的当前预测。比特率估计的确切方法因客户而异。需要注意的是，HTTP 代理缓存应该为从其缓存键中排除此参数。
图 2：转向服务器查询参数
另外还有内容转向清单(Steering Manifest)。内容转向清单响应是一个 JSON 对象，它有许多字段。首次第一个字段是版本号，固定为 1。
下一个字段是 TTL，TTL 指的是客户端在重新加载转向清单之前必须等待多少秒。推荐值是 300 秒（5 分钟）。转向服务器可以根据客户端改变 TTL 以分配服务器的负载。
然后是 RELOAD-URI，这是可选的，它指定客户端在下次获得转向清单时必须使用的 URI。它可以是一个基于当前转向清单 URI 的相对 URI。
PATHWAY-PRIORITY 字段是包含 Pathway ID 的数组。PATHWAY-PRIORITY 数组中的元素是按 Pathway 偏好排序的，第一个是最优先的。一个转向清单必须包含至少有一个 Pathway。在 PATHWAY-PRIORITY 数组中的一个 Pathway ID 不得出现超过一次客户端必须忽略 PATHWAY-PRIORITY 数组中未被识别的 Pathway ID。
图 3：转向清单
关于规范的更多内容，可以参考其 PDF 完整版本：https://developer.apple.com/streaming/HLSContentSteeringSpecification.pdf
插页式（interstitial）广告规范
目前，服务器端广告插入（Server Side Ad Insertion）是最常用的方式，然而它还面临着许多挑战。HLS interstitials 规范旨在让广告内容的部署更加便捷，无论是在服务器端还是客户端，它不再需要依赖 SSAI 中的特殊标签。此外，它对 VOD 和直播场景都支持得很好。
图 4：HLS interstitials 规范目标
此规范中，服务器可以插入 EXT-X-DATERANGE 标签来告诉客户端安排插页式播放。它包含许多属性，如下图所示。
图 5：DATERANGE 标签属性
首先，CLASS 属性固定为 “com.apple.hls.interstitia”；X-ASSET-URI 属性是一个带引号的绝对 URL，用于一个单一的 interstitia asset; X-ASSET-LIST 属性是指向一个 JSON 对象的 URL，该 JSON 对象必须包含一个键/值对；X-RESUME-OFFSET 属性 的值是一个以秒为单位的十进制浮点数，用于指定在插页式广告播放后应在何处恢复主要内容的播放，X-RESUME-OFFSET 的典型值为零，如果 X-RESUME-OFFSET 不存在，则播放器使用插页式播放的持续时间作为恢复偏移量，这适用于从实时边缘保持恒定延迟的实时播放和 VOD 播放；X-PLAYOUT-LIMIT 属性的值是一个十进制的浮动秒数，指定了整个插页的播放时间限制。如果它存在，播放器应该在达到其开始时的偏移量时结束插页播放，否则应该在到达 插页终点的时候结束。
关于规范的更多内容，可以参考其 PDF 完整版本：https://developer.apple.com/streaming/GettingStartedWithHLSInterstitials.pdf
设备支持
内容转向和插页式广告规范在刚刚提出来的时候就作为 ios 和 tvos15 的一部分被支持。除了 Apple 设备之外，其他设备支持的迹象并不多，但有许多商业和开源的工作开始研究如何实施这两个规范。目前 hls.js 已经开始实施内容转向规范。
总体而言，内容转向规范的实施似乎已经达成共识，因为它实施起来相当简单，尤其是在已经支持冗余流的播放器中。但支持插页式广告可能会面临更多挑战，尤其是在只有一个播放器或解码器可用的平台上。
附上演讲视频：
http://mpvideo.qpic.cn/0bc32uabaaaa6eahsc2w4frfbvodcdkqaeaa.f10002.mp4?dis_k=5da2838177ecc80bb87d09105bce5967&dis_t=1653387465&vid=wxv_2352801699507306497&format_id=10002&support_redirect=0&mmversion=false
