通过 CDN 实现低延迟流媒体：如何优化 LL-HLS 和 LL-DASH 以实现低于 3 秒的延迟

直播技术正在不断演进，观众如今期待近乎即时的播放体验。Gcore 推出低延迟直播解决方案，通过采用 LL-HLS 和 LL-DASH 技术，实现端到端 2.0-3.0秒的延迟。该方案针对 hls.js、dash.js 等行业标准播放器及原生 Safari 浏览器进行了优化，确保流畅传输，Gcore 的 CDN 网络将提供卓越的流媒体体验：

• LL-DASH 延迟： ±2.0 秒 
• LL-HLS 延迟： ±3.0 秒 

Gcore 流媒体平台产品经理 Alexey Petrovskikh 分享了如何优化 LL-HLS 和 LL-DASH 以实现低于 3 秒的延迟。

挑战：加速实时视频传输

实现低于 3 秒延迟的 LL-HLS 与 LL-DASH 传输

支持延迟低于 3 秒的 LL-HLS 和 LL-DASH 需要克服几个关键挑战：

1. 可扩展的请求处理：由于频繁的小文件更新，传统的针对大文件的缓存策略不适用于 LL-HLS 和 LL-DASH。
2. 性能监控演进：文件下载速度现在由分段持续时间而不是文件大小决定。
3. 细粒度低延迟分段处理：CDN 必须高效地管理分块传输编码，以实现更小的分段大小。

以下示例说明了在相同数量的观众观看的情况下，从常规 HLS 切换到 LL-HLS 时，平均请求率和平均请求时间方面的差异：

典型的低延迟实现涉及两个原则：

• 从源端完整下载，然后通过分块传输进行分发。这意味着需要等待 DASH .mp4 片段完整下载完毕（通常为 10 秒）。
• 禁用缓存并进行部分下载，所有请求都将直接发送到源服务器，而不进行缓存。

这些传统原则在 CDN 上扩展性不佳，无法满足低延迟需求。因此，需要新的方法来降低延迟，同时保持流媒体的稳定性。

我们之前实现了±5秒的延迟，但要进一步降低延迟，尤其是在 hls.js 和 Safari 等浏览器上是一项巨大的技术挑战。我们的目标是在不影响稳定性的前提下，实现 2 秒的延迟。

最终，传统的传输方案和新的低延迟传输方案看起来是这样的：

多功能性

LL-DASH 与 LL-HLS 协议采用截然不同的传输与播放方案。核心挑战在于使两种协议能在单一传输系统中协同运作。

通过以下关键措施，我们实现了两种协议传输的同步：

LL-DASH

DASH（基于HTTP的动态自适应流媒体）是一种非常灵活的协议，这既是它的优势，也是它的挑战。这种灵活性要求开发人员在分割内容时考虑诸多细微差别。以下是MPEG-DASH最基本的原则：

• 单一清单。 
• 通过计时机制请求数据块。
• 在数据块生成过程中持续下载（即文件尚未以最终形式存在）。

低延迟流媒体旨在尽可能接近实时播放直播内容。在LL-DASH中，视频片段会同时进行转码和分发。播放器无需等待整个文件录制完成，即可根据指定的“targetLatency”属性开始播放。

然而，回放仅能从关键帧开始，这在确定延迟时引入了限制。

另一方面，您知道回放仅能从关键帧开始。因此，关键帧成为确定延迟时的重要限制因素。

关键帧放置策略及其对 LL-DASH 延迟的影响：

在 LL-DASH 中，您可在最后一公里实现最低延迟与传输质量的平衡。若关键帧间隔过长，数据更新与网络问题可能导致缓冲现象。

LL-HLS

LL-HLS 相较于常规版本引入了一系列新特性：

• 清单阻塞机制
• 短清单
• 微小分段文件（出现后即时下载）

阻塞播放列表重新加载：

该功能通过指令控制：#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES。

它指示服务器暂缓处理请求，直到部件文件完全可用。传统的 HLS 几乎可以立即返回结果（±30 毫秒），而 LL-HLS 则会引入一个延迟，该延迟等于下一个部件的准备时间——通常为 500 毫秒或更长。

微小片段与缓冲长度：

微小文件（即“片段”）的生成频率高于完整数据块。其持续时间通过 #EXT-X-PART-INF:PART-TARGET 指令进行调控。

缓冲区长度由 #EXT-X-SERVER-CONTROL:PART-HOLD-BACK 参数决定。

该值定义播放器开始播放前应缓冲的秒数，必须至少为片段目标时长的三倍。

Apple LL-HLS 工作原理：

延迟受本地缓冲区、已生成微小文件数量以及关键帧影响。

LL-HLS 中关键帧放置策略及其对延迟的影响：

整个片段的长度不会影响延迟，但关键帧的位置仍是关键因素。

LL-HLS的关键特性之一是字节范围请求，该技术可通过将多个小文件合并为单次请求大幅减少请求次数。部分播放器（如Safari）会延迟播放以等待下一个关键帧，从而实现指定延迟值。

统一

为统一两种协议的传输系统，我们利用了它们在处理关键帧和流媒体方面的相似性。

以下示例展示了如何将两种协议整合为单一系统，用于生成 LL-DASH 和 LL-HLS 的流：

这种统一的方法使我们能够克服采集、转码、打包和 CDN 分发系统中的几个挑战。

