选直播协议这件事，很多时候不是“哪个更好”的问题，而是“你的场景能容忍多少延迟”的问题。HTTP-FLV和HLS的延迟差距，在技术上是可以精确解释的。理解这个差距从哪来，比记住“FLV快HLS慢”这个结论更有价值。因为你的业务场景，可能正好落在“HLS够用”和“必须用FLV”之间的某个位置。

　　延迟差距的根源：切片机制

　　HLS的全称是HTTP Live Streaming，苹果在2009年推出。它的核心工作方式是：把直播流切成一个个小分片文件(通常是TS格式)，每个分片5到10秒，然后通过普通的HTTP协议分发出去。播放器拿到m3u8索引文件后，按顺序下载这些分片来播放。

　　这个“先切片、再下载、攒几个再播”的流程，天然就带来了延迟。一个分片从生成到被播放器完整下载，本身就需要时间。更关键的是，播放器为了保证流畅性，通常不会“下完一个播一个”，而是会缓存3到4个分片再开始播放。技术文档把这个账算得很清楚：每个分片5秒以上，分片数量3到4个，总延迟就在10秒到30秒这个区间。

　　HTTP-FLV走的是另一条路。它把音视频数据封装成FLV格式，通过一个HTTP长连接持续不断地推送给播放器。服务器回复时没有Content-Length字段，客户端就一直接收数据，直到连接断开。播放器不需要等待“分片生成”，也不需要攒够几个分片才开始播，数据是流式到达的，缓冲可以控制得很小。多家技术文档给出的HTTP-FLV典型延迟在1到3秒之间。

　　一个是“等文件生成再下载”，一个是“数据到了就传”。 这个本质差异，决定了HLS的延迟下限远高于HTTP-FLV。

　　实测数据：差距有多大

　　数字比描述更有说服力。

　　RTMP推流加FLV播放的正常延迟在2到3秒左右，而HLS因为切片机制，延迟在10到30秒是“正常现象”。HTTP-FLV延迟较小，适合低延迟播放场景；HLS延迟较大，10秒到30秒属于正常范围。

　　另一个维度的数据：HLS的首次取流延迟是4到10秒，HTTP-FLV的首次取流延迟是2到4秒。这个“首次取流延迟”反映的是用户点开直播后需要等多久才能看到画面，对直播体验的影响非常直接。

　　有一个来自技术博客的测试数据值得参考：在相同条件下，HTTP-FLV的内容延迟可以做到1秒左右，而HLS的延迟达到20秒，差距接近20倍。这个测试是在特定条件下完成的，实际生产环境中的差距会因服务器配置、网络状况和播放器缓冲策略而有所不同，但数量级的差距是真实存在的。

　　为什么HLS延迟这么高还有人用

　　如果只看延迟，HLS在技术上是“落后”的。但它能在直播生态中占据主流位置，靠的是另外几个维度的优势。

　　兼容性是HLS最大的护城河。 HLS是苹果原生支持的协议，Safari浏览器不需要任何插件就能直接播放。安卓端的浏览器也普遍支持。这意味着你把一个HLS的m3u8链接通过微信发给别人，对方点开就能看，不需要安装任何东西。HTTP-FLV依赖浏览器的MSE(媒体源扩展)能力，Chrome、Firefox、Edge支持得不错，但Safari的支持很弱，手机端浏览器更是有限。

　　CDN亲和度是另一个关键因素。 HLS的分片是独立的HTTP文件，CDN可以像缓存普通网页图片一样缓存这些分片。热门分片被缓存在边缘节点，后续观众直接从就近节点获取，源站压力小，扩展性极好。HTTP-FLV是长连接，CDN边缘节点需要维护每个观众的状态，缓存和调度的复杂度更高，大规模并发的成本也更高。

　　稳定性也是HLS的优势。 因为播放器缓存了多个分片，网络短暂波动时，播放器可以继续播放缓存中的内容，用户几乎感知不到卡顿。HTTP-FLV的缓冲小，网络抖动更容易直接反映为画面卡顿或延迟累积。

　　这些优势，让HLS在“延迟不是首要矛盾”的场景中，成为更务实的选择。

　　场景选型：你的业务能容忍多少延迟

　　选协议不是选“最好的”，是选“最合适的”。延迟、兼容性、成本三个维度，在不同场景下的权重完全不同。

　　必须用HTTP-FLV的场景：

