在直播应用中，RTMP 和 HLS 是两种较为成熟且广泛应用的流媒体协议，基本上可以覆盖所有客户端。RTMP 是互联网 TCP/IP 五层体系结构中应用层的协议，主要优势就是实时性高，基本可将直播延时控制在3秒以内，因此广泛应用于低延时直播。
HLS是由 Apple 公司实现的基于 HTTP 的流媒体传输协议，拥有性能高、完美支持 iOS等优势。相比于 RTMP 协议，HLS 无需在移动端安装 APP，同时兼容HTML5，因此在移动直播的传播和体验上都拥有巨大的优势。不过HLS 的实时性较差，业界的平均直播延时达在10s ~35s。
在让许多用户最头痛的 HLS 延时问题上，又拍云做了针对性的技术优化，实现了 HLS 的超低延时，将 HLS 延时稳定控制在了 4 秒左右。
HLS 高延时原因分析
HLS 理论上延时=1个切片的时长+ 0-1个td(td是EXT-X-TARGETDURATION，可简单理解为播放器取片的间隔时间) + 0-n个启动切片(苹果官方建议是请求到3个片之后才开始播放) + 播放器最开始请求的片的网络延时（网络连接耗时）。
从延时组成公式可以看出，HLS 的延时主要是以下四部分组成：
服务器端的编码器和流分割器生成 TS 文件的时常，HLS 协议应用于直播视频传输时，是将媒体文件切割成了对应于媒体分段的 TS 文件。
播放器取片的间隔时间，在客户端开始下载之前，必须等待服务器端的编码器和流分割器至少生成一个TS 文件。
客户端下载切片的时间及启动播放所需的切片个数，通常下载完两个媒体文件后才能保证不同分段音视频间的无缝连接。
客户端最开始解码并开始播放的时间。
HLS的延时优化主要是针对前三个部分，第四个部分是取决于用户客户端的性能。
又拍云 4S 延时 HLS+ 技术详解
由于客户端每次请求 TS 或 m3u8 可能都是一个新的连接请求，所以，我们无法有效地标识客户端，一旦出现问题，基本无法有效地定位问题，因此一般服务器都会对传统的 HLS 做一些改进。
又拍云 HLS+ ，又称为流式 HLS 技术，将标准的 HLS 进行流式处理，能大幅度降低标准 HLS 延迟，提高HTML5 端直播兼容性，且具有回源量小、系统简单、排错容易、防盗链、避免 HLS 404 等优势。
又拍云 HLS+ 能够标记每个客户端的 HLS 请求，并为每个 HLS 请求建立起连接，再动态的为每个播放请求生成独立的 M3U8 列表，并动态快速的生成仅针对这个播放请求的小切片文件。
为了解决 HLS 请求不友好的问题，又拍云采用Variant HLS+HTTP 302的方式标识客户端的行为。
1、Variant HLS
首先，下载一条又拍云的 m3u8 文件：
wget http://uplive.bo.upaiyun.com/live/loading.m3u8
然后，打开下载得到的 playlist 文件：
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:YES
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:1
#EXTINF:0.998, no desc
可以看出又拍云的 HLS+ 支持这种 Variant HLS 方式来标识一条 HLS 连接，同时是使用 UUID 来表示一条 HLS 连接。
2、HTTP 302
首先，以 HTTP 302 方式来请求播放地址。
❯ curl -v http://uplive.b0.upaiyun.com/live/loading.m3u8\?shp_identify\=302 -o playlist
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 183.158.35.59...
* TCP_NODELAY set
* Connected to uplive.b0.upaiyun.com (183.158.35.59) port 80 (#0)
> GET /live/loading.m3u8?shp_identify=302 HTTP/1.1
> Host: uplive.b0.upaiyun.com
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Server: marco/0.26
< Date: Wed, 22 Mar 2017 08:54:11 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 259
< Connection: keep-alive
< Access-Control-Allow-Methods: GET
< Access-Control-Allow-Origin: *
< Location: http://183.158.35.19:8080/uplive.b0.upaiyun.com/live/loading.m3u8?shp_uuid=2862b1b817a74cf719b1cd8f554616cd&shp_ts=1490172851450&shp_cid=59553&shp_pid=1730488&shp_sip0=127.0.0.1&shp_sip1=183.158.35.19&domain=uplive.b0.upaiyun.com&shp_identify=302
<
{ [259 bytes data]
* Curl_http_done: called premature == 0
100 259 100 259 0 0 4813 0 --:--:-- --:--:-- --:--:-- 4886
* Connection #0 to host uplive.b0.upaiyun.com left intact
打开 playlist 内容：
跳转之后的地址存放真正的 playlist，同时也能够将 UUID 加入到了连接上。
总的来说，不管通过这个方法，最终能通过一个唯一的 ID 来标识一条媒体流，这样在排查问题时就可以根据这个 ID 来定位播放过程中的问题。
又拍云 HLS+延时实测
以下是通过又拍云 HLS+ 直播技术所测试的延迟实例，又拍直播云已可将 HLS 延时控制在4秒左右。
推荐阅读：
让Chrome看不了WWDC直播的HLS技术详解
技术干货|直播转码系统架构与实践
无连麦，不直播，都在说的直播利器连麦互动到底是啥？