7.4.1 把直播搬进 HTTP（Moving Live Streaming into HTTP）

RTMP 的舒适区之外

上一节对 RTMP 的体检报告可以再补几笔。长连接意味着 每台边缘服务器都要为每个观众维护一份连接状态——十万观众就是十万条 TCP，状态同步与故障转移的重担全压在流媒体专用服务器上；1935 端口与私有协议在穿透企业防火墙、透明代理时步步惊心；最致命的是，它无法沾 HTTP 缓存的光——每一个字节都得从源站或专门的流节点实时推出。

这些痛点在 Flash 时代可以忍：播放器垄断在 Flash Player 手里，生态闭环自成一体。可一旦播放端转向浏览器原生与移动端，闭环瓦解，所有代价都得裸泳偿还。

Apple 的解法：直播即文件

2009 年，Apple 以 IETF 私有草案序列的形式抛出 HLS，2017 年 8 月由 Pantos 与 May 整理为 RFC 8216 [8]。核心思想朴素到近乎偷懒：

直播流被切成一串几秒钟的媒体分片（Media Segment），另配一份不断追加的播放列表（Playlist）充当索引。播放器的工作退化为两件小事：定时拉列表、按列表拉分片。连文件格式都不新鲜——那份列表文件的后缀 m3u8，考据起来是 M3U（MPEG URL）播放列表的 UTF-8 版本，一个从 MP3 播放器时代走来的老格式，被顺手征用了。

为什么 HTTP 化就赢了

把直播搬进 HTTP，换来的是整个生态的现成红利：

• CDN 零定制：分片是静态文件，天然可缓存、可回源、可预热——直播分发第一次搭上了内容分发的便车，边缘节点无需任何流媒体专用软件（流媒体经 HTTP/CDN 交付的运营考量，IETF 已有专门文献梳理 [13]）
• 穿透无阻：80/443 端口与标准 HTTP 语义，防火墙与代理对它与普通网页一视同仁
• 无状态扩容：服务器不记任何观众状态，请求来了就回文件——水平扩容只是把文件铺到更多节点，这是 HTTP 三十年验证过的扩容路径
• 实现门槛低：播放器只需会 HTTP GET 与解析文本列表，任何平台都能快速支持

回看 "可靠性 - 实时性" 的天平：RTP 押极端实时，RTMP 退到几秒延迟换可靠，HLS 则干脆再退一大步——用文件粒度换生态。三者没有胜负，只有场景。

代价：延迟与分片长度绑定

天下免费的午餐，账单记在延迟上。编码器要攒够一个分片才能发布，列表更新有周期，播放器要缓冲若干分片才敢开播——端到端延迟与分片时长死死绑定。传统配置下，几十秒的延迟司空见惯，这对赛事直播、连麦互动是难以忍受的。

怎么把延迟压回去？要回答这个问题，得先看清 HLS 的索引体系长什么样——下一节，我们打开那份不起眼的 m3u8。