　　内网监控大屏、生产指挥中心、设备监管面板。这些场景的用户需要“看到正在发生的事”，延迟超过3秒就会影响判断。HTTP-FLV的1到3秒延迟在这个场景下是刚需，而CDN和兼容性问题在内部网络中通常不是障碍。

　　私域直播中的强互动场景也值得考虑HTTP-FLV。在线答题、竞拍、限时秒杀，这些场景对“讲师说的话和观众看到的画面同步”有明确要求。私域直播的延迟优化目标是“让直播更像‘正在发生’的现场”，普通课程可以容忍几秒延迟，但互动密度高的场景需要更低延迟。

　　HLS更合适的场景：

　　公开直播活动、课程直播、社交平台分享。这些场景的观众分散在各类设备上，兼容性是第一优先级。一个通过微信分享的直播链接，如果要求用户“必须用Chrome打开”或者“安装一个App”，转化率会大幅下降。HLS的“点开就能看”在这个场景下的价值，远超延迟从10秒降到3秒带来的体验提升。

　　移动端观看为主的场景也倾向HLS。平台的对比明确指出“移动端用HLS播放兼容性较佳”。iOS设备原生支持HLS，安卓浏览器对HLS的支持也远好于HTTP-FLV。

　　一个务实的架构：多协议输出。

　　实际的企业直播系统，很少只选一种协议。源流推上来之后，流媒体服务器同时输出HLS和HTTP-FLV两路。对延迟敏感的终端(比如内网大屏)走FLV，对兼容性要求高的终端(比如微信分享的移动端观众)走HLS。SRS和ZLMediaKit这类流媒体服务器都支持这种多协议输出能力。

　　这不需要在编码端做任何改动。你推一路RTMP流上去，服务器根据播放端的请求协议，自动适配输出格式。

　　常见问答

　　问：HTTP-FLV的延迟比HLS低多少?

　　根据多个技术文档和实测数据，HTTP-FLV的典型延迟在1到3秒，HLS在10到30秒，差距在10倍左右。首次取流延迟对比显示，HLS需要4到10秒，HTTP-FLV只需要2到4秒。实际延迟会受服务器性能、播放器缓冲策略和网络状况影响，但数量级差距是稳定的。

　　问：为什么HLS的延迟不能通过“缩短分片时长”来降低?

　　可以降低，但有代价。把分片从10秒缩短到2秒，理论上延迟可以从20秒降到4秒左右。但更短的分片意味着更频繁的播放列表更新和更多的HTTP请求，服务器和CDN的负载会明显增加。技术文档也提到，“减少分片个数或缩短分片时长”来降低HLS延迟，需要“综合考虑对卡顿指标可能造成的影响”。低延迟HLS(LL-HLS)是一套更复杂的端到端方案，需要在打包器、CDN和播放器之间协调支持，不是改一个参数就能解决的。

　　问：我的观众主要在微信里看直播，选哪个协议?

　　HLS。微信内置的浏览器对HLS的支持是原生的，m3u8链接可以直接打开播放。HTTP-FLV在微信浏览器中的支持不稳定，依赖MSE的可用性，在部分安卓机型和iOS上可能无法播放。如果你的直播入口主要是微信分享，HLS是唯一可靠的选择。

　　问：内网大屏直播，没有公网CDN，选哪个?

　　HTTP-FLV。内网环境没有CDN扩展性的顾虑，兼容性也不是问题(大屏通常用Chrome或专用播放器)。HTTP-FLV的1到3秒延迟能给操作人员提供更接近实时的画面，这对监控和指挥场景很重要。

　　问：有没有办法兼顾低延迟和兼容性?

　　可以用双协议输出。源流推给流媒体服务器(比如SRS)，服务器同时输出HLS和HTTP-FLV。播放端根据设备类型自动选择：移动端浏览器用HLS，内网大屏用HTTP-FLV。这需要播放器端做一点适配逻辑，但服务器端的配置并不复杂，SRS和ZLMediaKit都原生支持这种模式。

　　问：WebRTC比HTTP-FLV还快，为什么不直接用WebRTC?

　　WebRTC的延迟可以做到0.2到1秒，确实更低。但它的接入复杂度远高于HTTP-FLV，需要处理信令、ICE穿透、NAT等问题，而且不适合走传统CDN，大规模分发的成本很高。WebRTC适合的是“连麦互动”“实时指挥”这类对延迟有极端要求、且观众规模可控的场景。如果你的业务只是“看直播”，HTTP-FLV的1到3秒延迟已经能满足绝大多数需求，没必要为了那一两秒的差距承担WebRTC的复杂度。