CN104506493B

CN104506493B - 一种实现hls内容回源和缓存的方法

Info

Publication number: CN104506493B
Application number: CN201410729789.4A
Authority: CN
Inventors: 冯军
Original assignee: WUHAN FONSVIEW TECHNOLOGY Co Ltd
Current assignee: WUHAN FONSVIEW TECHNOLOGY Co Ltd
Priority date: 2014-12-04
Filing date: 2014-12-04
Publication date: 2018-02-27
Anticipated expiration: 2034-12-04
Also published as: CN104506493A

Abstract

一种实现HLS内容回源和缓存的方法，涉及互联网多媒体技术领域。本发明中，缓存服务器接收到客户端发来的一个HLS内容请求后，会为客户端分配一个会话对象，并生成唯一标识；若本地已经缓存该HLS内容，则直接响应当前及后续请求，若未缓存，则缓存服务器需向源站请求该HLS内容的所有索引文件，并修改其中的地址；待收到客户端每次发来的媒体分片请求后，缓存服务器向对应源站请求，将该次媒体分片返回给客户端的同时将该次媒体分片按照索引文件中的顺序连续存储在一个大文件中，直至所有媒体分片存储完。本发明能够完整跟踪客户端行为，且回源流程的适应性强，与源站的对接效率高，存储利用效率及磁盘吞吐率也高。

Description

一种实现HLS内容回源和缓存的方法

技术领域

本发明涉及互联网多媒体技术领域，具体来讲是一种实现HLS内容回源和缓存的方法。

背景技术

HLS(HTTP Live Streaming)是苹果公司提出的基于HTTP的多码率自适应流媒体规范。目前，HLS已成为互联网和移动互联网上主流的流媒体播放规范。该规范支持一个内容具有多个不同码率的媒体文件，每个码率的媒体文件被切分成许多个时长在十秒左右的小文件。一个内容具有几个不同码率，以及一个码率由哪些小文件组成，这些信息被组织在几个索引文件中，这些索引文件采用M3U8格式，因此也被称作M3U8文件。

客户端播放HLS内容的过程，本质上是分别下载索引文件和分片文件的过程，采用标准HTTP协议。HTTP协议的URL格式为："http:""//"host[":"port][abs_path["？"query]]，其中，方括号里的内容表示可选项；http表示指定使用HTTP作为传输协议；host为服务器的域名或IP地址；port为服务器的端口，缺少此地段代表默认使用80端口；abs_path为绝对路径，以“/”符号开头，由零个或多个目录名或文件名组成，相邻名称之间用“/”符合分隔；query为可选字段，用于携带参数，有多个参数时，用“&”符号分隔，每个参数的名和值用“＝”符号分隔。

目前，HLS的媒体播放和网页访问均是采用HTTP协议，并引入了缓存服务器进行HLS内容的回源和缓存。缓存服务器的主要功能是缓存静态内容，当客户端来访问的时候，判断本地是否已经缓存，如果已经缓存则直接将内容返回给客户端，否则先向源站请求内容，再返回给客户端，如果未缓存，则缓存该内容。引入缓存服务器既可以减小源站的访问压力，降低源站到缓存服务器的网络吞吐量，也可以提高客户端的访问速度，从而增强用户的体验。

现有的HLS内容的回源和缓存方法可以在一定程度上达到缓存的效果，从而实现HLS的媒体播放和网页访问。但是，依然存在以下不足：(1)由于HTTP协议是无状态的，这就导致客户端对同一个HLS内容的各个索引文件以及分片文件的请求是相互独立的、零散的，缓存服务器无法完整的跟踪一个客户端的一次播放行为；(2)由于HTTP URL尾部可携带？、&、#等具有特定意义的符号，目前的回源方式没有定义统一的处理规则，因而导致缓存节点与源站的对接效率低；(3)由于一个HLS媒体内容被缓存服务器作为众多相互毫无关联的小文件来存储，这会导致缓存服务器的磁盘碎片多，空间利用率低下，操作粒度小，读写性能低，当缓存服务器的文件描述符开销过大时，还会造成安全隐患。

发明内容

针对现有技术中存在的缺陷，本发明的目的在于提供一种实现HLS内容回源和缓存的方法，能够完整跟踪客户端行为，且回源流程的适应性强，与源站的对接效率高，存储利用效率及磁盘吞吐率也高。

为达到以上目的，本发明采取的技术方案是：提供一种实现HLS内容回源和缓存的方法，包括以下步骤：

S1.缓存服务器接收到客户端发来的一个HLS内容请求后，为客户端的本次请求分配一个会话对象，并生成该会话对象的唯一标识；

