7.4 直播的 HTTP 化：HLS 与 fMP4（HLS & Fragmented MP4）
7.3 节的结尾给 RTMP 王朝做了一次体检：握手、Chunk、Message、命令四层运转如飞，但队头阻塞悬顶、秒级延迟在基因里、播放端早已倒向 HTTP。历史没有给这套状态化长连接太多留恋的时间——2009 年 Apple 把草案递到 IETF，2017 年定格为 RFC 8216 的 HLS（HTTP Live Streaming），用一种近乎 "偷懒" 的方式赢下了直播分发 [8]：把直播切成一串小文件，交给最普通的 HTTP 去送。
这个 "偷懒" 恰恰是最深的洞察：HTTP 生态三十年积累的基础设施——CDN 缓存、代理穿透、无状态扩容——一夜之间全部可以为直播所用。代价则是延迟与分片粒度死死绑定，这场拉锯战一直打到今天的 LL-HLS。
本节按 "动机 → 索引 → 分片 → 切换 → 延迟" 的顺序递进：
- 7.4.1 把直播搬进 HTTP：RTMP 舒适区之外的痛点；Apple 的 "直播即文件" 解法；HTTP 化的四重红利与代价
- 7.4.2 两级播放列表：Master 与 Media：m3u8 的索引体系；变体流与分片的两级组织；一张列表看清 HLS 的骨架
- 7.4.3 分片机制与直播滑动窗：TARGETDURATION 与 MEDIA-SEQUENCE 的语义；TS 与 fMP4 两种分片载体；EXT-X-MAP 衔接的容器知识回流
- 7.4.4 自适应码率：客户端的切换艺术：BANDWIDTH 的峰值口径；CODECS 声明；客户端如何在变体流之间做决策
- 7.4.5 延迟之战与 LL-HLS：延迟的三重构成；分片缩短的连锁代价；LL-HLS 的分片内再切片思路
完成本节后，我们将理解今天直播拉流端的主流形态，也会在 7.6 的实战里亲手拉一条 LL-HLS 流，量一量 "亚秒级" 的成色。