挑战

采集：在处理两种协议的细微差异时，如何以最小延迟从源端采集流媒体数据是一大挑战。

转码：将未完成的片段/文件传递给 JITP 需要全新的处理工作流。

打包：从未完成的转码文件中实时打包清单文件和片段文件是技术难点。

CDN：内容分发网络必须同时支持两种不同的数据传输方案：

• 小文件加速下载（出现即刻下载）
• 未完成长文件的持续下载

性能：通过 CDN 进行交付

项目中最复杂的部分是由 CDN 负责的。我们的工程师将网络容量扩展到 200Tbps 以上，并将全球平均响应时间缩短至仅 30 毫秒。与此同时，我们还完成了多项开发任务：

LL-DASH

• 分块传输： CDN 需要支持分块交付，这与 Nginx 的代理缓存锁定和缓冲等传统配置不兼容。 
• CPU 优化：由于连接持续时间比普通文件下载时间更长，CDN 边缘需要处理更高的 CPU 负载。

分块代理模块开发：

我们从零开始开发了一个名为“分块代理”的新模块。它的工作原理是从源服务器下载数据字节，并立即将其分发给最终用户。当新用户连接时，他们会立即获得已累积缓存的全部数据，同时与其他用户一样，通过持续下载的方式继续接收其他数据字节。

需要注意的是，这里“分块传输”一词的使用需谨慎。对于 HTTP/1.1 连接，这会被视为分块传输响应；而对于 HTTP/2，其响应机制则有所不同。

分块代理模块的主要特性：

• chunked-proxy 模块被设计成一个功能齐全的缓存模块，符合 CDN 标准。
• 支持对 GET 和 HEAD 请求进行 RAM 缓存。
• 它会处理 Cache-Control 标头，以及 Expires、Date 和 Last-Modified。
• 它会在响应中添加一个 Age 标头。该标头可用于检查缓存状态： 
  • 如果在缓存中找到响应，则 Age 标头指示响应被缓存的时间（以秒为单位）。
  • 如果在缓存中找不到响应，则不会添加 Age 标头。

通过 CDN 进行 LL-DASH 的分块缓存和分发：

LL-HLS

• 源端被阻止的请求：

CDN必须能够长时间保持低延迟清单文件（.m3u8）的连接，同时等待源服务器的响应。这对监控“response_time”的工具来说是个挑战，因为响应时间现在将大致等于部分文件的持续时间。

此外，我们需要正确处理 MISS 和 EXPIRED 状态，仅在首次请求时将其发送到源服务器。这个过程比较棘手，因为像 Nginx:proxy_cache_lock 这样的默认缓存机制并不完全适用，它们只能处理部分状态。因此，我们需要一个完整的实现方案。

• 清单缓存规则：

CDN 必须配置为正确缓存低延迟的 .m3u8 清单文件。缓存控制时间应设置为 1 秒，并且缓存键中应包含 _HLS_skip、_HLS_msn 和 _HLS_part 等查询参数。

处理日益增多的请求：

CDN 必须做好准备，应对日益增长的小文件请求，这些请求包括每个新分段的低延迟清单文件以及分段文件本身。虽然文件大小很小，但请求数量却显著增加。例如，单个分段可能包含多个清单文件和分段文件。因此，日志大小可能会增加2*N倍。监控和分析工具必须进行优化，以适应这种增长的负载。

字节范围请求可以显著减少向源服务器发出的请求数量。它无需针对离散的文件部分发出多个请求，而是只需对整个段发出一个请求。根据 HLS 规范（第 6.2.6 节），“当处理包含一个或多个尚未完全发送的部分段的 URI 的字节范围时，服务器必须避免发送属于该部分段的任何字节，直到该部分段的所有字节都能以全速传输给客户端为止。”

这意味着与 CDN 之间的传输应该通过分块代理进行组织，就像 LL-DASH 一样，但要进行明确的逻辑划分。

可观测性

所有新功能均已集成到标准转码和 CDN 分发流程中。因此，我们调整了常用的分析和监控工具，以应对增加的负载。

可观测性的关键组成部分：

• 日志：系统生成的用于记录一段时间内发生的事件的文本记录。我们会维护低延迟流的日志。
• 指标：随时间收集的定量指标，包括请求计数、请求状态、过期清单检测、响应时间等。
• 跟踪记录：详细记录请求在系统中的流转过程，有助于识别瓶颈并了解系统行为。

结果

Gcore 使用 LL-DASH 协议实现了卓​​越的延迟性能，延迟约为 ±2.0 秒；使用 LL-HLS 协议实现了卓​​越的延迟性能，延迟约为 ±3.0 秒。

主要技术发展包括：

1. 改进了 LL-HLS 和 LL-DASH 的负载管理：CDN 基础设施经过优化，能够有效地处理小型、频繁的内容更新所产生的高请求量，从而确保两种协议的流畅交付。
2. 增强的监控和分段处理：性能监控和分块传输管理方面的更新显著降低了延迟，从而在主流视频播放器上实现了 LL-HLS 和 LL-DASH 流的无缝播放。

原文：https://www.streamingmedia.com/Articles/Editorial/Spotlights/Low-latency-streaming-via-CDN-How-to-optimize-LL-HLS-and-LL-DASH-for-sub-3-second-latency-172056.aspx