不同音视频传输协议的对比

一、直播

直播场景通常使用的有hls协议、http-flv渐进式传输、RTP协议、DASH协议、RTMP协议，当然还有一些公司自己研发的私有(一般是UDP)协议。此外还有一些较少为人所知的HDS(adobe出品的与hls/dash匹配的码率自适应协议HTTP Dynamic Streaming)、SSTR/MSS(微软出品的码率自适应协议Smooth Streaming Transport Protocol)

各个协议对比：

协议	传输层	客户端支持	优势	劣势
hls	HTTP短连接	ios/android端及H5原生支持，flash/PC端等需要自研播放器	支持广泛，HTTP请求支持简单，网络兼容性好，码率自适应，服务端及CDN支持好	延时太长，10s以上，单分片文件较小不便存储
http渐进式传输	HTTP长连接	flash支持，ios/android/PC端/H5需要自研	延迟相对较小，HTTP请求简单，网络兼容性好，服务端及CDN支持好	容易被劫持，多端兼容较为麻烦
rtp	UDP	Android端支持，其他各端都需要自研	延迟小	服务端逻辑复杂，协议及控制协议较难理解，开发周期长，客户端支持很难
dash	HTTP短连接	H5原生支持，其他端需要转换格式	开放标准支持广泛，码率自适应	服务端及商业CDN支持不够，使用不广泛
rtmp	TCP长连接	flash支持，其他需要自研	延迟较小	服务端压力相对较大，协议较为复杂，客户端兼容播放麻烦
私有协议	UDP	完全需要自研	延迟可以做到很小，保密性较好，业务自行扩展性高	开发难度极其大，客户端/协议定义/流服务端及CDN都需要自行开发支持，传输可靠性难以保证

多说一句：上面表格中传输层一列，并不是指该种传输方式对应的传输层协议（实际上传输层应该就是我们说的UDP/TCP），而是我们工作场合便于理解，常提到的传输和连接方式（有的是介于传输层和应用层的）。比如HTTP短连接和HTTP长连接，其实HTTP严格来说是基于TCP的应用层协议，但TCP连接的通道可以保持一段时间不关闭，这样就实现了“所谓的”HTTP长连接。实际上对于HTTP而言，就是完成HTTP REQUEST和HTTP RESPONSE，但如果传输层的TCP连接未断开，则可以仍旧在这个通道中继续request和response。

目前国内互联网直播使用协议场景：

业务场景	使用协议情况
web端直播	http-flv,rtmp,hls都有使用。一般如果结合P2P使用，会选择flv和hls
移动端互动直播	较多使用http-flv，个别厂家使用私有协议
移动端大型直播	较多使用http-flv和hls
web端推流	主要使用rtmp，少数使用rtp
移动端推流	主要使用rtmp，少数使用rtp，个别厂家使用私有协议

个人比较看好dash的发展，标准总是需要统一的嘛，但感觉要10年后了。。。

二、点播

点播的协议有hls,DASH,常见的基于http传输的mp4和flv,以及部分公司的私有协议。

写到这里我突然觉得confused。网上一大坨都是直接拿mp4/flv和hls并列对比，你说怎么能把mp4、flv和hls放一起对比呢？感觉不对呀！！确实我们通常是基于http协议来传输mp4和flv，但说白了mp4和flv是一种封装音视频的标准（是一个盒子），应该对应hls协议里面的ts/fMp4、DASH的mpd这些嘛，而且我们也可以用私有协议来传输mp4和flv呀。但是为了便于理解，我们沿用这种奇怪的对比方式。

各个协议对比：

协议	传输层	客户端支持	优势	劣势
mp4	一般http	广泛支持	各种设备及服务端、CDN都通用	文件头过大且会累积
hls	http	H5/iOS/android原生支持，其他需要自研	码率自适应，直播切点播时可以实时生成	拖拽可能不够精准，对于超长点播可能分片较多
flv	一般http	flash支持，ios/android/PC端/H5需要自研	格式简单	多端兼容略微麻烦
dash	http	H5原生支持，其他需要转换	码率自适应，标准规范	服务端及CDN支持不够，使用不广泛
私有协议	udp	同直播	与直播不同的是，更多的结合P2P使用，用于合理利用带宽	同直播

目前国内通常使用搭配：

1).短视频播放——用整段mp4的较多
2).与直播无关的长视频播放——用分段的mp4/flv较多;也有少数厂家开始使用HLS/DASH，但由于码率自适应对客户端的适配要求以及服务端转码要求不低，所以并没有被真的广泛使用；有技术积累的厂家会用私有协议传输，叠加P2P
3).直播生成的回放——用hls较多。因为hls可以在直播过程中就转码切片生成ts，而且可以实现直播实时观看回放（*但这种情况不适用于互动直播）。当然也可以考虑使用分段的mp4/flv，但是这样在直播结束时需要更新最后的文件头，以及直播转回放的URI查询接口，会比较麻烦，也不适用于直播实时观看回放的场景。

对于mp4和hls，有一种方法可以结合二者的优点，具体见文章MP4大文件虚拟HLS分片技术，避免点播服务器的文件碎片