1. HLS协议基础：从诞生到实战
1.1 HLS协议发展史
HLS（HTTP Live Streaming）是苹果公司在2009年推出的流媒体协议。说实话，当时市面上已经有了RTMP、RTSP这些协议，苹果为什么还要另起炉灶？
我个人的理解是——苹果想要一个「纯HTTP」的方案。你想想看，传统的流媒体协议需要专门的服务器和端口，防火墙配置起来特别麻烦。而HLS直接跑在HTTP 80/443端口上，CDN可以直接缓存，这简直是降维打击。
我记得2012年刚接触HLS时，它只支持MPEG-TS格式，延迟也高得吓人。但苹果一直在迭代：
- 2014年：支持fMP4格式，告别了TS的冗余结构
- 2016年：引入LL-HLS（低延迟HLS），目标延迟降到2-3秒
- 2020年：支持CMAF（Common Media Application Format），与DASH统一底层格式
嗯，这里要注意一个关键点：HLS虽然叫「直播」，但它本质上是一个分段下载的方案。服务器把视频切成一个个小文件，客户端按顺序下载播放。这个设计思路贯穿了整个HLS体系。
核心认知：HLS不是真正的「流」，而是「伪流」——它把流媒体伪装成静态文件下载。这个特性让它天然适合HTTP缓存和CDN分发。
1.2 HLS工作原理
HLS的工作原理，说白了就是三个角色：切片器、索引文件、播放器。
我画了一张流程图，帮你理清它们的关系：
整个流程其实很简单：
- 编码器把原始视频压缩成H.264/H.265格式
- 切片器把连续的视频流切成2-10秒的小片段
- 每个片段保存为独立的
.ts或.m4s文件 - 同时生成一个
.m3u8索引文件，记录所有片段的URL - 播放器先下载
.m3u8，然后按顺序请求片段
避坑指南：我曾经在项目中遇到一个问题——切片时长设置成了10秒，结果用户切换码率时要等10秒才能看到效果。后来我改成2秒切片，虽然索引文件大了点，但用户体验好多了。建议直播用2-4秒，点播用6-10秒。
1.3 M3U8索引文件详解
M3U8是HLS的核心。说白了，它就是一个播放列表。我直接给你看一个实际项目中的例子：
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:168
#EXTINF:6.000,
segment_168.ts
#EXTINF:6.000,
segment_169.ts
#EXTINF:4.320,
segment_170.ts
#EXT-X-ENDLIST每个标签都有它的意义：
#EXTM3U：文件头，告诉播放器这是HLS索引#EXT-X-VERSION：协议版本，版本越高支持的特性越多#EXT-X-TARGETDURATION：单个片段的最大时长#EXTINF：片段时长和文件名#EXT-X-ENDLIST：表示直播结束（点播文件必须有）
如果是多码率自适应，还会有一个主索引文件：
#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=1280000,RESOLUTION=720x480
low.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2560000,RESOLUTION=1280x720
mid.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5120000,RESOLUTION=1920x1080
high.m3u8播放器会根据当前网络带宽，自动选择最合适的码率。这个机制我特别喜欢——它让视频播放变得「智能」了。
1.4 HLS与DASH对比
很多新手会问：HLS和DASH到底选哪个？我直接给你一张对比表：
| 对比维度 | HLS | DASH |
|---|---|---|
| 提出者 | 苹果（2009） | MPEG（2012） |
| 索引格式 | M3U8（文本） | MPD（XML） |
| 容器格式 | TS / fMP4 | fMP4 / WebM |
| 加密方案 | AES-128 / SAMPLE-AES | CENC（通用加密） |
| 浏览器支持 | 原生支持（Safari） | 原生支持（Chrome） |
| 低延迟 | LL-HLS（2-3秒） | LL-DASH（2-3秒） |
| CDN友好度 | ★★★★★ | ★★★★☆ |
我个人在实际项目中的选择策略是这样的：
- iOS生态：必须用HLS，苹果强制要求
- Android/Web：DASH更灵活，支持更多编码格式
- 全平台覆盖：两个都支持，用CMAF统一底层
注意：不要以为DASH就一定比HLS好。我见过一个项目，团队非要上DASH，结果发现某些老旧Android设备不支持，最后还得降级到HLS。选协议要看你的用户群体，不是看技术先进性。
1.5 我的实战建议
做了这么多年HLS，我总结了几条经验：
- 切片大小要合理：2-4秒是黄金区间，太短增加请求数，太长影响切换速度
- 索引文件要缓存：M3U8文件很小，但每次请求都会产生开销，建议CDN缓存1-2秒
- 备好降级方案：HLS不是万能的，遇到极端网络环境，要能回退到HTTP渐进式下载
- 监控是关键：我习惯在播放器里埋点，记录每个片段的下载耗时和播放成功率
嗯，HLS的基础知识就讲到这里。记住一句话：HLS的本质是「用HTTP的简单，解决流媒体的复杂」。理解了这一点，后面的内容就好办了。
一句话总结：HLS把连续的视频流切成小文件，用M3U8索引文件管理，通过HTTP协议分发。它牺牲了实时性，换来了极致的兼容性和CDN友好度。
可可精品资料库