S2.缓存服务器判断本地是否已经缓存该HLS内容，若是，转入S5，若否，转入S3；

S3.缓存服务器向源站请求该HLS内容的所有索引文件，修改所有索引文件中的地址，并将修改后的索引文件返回给客户端；

S4.缓存服务器收到客户端每次发来的媒体分片请求后，进行URL解码，获取回源URL，根据该回源URL向对应源站请求该次媒体分片，将该次媒体分片返回给客户端；并将该次媒体分片按照索引文件中的顺序连续存储在一个大文件中，直至所有媒体分片存储完，结束；

S5.缓存服务器根据已缓存下来的HLS内容实时生成索引文件，将索引文件返回给客户端，并响应后续请求。

在上述技术方案的基础上，步骤S1中，所述唯一标识包括会话ID、客户端请求内容的绝对路径、客户端IP和当前时间戳。

在上述技术方案的基础上，所述步骤S3中，缓存服务器向源站请求HLS内容的所有索引文件时，先根据客户端请求内容的绝对路径查找内容路由表，获得对应源站的基地址，将基地址和绝对路径顺序拼接在一起，形成回源URL；再根据回源URL，获取其中的源站主机名信息和端口信息，并向源站的IP地址及端口发起请求。

在上述技术方案的基础上，若根据回源URL获取的源站主机名为域名，缓存服务器则需要向域名服务器请求解析域名，从而获取源站的IP地址。

在上述技术方案的基础上，所述步骤S3中，缓存服务器向源站请求HLS内容的所有索引文件后，先记录所有获取索引文件的URL；再根据每个索引文件的URL和每个索引文件中的路径，拼接出每个索引文件中的路径的对应URL；然后将所有索引文件中的路径修改成统一形式的URL，并将修改后的索引文件返回给客户端。

在上述技术方案的基础上，所述统一形式的URL的格式为http://<服务器IP>:<服务端口>/<会话ID>/<经过URL编码的原路径对应的URL>。

在上述技术方案的基础上，所述步骤S4中，缓存服务器返回一次媒体分片给客户端的具体步骤为：缓存服务器获取客户端媒体分片的请求路径，形式为/<会话ID>/<经过URL编码的原路径对应的URL>；截取该路径中的第一级目录名，获取会话ID，根据会话ID查找会话对象；找到会话对象后根据会话中的客户端IP对客户端进行匹配验证；验证成功后截取该路径中的第二级目录名，取出该请求的绝对路径，进行URL解码，获取被请求对象的回源URL；根据该回源URL向对应源站请求，并将收到的媒体分片返回给客户端。

在上述技术方案的基础上，所述步骤S4中，将媒体分片按照索引文件中的顺序连续存储在一个大文件中时，按照以下规则存储：第一个分片存储在文件的开头；编号在前的分片存储在文件的前面；编号相邻的两个分片存储在文件中连续的一段空间。

在上述技术方案的基础上，所述步骤S4中，将媒体分片按照索引文件中的顺序连续存储在一个大文件中时，缓存服务器需记录每个分片的时长、字节长度和起始字节偏移；且缓存服务器还将索引文件中出现的VERSION、TARGETDURATION、MEDIA-SEQUENCE、PROGRAM-DATE-TIME、STREAM-INF、DISCONTINUITY标签作为元数据记录下来。

在上述技术方案的基础上，所述步骤S5中，缓存服务器根据缓存下来的与相应请求内容相关的元数据实时生成索引文件，将该索引文件返回给客户端，并响应后续请求。

本发明的有益效果在于：

1、本发明中，缓存服务器每次在接收到客户端发来的HLS内容请求后即会为该客户端的本次请求分配一个会话对象，并生成该会话对象的唯一标识。通过该唯一标识，缓存服务器可以完整的跟踪一个客户端的一次播放行为，不仅提高了系统工作的效率，而且可以对用户的整个播放行为进行管控。

2、本发明中，缓存服务器对HTTP URL尾部可携带的？、&、#等具有特定意义的符号按统一规则做了处理，把索引文件中的路径替换成统一形式的URL，实现了一种适应性非常强的HLS回源流程，可提升缓存节点与源站的对接效率，节省了系统资源，提升了用户体验。

3、本发明中，缓存服务器将媒体分片按照索引文件中的顺序连续存储在一个大文件中，能将众多媒体分片的小文件进行整合，减少了缓存服务器的磁盘碎片，更好地利用了缓存服务器的资源，提升了空间利用率及读写性能，并且避免了因缓存服务器的文件描述符开销过大而造成的安全隐患。

附图说明

图1为本发明实现HLS内容回源和缓存的方法的流程图；

图2为缓存服务器请求索引文件并修改索引文件的流程图。

具体实施方式

