破解HLS低延时的密匙: HLS＋技术解密（一）
大红大紫的2016直播年已经过去大半，如果盘点网络直播领域重大的技术创新，观止云首创的流式HLS技术（观止云首次提出概念并命名其为HLS+）一定值得大书特书，浓墨重彩。HLS+技术面世后在业内引起了极大关注，并已陆续接入商用测试客户，将其应用到纯音频互动直播、VR直播等场景中。
观止云以往文章中曾介绍过HLS+研发目标之一就是要大幅降低采用标准HLS协议进行直播的延时，HLS+ 在以下9个方面具有突出优势：
（1）大幅降低传统HLS协议的延时；
（2）HLS+与RTMP/FLV等协议共用同一个流媒体服务器集群，CDN网络可省一套设备组（众多机房和设备建设）；
（3）HLS+与RTMP/FLV/HLS等使用同一个域名，用户配置简单，使用简单，域名CNAME简单；
（4）数据统一，系统给出的在线人数，带宽，计费，防盗链，鉴权认证等，全部统一实现，无需单独区分协议；
（5）合并回源，访问RTMP/FLV/HLS+只需回一路RTMP，并且是访问时才回源，大幅降低了客户源站带宽与回源压力；
（6）快速排错，HLS+使用观止云BMS可追溯日志，可以毫秒级抓取到每个客户端链接数据，实现快速排错；
（7）快速启动，通过GOP优化能做到无感官差异的快速启动；
（8）避免404，HLS是切片文件分发，会有一定概率的404，而HLS+为流式回源杜绝了此情况；
（9）避免每次回源取片的时间，HLS每个切片从源站到边缘都得回源，而HLS+使用长连接回源。
HLS+技术为移动WEB端互动直播进行了一次底层技术升级，将为移动端互动直播再添一大神器。观止云将以系列文章形式详细介绍HLS+技术的几个关键算法，此文先介绍HLS+实现的基础 —— 虚拟连接。
大家都知道，HLS协议是由.m3u8索引文件和一系列.ts音视频文件组成，客户端播放时根据索引找到对应音视频文件的网络地址进行顺序播放。而客户端是独立发送这一系列的请求，各个m3u8和ts请求间是没有相互联系的。正因为如此，当有多个HLS请求时，服务器是无法识别每个m3u8或ts请求归属于哪个客户端的。
HLS+能够标记每个客户端的HLS请求，并为每个HLS请求建立起虚拟连接，再动态的为每个播放请求生成独立的m3u8列表，并动态快速的生成仅针对这个播放请求的小切片文件。实际上，为了解决HLS请求的不友好，业内已有友商采取了标识客户端的行为。下面介绍观止云CDN是如何识别客户端并建立起HLS+的虚拟连接。
（1）使用X-Playback-Session-Id识别
苹果客户端在播放HTML5标签上的m3u8时会启动多个线程来获取数据（一般是4个线程），为了标识HLS会话，苹果客户端在请求m3u8和ts片请求中都会带有X-Playback-Session-Id这个参数，服务器就直接以此标识客户。
（图：iphone播放html5标签上的HLS）
然而，X-Playback-Session-Id并不是万能的。比如直接使用sarafi播放m3u8的时候第一次m3u8请求是没有X-Playback-Session-Id的，而非苹果的客户端压根就没有这个参数。所以必须还得使用另外的方法来标识m3u8会话。
（图：Sarafi播放HLS）
（2）UUID
UUID标识的大体思路就是每当客户端第一次请求m3u8时，服务器就对这个请求做一次HTTP302重定向，将UUID加入重定向的URL中。这样此客户端以后的请求将带有UUID，服务器以此识别客户端。
（图：Sarafi播放HLS+）
（图：Android播放html5标签上的HLS+）
（3）连接标识
绝大多数客户端都是乖孩子，只要给了UUID，他们会生生世世都带着这个“身份证”。对于那些不乖的，弄丢了UUID“身份证”的怎么办？观止云BMS将标识连接。HLS播放请求一般使用TCP长连接，那么该长连接将被视为一个HLS会话。
HLS+的虚拟连接，除了对标准HLS协议实现流式处理的前提，也提供了HLS请求的可追溯日志的实现基础。比如某个HLS请求是何时发起的，又是何时结束的，每个HLS请求的各种数据表现等等。以此为依据，还可以对不同的客户端采用不同的优化策略。HLS+基于可追溯日志的各种数据与RTMP、HTTP-FLV一样，同样汇聚到了观止云大数据平台，提供着毫秒级定位故障、智能分发路由优化、实时业务数据分析等能力，请参考观止云以往文章：
《可追溯日志：视频云时代的新运维大胸器》
《60毫秒，从海量直播日志中实时定位故障》
未完待续：观止云HLS+技术还在紧张的升级与优化之中，很快，HLS+将使移动Web端互动直播真正“互动”起来。后续同系列文章将进一步介绍HLS+技术另外两大关键算法——如何给片？如何快速启动？