直播协议 优势 劣势
RTP /RTCP RTP 实行有序传送,RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，如在视频解码中，就不需要顺序解码。RTCP的主要功能是为RTP所提供的服务质量提供反馈，例如：RTP传输字节数，传输分组数，丢失分组数，单向和双向网络延迟等。网络应用程序可以利用RTCP所提供的信息来提高服务质量，比如限制流量或改用压缩比小的编解码器 RTP载荷的最大尺寸为1460字 节。以H264 为例，如果一帧数据大于1460，则需要分片打包，然后到接收端再拆包，组合成一帧数据，进行解码播放。
RTSP:(Real Time Streaming Protocol)实时流协议 RTSP 是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。而且，RTSP 可基于RTP 来传送数据，还可以选择 TCP、UDP、组播 UDP 等通道来发送数据，具有很好的扩展性 1.服务端实现复杂。2.代理服务器弱：数量少，优化少3. 无路由器防火墙穿透。4. 管流分离：需要1-3个通道
RTMP协议(Real Time Messaging Protocol)实时消息传输协议 RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。该协议基于TCP，RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。1.速度快，误码率低，延迟低 。2.RTMP 是专为流媒体服务而生，协议在制定的时候就考虑到很多底层的优化3.消息块的传输能够提供更加稳定的直播环境，在硬件上要求会更高，但是却能够缓解http的繁琐的传输介质 1.不支持Html5传播、浏览器推送 2.基于TCP协议,虽然开发难度大，推广度还不够，对于开发人员来说门槛比较高 3.硬件要求相较于HLS较高。 4. 协议复杂：开发者写起来累，效率也不行。5.Cache麻烦：流协议做缓存不方便。
HTTP-FLV协议 FLV协议由Adobe公司主推，即将音视频数据封装成 FLV，然后通过 HTTP 协议传输给客户端，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，在延迟表现和大规模并发方面都很成熟。但是在手机浏览器上的支持非常有限，但是用作手机端APP直播协议却异常合适。 1.需要http长连接 2.h5中需要使用插件。3.需要flash技术支持，不支持多音频流，多视频流，不便于拖动
HLS协议 HLS协议苹果推出，将视频分成5-10秒的视频小分片，然后用m3u8索引表进行管理，由于客户端下载到的视频都是5-10秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟(HLS的一般延迟在10-30s左右)。实际上还是纯“文本协议”相比于FLV，HLS在iPhone和大部分android手机浏览器上的支持非常给力。HLS协议客户端支持简单, 只需要支持 HTTP 请求即可, HTTP 协议无状态, 只需要按顺序下载媒体片段即可，而且网络兼容性好, HTTP 数据包也可以方便地通过防火墙或者代理服务器。但是相比RTMP 这类长连接协议, 用到互动直播场景延时较高。 相比 RTMP 这类长连接协议, 延时较高, 难以用到直播场景。对于点播服务来说, 由于 TS 切片通常较小, 海量碎片在文件分发, 一致性缓存, 存储等方面都有较大挑战，小文件碎片化严重

直播协议hls，rtmp，http flv，rtsp

协议 传输方式 视频封装格式 延时 数据分段 HTML5直播 应用场景
HLS Http流 ts文件 10~30s 切片 支持 H5直播，游戏直播
RTMP tcp流 flv tag 2s~5s 连续流 不支持 互动直播
http flv HTTP流 flv 2s~5s，优于rtmp 连续流 支持 互动直播
rtsp tcp/udp流 flv 一般做到500ms以下 连续流 不支持 互动直播