以下结合附图对本发明的实施例作进一步详细说明。

如图1所示，本发明提供一种实现HLS内容回源和缓存的方法，包括如下步骤：

S1.缓存服务器在调度端口接收到客户端发来的一个HLS内容请求后，为客户端的本次请求分配一个会话对象，并生成该会话对象的唯一标识。其中，所述唯一标识包括会话ID、客户端请求内容的绝对路径(即abs_path["？"query])、客户端IP和当前时间戳。

S2.缓存服务器判断本地是否已经缓存该HLS内容，若是，转入S5，若否，转入S3。

S3.缓存服务器向源站请求该HLS内容的所有索引文件，修改所有索引文件中的地址，并将修改后的索引文件返回给客户端。

S4.缓存服务器收到客户端每次发来的媒体分片请求后，进行URL解码，获取回源URL，根据该回源URL向对应源站请求该次媒体分片，将该次媒体分片返回给客户端；并将该次媒体分片按照索引文件中的顺序连续存储在一个大文件中；缓存服务器再进行下一次媒体分片的返回和存储，直至所有媒体分片存储完，结束。

其中，缓存服务器返回一次媒体分片给客户端的具体步骤如下：缓存服务器获取客户端媒体分片的请求路径，其形式为/<会话ID>/<经过URL编码的原路径对应的URL>；截取该路径中的第一级目录名，获取会话ID，根据会话ID查找会话对象；若没有找到，则拒绝服务，若找到会话对象，则根据会话中的客户端IP对客户端进行匹配验证；若验证失败，则拒绝服务，若验证成功，则截取该路径中的第二级目录名，取出该请求的绝对路径，进行URL解码，获取被请求对象的回源URL；根据该回源URL向对应源站请求，并将收到的媒体分片返回给客户端。

例如：

收到的绝对路径为：/EX6V7A19/http％3A％2F％2F172.16.201.200％2Fpath％2Fto％2Fa％2Fb％2F1.m3u8；

则解析出回源URL为：http：//172.16.201.200/path/to/a/b/1.m3u8；

收到的绝对路径为：/EX6V7A19/http％3A％2F％2F172.16.201.200％2Fx％2Fy％2F2.m3u8；

解析出回源URL为：http：//172.16.201.200/x/y/2.m3u8；

收到的绝对路径为：/EX6V7A19/http％3A％2F％2Ftest.hls.exmaple.com％2Fu％2Fv％2F3.m3u8；

解析出回源URL为：http：//test.hls.exmaple.com/u/v/3.m3u8；

另外，缓存服务器将媒体分片按照索引文件中的顺序连续存储在一个大文件中时，按照如下规则进行：第一个分片存储在文件的开头；编号在前的分片存储在文件的前面；编号相邻的两个分片存储在文件中连续的一段空间。并且，在存储的同时，缓存服务器需记录每个分片的时长、字节长度和起始字节偏移；并将索引文件中出现的VERSION、TARGETDURATION、MEDIA-SEQUENCE、PROGRAM-DATE-TIME、STREAM-INF、DISCONTINUITY标签作为元数据记录下来。

S5.缓存服务器根据已缓存下来的与该HLS内容相关的元数据实时生成索引文件，将该索引文件返回给客户端，并由本地直接响应后续请求。其中，索引文件中分片地址的生成方法为<MEDIA-SEQUENCE>-<时长>-<字节长度>-<起始字节偏移>.ts，例如42-9.7-3073800-129099976.ts。

如图2所示，所述步骤S3中，缓存服务器请求索引文件并修改索引文件的具体步骤如下：

S31.缓存服务器根据会话对象中记录的客户端请求内容的绝对路径查找内容路由表，获得对应源站的基地址，将基地址和绝对路径顺序拼接在一起，形成回源的URL。

S32.缓存服务器根据回源URL，获取其中的源站主机名信息和端口信息，并向源站的IP地址及端口发起请求。

实际中可能出现通过回源URL获取的源站主机名是域名的情况。此时，缓存服务器则需要向域名服务器请求解析域名，从而获得源站的IP地址。

另外，在缓存服务器向源站的IP地址及端口发起请求时，若源站返回的是重定向代码(302)以及新的请求URL，则需向新的请求URL发起请求，直至收到成功接收代码(200)。

S33.缓存服务器收到源站发来的所有索引文件后，记录所有的获取索引文件的URL。

S34.分析索引文件，根据每个索引文件的URL和每个索引文件中的路径，拼接出每个索引文件中的路径的对应URL。

例如：

索引文件的URL是：http：//172.16.201.200/path/to/index.m3u8。

索引文件中的路径1形式是：a/b/1.m3u8；

