流媒体协议—HTTP

http://www.wtoutiao.com/p/5c4KKEX.html

传输协议作为流媒体系统中最重要组成部分之一，在流媒体应用中扮演着关键性作用。本章着重对我们目前业务中常用的基于HTTP的流协议（如HLS、HTTP-FLV）、RTMP等主要流媒体协议以及相关的Websocket 、URL进行详细介绍。

在流媒体相关工作中，我们经常会听到有人问起，这么多流媒体协议我该选用哪个？需要说明的是，各种流媒体协议都有其生存的理由，比如监控行业、电信行业IPTV就不能没有RTSP，因为这里面所有的监控应用程序太多基于RTSP；比如目前的直播主协议就是RTMP，主要是因为CDN对RTMP支持的最好；再比如Apple终端市场占有率太高，就不能够不去考虑HLS。

每一种流媒体协议都有其应用场景，每一种流媒体协议都有其发展的历史原因，每一种流媒体协议都有其自身的优势和不足。所以，我们需要对各种协议的原理、构成、特性都有所了解，才能在自身应用场景中选择出最佳方案。

▼▼▼  

HTTP

通过前面文章，我们知道目前互联网上传输媒体内容的重要方式之一就是通过HTTP来传输的。例如各大视频网站上的HLS点播内容，以及部分直播平台的直播流采用http-flv，H5页面上采用hls等。这些都属于基于HTTP流媒体传输范畴。

总结起来说，基于HTTP的媒体分发可以分为三种方式：

❶  HTTP渐进式：如YouTube、优酷等大型视频网站的点播分发。它的核心区别是媒体文件不分片，直接以完整文件形态进行分发，通过支持Seek,终端播放器可从没下载完成部分中任意选取一个时间点开始播放，如此来满足不用等整个文件下载完快速播放的需求，一般MP4和FLV格式文件支持较好，打开一个视频拖拽到中部，短暂缓冲即可播放，点击暂停后文件仍将被持续下载就是典型的渐进式下载。

❷  HLS类“伪”HTTP流：HLS（Apple）、HDS(Adobe)、MSS(Microsoft) 、DASH（MPEG组织）均属于“伪”HTTP流，之所以说他们“伪”，是因为他们在体验上类似“流”，但本质上依然是HTTP文件下载。以上几个协议的原理都一样，就是将媒体数据（文件或者直播信号）进行切割分块，同时建立一个分块对应的索引表，一并存储在HTTP Web服务器中，客户端连续线性的请求这些分块小文件，以HTTP文件方式下载，顺序的进行解码播放，我们就得到了平滑无缝的“流”的体验。

❸  HTTP流：http-flv这样的使用类似RTMP流式协议的HTTP长连接，需由特定流媒体服务器分发的，是真正的HTTP流媒体传输方式，他在延时、首画等体验上跟RTMP等流式协议拥有完全一致的表现，同时继承了部分HTTP的优势。

以下主要介绍HTTP流媒体传输的一些基本知识，以及对最常用的HLS和HTTP-FLV进行简单分析，此二协议后续文章会专门论述。

HTTP流媒体传输的基础

互联网上最初只能传输一些文本类的数据，自从HTTP协议发明之后，就可以传输超文本的音频视频等等内容，这主要就是靠HTTP协议中的MIME。通过它，浏览器就会根据协议中的Content-Type header去选择相应的应用程序去处理相应的内容。如此，才使得流媒体内容通过HTTP协议传输成为可能。

和流媒体相关的Type列表：

（可点击查看大图）

HTTP流媒体传输技术

01

HTTP request & response

和流媒体相关的http方法主要是GET。GET请求的首部大致如下：

（可点击查看大图）

HTTP的响应头大概是这样:

（可点击查看大图）

02

http协议中content-length 和chunked

我们打开网宿的http-flv流举例：

http://175.25.168.16/pl3.live.panda.tv/live_panda/d4e0a83a7e0b0c6e4c5d03774169fa3e.flv?wshc_tag=0&wsts_tag=57e233b1&wsid_tag=6a27c14e&wsiphost=ipdbm

发现响应头中出现Connection: close 的字段，表示网宿采用的是短连接，则直接可以通过服务器关闭连接来确定消息的传输长度。

（可点击查看大图）

正常的流媒体请求都采用长连接即keepalived的方式来传输数据。Content-length：用于描述HTTP消息实体的传输长度。主要表示压缩后的message-body的长度。以下这种就是content-length的方式。 如果head中有Content-Length，那么这个Content-Length既表示实体长度，又表示传输长度。

（可点击查看大图）

还有一种方式是采用Chunked编码的方式来传输流媒体的内容。例如http-flv这种流，服务器是不可能预先知道内容大小的，这时就可以使用Transfer-Encoding：chunk模式来传输 数据了。

如下的响应就是采用的Chunked的方式进行的传输的响应头：

（可点击查看大图）

03

HTTP协议中代理的应用

▣  http-flv,hls+：如果80端口被占用，客户访问flv或hls+的时候,代理到本地的流媒体服务器监听的端口(例如8080)。

▣  nightclub热升级系统也采用代理的方式。热升级的时候讲新进来的请求代理转发到后端新版本程序监听的端口上，从而可以实现无缝升级。对外都是1935端口(NC监听的)，只是真正服务的端口会变化。

▣  HTTP代理还可以做鉴权等功能

04

302跳转功能

▣  302跳转可以实现主机调度的功能。将请求重定向到合适的服务器上达到调度的效果

▣  可以通过重定向完成负载均衡的功能

▣  可以通过302重定向解决一些新老版本的兼容性问题

HTTP-FLV和HLS

这两种协议是当前HTTP媒体传输最常用，大家也接触最多的协议。它们相比RTMP和RTSP这种传统的流媒体传输协议来说，最大的优点就是它外面封装的是HTTP协议，兼容性很好。可以穿过一些防火墙，还支持灵活的调度，防盗链等等功能。后续文章将专门对它们分别论述，此处仅提及概念。

http-flv一般的实现是：服务器响应http请求的时候不回复content-length字段；这样客户端就会一直接受数据，从而实现了流媒体的传输。当然，flv在播放的时候是需要通过flash插件来播放的。

HLS是媒体数据由服务器端切片器切割存储为为连续的、时长很短（约10s）的媒体文件（MPEG 2-TS格式）,同时创建.m3u8索引文件。客户端读取索引文件，然后按顺序下载和播放.ts文件实现HLS直播流。
HLS相比于http-flv的优点就是不需要任何插件，html5可以直播播放，safari，EDGE等浏览器都可以直接播放HLS的视频流。
其它几种类似HLS的协议，HDS(Adobe)、MSS(Microsoft) 、DASH（MPEG组织）原理都一样，只是切片文件的封装格式和索引文件上有差别而已。

总结

HTTP在流媒体应用场景中，主要体现在传输和控制层面。HTTP对流媒体数据进行封装，再通过底层TCP协议来进行传输，同样再通过成熟的HTTP协议对流媒体进行精确控制、调度等，从而完善了流媒体在互联网中的传播。

和RTMP、RTSP等真正的流式协议比起来，HTTP流媒体分发方式主要优势在于集成了HTTP的诸多优点，比如协议简单性能高，WEB服务器在部署、CDN缓存支持、防火墙穿透等方面都对现有平台兼容性极好。同样，它也有不少缺点，比如大部分HTTP流实时性相对就差，碎片文件多导致性能低下，码流控制机制较为缺乏等。