在流媒体的动态格局中，选择最佳协议是提供无缝观看体验的关键。在众多可用协议中，HTTP-FLV（基于 HTTP 的 Flash 视频）正在掀起波澜，并比更成熟的 HLS（HTTP 实时流）更具吸引力。本博客探讨 HTTP-FLV，深入探讨其功能、性能以及与 HLS 相比其越来越受欢迎的原因。
流协议简介：您需要了解的基础知识
如果您是媒体专业人士，您可能对 HLS（HTTP 实时流）很熟悉，因为它在 Apple 生态系统中被广泛采用。HLS 是通过互联网向观众流式传输在线视频和音频媒体的领先标准之一。根据 鸟视，HLS在目前全球流媒体协议的使用率中位居第一。
但随着网络技术的不断进步，以及高质量直播需求的不断增长，这些协议的排名可能会发生变化。例如，HTTP-FLV 是一种经常被忽视的流媒体协议。一个引人注目的事实是，许多媒体巨头（包括但不限于抖音、TikTok 等）都在采用 HTTP-FLV，因为它具有超低延迟体验，这对于互动娱乐领域至关重要。
为了更好地理解为什么会发生这种转变，我们需要深入研究 HTTP-FLV 和 HLS 在提高直播质量方面的主要区别。
什么是 HLS (HTTP 实时流)？
HLS，即 HTTP Live Streaming，是 Apple 于 2009 年开发并推出的一种协议。它旨在取代 QuickTime Streaming Server，并解决 RTMP 等现有协议的一些限制。HLS 现已成为自适应比特率视频流最广泛采用的标准，通过适应不同的网络条件并确保跨设备兼容性，提供可靠且无缝的观看体验。
HLS 的诞生是为了解决当时互联网速度所导致的性能问题。这需要一种具有高可靠性和与各种网络和设备条件兼容的协议。为了实现这一点，HLS 通过使用短连接传输视频内容来修改直播流程。
简单来说，HLS 的工作原理是将内容分割成较小的部分，然后为每个部分创建请求，然后按顺序播放。为了防止大片段导致传输时间过长，HLS 进一步将这些片段切成更小的块，然后将其打包成播放列表文件（M3U8 格式）并发送到客户端进行解析。客户端使用播放列表来请求和播放各个块。
一旦M3U8文件中打包的所有TS文件（传输流段）都传输完毕，服务器就会继续对即将传输的媒体内容进行切片、打包，并等待客户端请求新的媒体内容。
除了短连接带来的可靠性和适应性之外，HLS作为自适应码率视频流的广泛采用的标准，在跨设备兼容性和可扩展性方面也表现出色。
- 跨设备兼容性 – HLS 保证您的内容可以在运行兼容视频播放器（例如 HTML5）的每台客户端设备上播放。这意味着 HLS 可在各种设备上使用，包括 iOS、Android、智能电视和大多数 Web 浏览器。这种广泛的兼容性使其成为流媒体的多功能选择。
- 可扩展性 – HLS 在标准 HTTP 服务器上运行，并且可以轻松与内容分发网络 (CDN) 集成，以在全球范围内分发内容，满足病毒式收视率高峰和大量现场观众的需求。
尽管短连接为 HLS 带来了诸多优势，但这种方法也存在一些缺点。由于数据块或片段通常为 2-6 秒，并且需要一次缓冲多个这样的小片段，因此延迟最终可能会达到数十秒。这时，一种新的连接方法便应运而生：持久连接。
什么是 HTTP-FLV？
HTTP-FLV 传输方式是建立一次连接并维持连接，在此期间服务器不断向客户端发送小文件，直到客户端或服务器断开连接。HTTP-FLV 直播协议利用 FLV 文件小的特点，通过不间断的网络连接传输视频内容，确保客户端始终有内容可播放。
从本质上讲，HTTP-FLV 旨在提供低延迟流媒体，使其成为延迟是关键因素的实时应用的理想选择。这对于现场活动、在线游戏和即时反馈至关重要的交互式流媒体尤其重要。
然而，延迟并不是直播的唯一因素。直播的最终用户体验由三个关键指标决定：初始加载时间、延迟和缓冲。因此，我们将重点比较这两种不同的直播协议如何影响这三个方面。
HLS 与 HTTP-FLV 在直播中的性能对比
在深入比较之前，让我们先定义一些对直播过程中用户体验有显著影响的关键因素：
初始加载时间： 请求直播流后，视频的第一帧出现在客户端屏幕上所需的时间。缩短此时间可最大限度地减少等待时间，从而提升用户体验。
延迟： 直播事件实际发生与客户端屏幕上显示之间的延迟。换句话说，这是内容被捕获与观众观看之间的时间差。较低的延迟对于实时交互至关重要。
缓冲： 由于客户端缓冲内容用尽而导致播放中断或暂停。这些中断的频率和持续时间是流媒体质量的关键指标。
现在，让我们基于以下因素比较一下 HLS 和 HTTP-FLV：
初始加载时间
HLS： 由于 HLS 具有分段特性，因此客户端需要下载并缓冲多个分段才能开始播放。这可能会导致初始加载时间更长，尤其是在低带宽情况下。通常，如果在请求期间发生任何错误，则可能会发生初始缓冲和延迟。
HTTP-FLV： HTTP-FLV 仅需要与服务器建立单一连接，之后服务器会持续向客户端发送内容。客户端只需接收和播放内容，而无需反复向服务器发送请求。这可以缩短初始加载时间，因为客户端在建立连接后几乎立即开始接收和播放视频。
延迟
HLS： 在传输层，HLS 需要对视频进行分段打包，打包完成后需要额外发起两次请求才能收到实际的视频内容进行播放。虽然 HLS 已经做了一些优化，降低了初始帧时间，但其固有的两次请求机制还是无法匹敌 HTTP-FLV 的单次请求时间。
HTTP-FLV： 使用 HTTP-FLV，可以建立并维护单个连接，使服务器能够持续向客户端传输视频内容。这种持久连接可显著减少延迟，非常适合需要即时反馈的实时广播。
缓冲
HLS： 分段和打包视频内容的过程本身就需要额外的时间。在传输阶段，需要处理和打包每个片段（通常需要 2-3 个片段时间）。此外，客户端必须先接收 M3U8 播放列表，然后才能请求 TS 片段。此外，在 CDN 层，需要缓存 M3U8 文件，这会增加额外的时间开销。总体而言，HLS 需要额外的传输和缓存时间来处理和发送直播内容。
HTTP-FLV： 由于FLV文件较小，且只有一个持久网络连接，HTTP-FLV只需要一个连接的延迟作为传输的时间开销，从而可以在尽可能短的传输时间内传输视频内容。
分析影响整体用户体验的关键指标，HLS前期传输逻辑比较落后，传输过程中耗时较高，HTTP-FLV在初始加载时间、延迟、缓冲三项指标上均优于HLS。
HTTP-FLV 优势的前提与限制
HTTP-FLV 虽然在直播体验上占有明显优势，但也有一定的前提条件和限制：
- CDN架构修改： 许多 CDN 并不原生支持 HTTP-FLV，因此需要修改 CDN 架构才能确保最佳性能。例如，CDNetworks 已经进行了此类架构调整。
- 跨设备兼容性： HTTP-FLV 的跨设备兼容性不如 HLS。虽然它在降低延迟方面表现出色，但这一优势是以有限的设备支持为代价的。不过，HTTP-FLV 的低延迟为用户留存和盈利提供了新的机会，尤其是在即时反馈可增强用户体验的应用中。
但你必须承认，尽管存在这些限制，HTTP-FLV 提供的低延迟使其在娱乐直播场景中非常受欢迎，因为最小的延迟对于观众的参与至关重要。
流媒体协议的未来趋势
直播中实时互动、即时反馈的需求日益增加，推动着低延迟协议不断演进，而凭借长连接机制的HTTP-FLV已然是强有力的竞争者。
但需要注意的是，我们今天讨论的两种协议只是 CDNetworks 支持的低延迟协议的一部分。对于需要事件级低延迟直播技术的媒体公司来说， CDNetworks 的低延迟流媒体解决方案采用 WebRTC 的 可能是更好的选择。另一方面，对于 OTT 行业来说，HLS 的跨设备兼容性具有显著优势。
这强调了一个关键点：没有“最佳”协议，只有最适合您特定需求的协议。平衡成本和收益以及企业品牌和用户体验是选择最合适协议的关键。
无论如何，选择可靠且强大的流媒体服务提供商是媒体行业最方便的选择。以 CDNetworks 为例。除了支持广泛的直播协议外，CDNetworks 还拥有超过 2,800 个 CDN 持久性有机污染物 （接入点）遍布全球，性能卓越，客户服务一流。这些特点使 CDNetworks 成为媒体公司在保持市场竞争优势方面的长期合作伙伴。
通过本文的深入分析，我们探讨了 HTTP-FLV 和 HLS 在流媒体领域的应用、优缺点，帮助您更好地了解和选择适合您需求的流媒体协议。希望本博客能为您提供宝贵的见解。如果您还有其他问题或需要进一步讨论，请随时 接触 我们。