拼接出路径1的对应URL为：http：//172.16.201.200/path/to/a/b/1.m3u8；

索引文件中的路径2形式是：/x/y/2.m3u8；

拼接出路径2的对应URL为：http：//172.16.201.200/x/y/2.m3u8；

索引文件中的路径3形式是：http：//test.hls.exmaple.com/u/v/3.m3u8；

拼接出路径3的对应URL为：http：//test.hls.exmaple.com/u/v/3.m3u8。

S35.将所有索引文件中的路径修改成统一形式的URL，并实时将修改后的索引文件返回给客户端。其中，该统一形式的URL包括http://<服务器IP>:<服务端口>/<会话ID>/<经过URL编码的原路径对应的URL>。

例如：

将索引文件中的路径1替换成：/EX6V7A19/http％3A％2F％2F172.16.201.200％2Fpath％2Fto％2Fa％2Fb％2F1.m3u8；

将索引文件中的路径2替换成：/EX6V7A19/http％3A％2F％2F172.16.201.200％2Fx％2Fy％2F2.m3u8；

将索引文件中的路径3替换成：/EX6V7A19/http％3A％2F％2Ftest.hls.exmaple.com％2Fu％2Fv％2F3.m3u8。

本发明不局限于上述实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。

Claims

1.一种实现HLS内容回源和缓存的方法，其特征在于，包括如下步骤：

S1.缓存服务器接收到客户端发来的一个HLS内容请求后，为客户端的本次请求分配一个会话对象，并生成该会话对象的唯一标识；步骤S1中，所述唯一标识包括会话ID、客户端请求内容的绝对路径、客户端IP和当前时间戳；

S3.缓存服务器向源站请求该HLS内容的所有索引文件，修改所有索引文件中的地址，并将修改后的索引文件返回给客户端；所述步骤S3中，缓存服务器向源站请求HLS内容的所有索引文件后，先记录所有获取索引文件的URL；再根据每个索引文件的URL和每个索引文件中的路径，拼接出每个索引文件中的路径的对应URL；然后将所有索引文件中的路径修改成统一形式的URL，并将修改后的索引文件返回给客户端；所述统一形式的URL包括http://<服务器IP>:<服务端口>/<会话ID>/<经过URL编码的原路径对应的URL>；

2.如权利要求1所述的实现HLS内容回源和缓存的方法，其特征在于：所述步骤S3中，缓存服务器向源站请求HLS内容的所有索引文件时，先根据客户端请求内容的绝对路径查找内容路由表，获得对应源站的基地址，将基地址和绝对路径顺序拼接在一起，形成回源URL；再根据回源URL，获取其中的源站主机名信息和端口信息，并向源站的IP地址及端口发起请求。

3.如权利要求2所述的实现HLS内容回源和缓存的方法，其特征在于：若根据回源URL获取的源站主机名为域名，缓存服务器则需要向域名服务器请求解析域名，从而获取源站的IP地址。

4.如权利要求1所述的实现HLS内容回源和缓存的方法，其特征在于，所述步骤S4中，缓存服务器返回一次媒体分片给客户端的具体步骤为：缓存服务器获取客户端媒体分片的请求路径，形式为/<会话ID>/<经过URL编码的原路径对应的URL>；截取该路径中的第一级目录名，获取会话ID，根据会话ID查找会话对象；找到会话对象后根据会话中的客户端IP对客户端进行匹配验证；验证成功后截取该路径中的第二级目录名，取出该请求的绝对路径，进行URL解码，获取被请求对象的回源URL；根据该回源URL向对应源站请求，并将收到的媒体分片返回给客户端。

5.如权利要求1所述的实现HLS内容回源和缓存的方法，其特征在于：所述步骤S4中，将媒体分片按照索引文件中的顺序连续存储在一个大文件中时，按照以下规则存储：第一个分片存储在文件的开头；编号在前的分片存储在文件的前面；编号相邻的两个分片存储在文件中连续的一段空间。

6.如权利要求1所述的实现HLS内容回源和缓存的方法，其特征在于：所述步骤S4中，将媒体分片按照索引文件中的顺序连续存储在一个大文件中时，缓存服务器需记录每个分片的时长、字节长度和起始字节偏移；且缓存服务器还将索引文件中出现的VERSION、TARGETDURATION、MEDIA-SEQUENCE、PROGRAM-DATE-TIME、STREAM-INF、DISCONTINUITY标签作为元数据记录下来。

7.如权利要求6所述的实现HLS内容回源和缓存的方法，其特征在于：所述步骤S5中，缓存服务器根据缓存下来的与相应请求内容相关的元数据实时生成索引文件，将该索引文件返回给客户端，并响应后续请求。