hls&flv直播请求过程
直播类产品层出不穷，从各方面塑造了我们的生活方式。直播产品中，延时是决定用户体验的关键因素，它也将间接决定直播产品的成败。这其间，对延时影响较大的就是直播架构中选择的直播协议。
一、HLS 的直播请求详情
1. 先通过循环的加载m3u8文件
2. 加载最新一次m3u8中包含的最新的ts切片，达到直播的效果的。之所以能循环加载，就是因为： 直播的m3u8文件中，没有 #EXT-X-ENDLIST 参数，也就是说，没有结束，需要一直加载。
第一次加载m3u8 的内容如下：
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:31
#EXT-X-TARGETDURATION:5
#EXTINF:5.079,
31.ts
#EXTINF:5.083,
32.ts
#EXTINF:5.201,
33.ts
第二次加载m3u8 的内容是：
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:32
#EXT-X-TARGETDURATION:5
#EXTINF:5.083,
32.ts
#EXTINF:5.201,
33.ts
#EXTINF:5.100,
34.ts
我们能看到，第一次加载m3u8时，ts切片，最后一个切片，名字是 33.ts；第二次加载m3u8时，ts切片，最后一个切片，名字是 34.ts ；
并且，m3u8文件中没有 #EXT-X-ENDLIST
就是通过这种循环加载的方式，这个直播，能一直循环加载下去。下面，我们看下实际的播放加载过程：
1. 首先加载m3u8文件，文件包含 113.ts 114.ts 115.ts 三个文件
2. 因为这是第一次加载m3u8文件，所以，前面是没有加载ts文件的，所以，这次m3u8的内容就是全新的，三个ts文件都需要加载。
3. 在播放器认为应该继续加载新的视频文件时，会先加载m3u8文件，这时，m3u8文件已经更新，和第一次加载的m3u8相比，有一个 116.ts 是需要加载的。
所以，下面只加载了116.ts
基于上述的逻辑，播放器会定期（不一定是固定的时间）的去加载m3u8的视频列表文件，以获取最新的ts视频文件名，从而加载视频文件，完成直播。
二、flv直播请求过程
1. flv简介：将直播流式数据虚拟成为一个无限大的flv文件，并通过HTTP协议进行传输。客户端仅发送一次HTTP GET请求，请求中携带需要访问的直播流名，服务器返回HTTP响应，不携带消息体内容长度直接发送无限长flv文件内容，或者使用HTTP CHUNK模式将无限长flv文件按分段模式发送。客户端获得HTTP消息体中的flv内容时即可播放。
2. 测试请求响应头
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 21 Sep 2019 07:38:01 GMT
Content-Type: video/x-flv
Transfer-Encoding: chunked
Connection: close
Expires: Wed, 21 Sep 2020 07:38:00 GMT
Cache-Control: no-cache
HTTP Header中有Content-Length，那么这个Content-Length既表示实体长度，又表示传输长度。而HTTP-flv这种流，服务器是不可能预先知道内容大小的，这时就可以使用Transfer-Encoding: chunked模式来传输数据了
原文：https://www.cnblogs.com/Kingsoftcloud/p/13300531.html