一、HLS 介绍
HLS，全称 HTTP Live Streaming，是苹果公司实现的基于 HTTP 的流媒体传输协议。它可以支持流媒体的直播和点播，主要应用在 iOS 系统和 HTML5 网页播放器中。
HLS 的基本原理非常简单，它是将多媒体文件或直接流进行切片，形成一堆的 ts 文件和 m3u8 索引文件并保存到磁盘。
当播放器获取 HLS 流时，它首先根据时间戳，通过 HTTP 服务，从 m3u8 索引文件获取最新的 ts 视频文件切片地址，然后再通过 HTTP 协议将它们下载并缓存起来。当播放器播放 HLS 流时，播放线程会从缓冲区中读出数据并进行播放。
通过上面的描述我们可以知道，HLS 协议的本质就是通过 HTTP 下载文件，然后将下载的切片缓存起来。由于切片文件都非常小，所以可以实现边下载边播的效果。HLS 规范规定，播放器至少下载一个 ts 切片才能播放，所以 HLS 理论上至少会有一个切片的延迟。
二、HLS的优势和不足
优势：
HLS 是为了解决 RTMP 协议中存在的一些问题而设计的，所以，它自然有自己的优势。主要体现在以下几方面：
RTMP 协议没有使用标准的 HTTP 接口传输数据，在一些有访问限制的网络环境下，比如企业网防火墙，是没法访问外网的，因为企业内部一般只允许 80/443 端口可以访问外网。而 HLS 使用的是 HTTP 协议传输数据，所以 HLS 协议天然就解决了这个问题。
HLS 协议本身实现了码率自适应，不同带宽的设备可以自动切换到最适合自己码率的视频进行播放。
浏览器天然支持 HLS 协议，而 RTMP 协议需要安装 Flash 插件才能播放 RTMP 流。
不足：
HLS 最主要的问题就是实时性差。由于 HLS 往往采用 10s 的切片，所以最小也要有 10s 的延迟，一般是 20～30s 的延迟，有时甚至更差。
HLS 之所以能达到 20～30s 的延迟，主要是由于 HLS 的实现机制造成的。HLS 使用的是 HTTP 短连接，且 HTTP 是基于 TCP 的，所以这就意味着 HLS 需要不断地与服务器建立连接。TCP 每次建立连接时都要进行三次握手，而断开连接时，也要进行四次挥手，基于以上这些复杂的原因，就造成了 HLS 延迟比较久的局面。
三、HLS 直播架构
客户端采集媒体数据后，通过 RTMP 协议将音视频流推送给 CDN 网络的源节点（接入节点）。源节点收到音视频流后，再通过 Convert 服务器将 RTMP 流切割为 HLS 切片文件，即 .ts 文件。同时生成与之对应的 m3u8 文件，即 HLS 播放列表文件。
切割后的 HLS 分片文件（.ts 文件）和 HLS 列表文件（.m3u8 文件）经 CDN 网络转发后，客户端就可以从离自己最近的 CDN 边缘节点拉取 HLS 媒体流了。
在拉取 HLS 媒体流时，客户端首先通过 HLS 协议将 m3u8 索引文件下载下来，然后按索引文件中的顺序，将 .ts 文件一片一片下载下来，然后一边播放一边缓冲。此时，你就可以在 PC、手机、平板等设备上观看直播节目了。
对于使用 HLS 协议的直播系统来说，最重要的一步就是切片。源节点服务器收到音视频流后，先要数据缓冲起来，保证到达帧的所有分片都已收到之后，才会将它们切片成 TS 流。
四、m3u8 格式分析
HLS 必须要有一个 .m3u8 的索引文件 。它是一个播放列表文件，文件的编码必须是 UTF-8 格式。m3u8 文件内容如下：
#EXTM3U
#EXT-X-VERSION:3 // 版本信息
#EXT-X-TARGETDURATION:11 // 每个分片的目标时长
#EXT-X-MEDIA-SEQUENCE:0 // 分片起始编号
#EXTINF:10.922578, // 分片实际时长
test000.ts // 分片文件
#EXTINF:9.929578, // 第二个分片实际时长
test001.ts // 第二个分片文件
...
RFC8216 规定，.m3u8 文件内容以#字母开头的行是注释和 TAG，其中 TAG 必须是#EXT 开头，如上面示例中的内容所示。
接下来，我们对这几个 TAG 做一下说明：
EXTM3U 表示文件是第一个扩展的 M3U8 文件，此 TAG 必须放在索引文件的第一行。
EXT-X-VERSION: n 表示索引文件支持的版本号，后面的数字 n 是版本号数字。需要注意的是，一个索引文件只能有一行版本号 TAG，否则播放器会解析报错。
EXT-X-TARGETDURATION: s 表示 .ts 切片的最大时长，单位是秒（s）。
EXT-X-MEDIA-SEQUENCE: number 表示第一个 .ts 切片文件的编号。若不设置此项，就是默认从 0 开始的。
EXTINF: duration, title 表示 .ts 文件的时长和文件名称。文件时长不能超过#EXT-X-TARGETDURATION中设置的最大时长，并且时长的单位应该采用浮点数来提高精度。
五、TS 格式分析
TS 流最早应用于数字电视领域，其格式非常复杂，包含的配置信息表多达十几个。苹果推出的 HLS 协议对 MPEG2 规范中的 TS 流做了精减，只保留了两个最基本的配置表 PAT 和 PMT，再加上音视频数据流就形成了现在的 HLS 协议。也就是说， HLS 协议是由 PAT + PMT + TS 数据流组成的。其中，TS 数据中的视频数据采用 H264 编码，而音频数据采用 AAC/MP3 编码。TS 数据流示意图如下所示：
TS 数据流由 TS Header 和 TS Payload 组成。其中，TS Header 占 4 字节，TS Payload 占 184 字节，即 TS 数据流总长度是 188 字节。
TS Payload 又由 PES Header 和 PES Payload 组成。其中，PES Payload 是真正的音视频流，也称为 ES 流。
PES（Packet Elementary Stream）是将 ES 流增加 PES Header 后形成的数据包。
ES（Elementary Stream），中文可以翻译成基流，是编码后的音视频数据。
TS 数据流的格式，如下图所示:
这是 TS Header 各个字段的详细说明，图中数字表示长度，如果数字后面带有 bytes ，单位就是 bytes；否则，单位都是 bit。
TS Header 分为 8 个字段，下面我们分别解释一下：
PES Packet 作为 TS 数据流的 Payload，也有自己的 Header，如下图所示：
下面我们就对这些常用的字段一一做下解释，当然也还有很多不常用的字段，我们这里就不列出来了，如有需求，可参考 ISO-IEC 13818-1 2.4.3.7 节。
PES Header 长度是 6 字节，字段说明如下：
参考：从0打造音视频直播系统/04-支持上万人同时在线的直播系统%20(8讲)/32丨HLS：实现一对多直播系统的必备协议.html
从0打造音视频直播系统/04-支持上万人同时在线的直播系统%20(8讲)/31丨一对多直播系统RTMP-HLS，你该选哪个？.html