HLS协议
HLS协议的本质是每次HTTP请求/响应都很快，因此具有良好的适应性，不会受到防火墙的影响。但它也有一个致命的弱点：延迟非常明显。如果每个ts分为5秒，一个m3u8放6个ts索引，那么至少会造成30秒的延迟。如果减少每个ts的长度，减少m3u8中的索引数量，延迟确实会减少，但是会导致缓冲更加频繁，服务器的请求压力也会成倍增加。所以我们只能根据实际情况寻找一个折衷点。
注意：HLS仅支持PC端的Safari浏览器。与使用HTML5视频标签的Chrome浏览器类似，它无法播放m3u8格式。可以直接使用网上一些比较成熟的解决方案，例如：sewise-player、MediaElement、videojs-contrib-hls、jwplayer。
优势：
性能高：
与HTTP 相同。
穿墙：
与HTTP 相同。
兼容性高：
IOS、Android、HTML5 原生支持。
劣势：
实时性差：
基本上HLS的延迟都在10秒以上。
文件碎片：
HLS分布式的话，代码流量低且分片小，小文件分布式不太友好。特别是在一些对存储比较敏感的情况下，比如源站存储、嵌入式SD卡等。
RTMP协议
RTMP基于flash，无法在iOS浏览器中播放，但实时性能比HLS好。因此，该协议一般用于上传视频流，即将视频流推送到服务器。
优势：
实时性高：
RTMP实时性能在3秒以内。经过多层CDN节点分发后，实时性能也在3秒左右。 RTMP主要用在一些需要实时性能的应用中。与YY的UDP私有协议相比，RTMP延迟较大，而与HTTP流的延迟（一般在10秒以上）相比，RTMP延迟较低。对于一般的直播应用，只要不需要电话通话，RTMP延迟是可以接受的。在一般的视频会议应用中，RTMP延迟也是可以接受的。原因是当别人说话时我们通常在听。事实上，1秒的延迟并不重要。我们也得想一想（有些人的CPU处理速度还不高）。这么快）。
经过测量发现，当网络状况良好时：RTMP延迟可以达到0.8秒左右。多级边缘节点不会影响延迟（与SRS同源的某个CDN的边缘服务器可以做到这一点）。 Nginx-Rtmp的延迟有点大。可能是缓存处理或多进程通信引起的？ GOP是一个硬指标，但是SRS可以关闭GOP缓存来避免这种影响。如果服务器性能太低，延迟也会增加，服务器将没有时间发送数据。客户端的缓冲区长度也会影响延迟。例如，如果flash客户端的NetStream.bufferTime设置为10秒，则延迟至少为10秒。
编码兼容性高：
RTMP实际上是现在编码器输出的行业标准协议。基本上所有的编码器（相机等）都支持RTMP输出。原因是PC市场巨大，而PC主要是Windows。 Windows浏览器基本都支持Flash，而Flash对RTMP的支持非常好。
支持加密：
RTMPE 和RTMPS 是加密协议。虽然HLS也有加密，但是flash在PC平台上应该对RTMPE/RTMPS有很好的支持。
稳定性高：
PC平台上播放flash最稳定的方式是RTMP。如果是做CDN或者大中型集群分发，需要选择稳定性高的协议。 HTTP也很稳定，但是HTTP在协议方面是稳定的；稳定性不仅仅是服务器的问题。在集群分布、服务器管理、主备切换、客户端支持等方面，RTMP在PC分布上还是有很大优势的。
由于RTMP支持非常完善，所以可以长时间连续播放flash中的RTMP流。当时的测试是100万秒，也就是说可以连续播放10天以上。对于商业流媒体应用来说，客户端的稳定性当然也是必须的。不然最终用户看不到怎么玩？我认识一个教育客户，最初使用播放器播放http流量，需要播放不同的文件，但总是出现问题。如果切换到服务端将不同的文件转成RTMP流，客户端就可以继续播放；客户采用RTMP方案并通过CDN分发后，从未听说客户端有任何问题。
编码器接入：
编码器输出到互联网（也可以输出到**应用如udp组播），主要是RTMP。比如专业的编码器，或者flash网页编码器，或者FMLE，或者ffmpeg，或者安防摄像头都支持RTMP输出。如果您需要接入多个设备，比如提供云服务；或者你想让网页直接捕捉摄像头；或者可以切换不同的编码器，那么RTMP作为服务器的输入协议将是最佳选择。
系统容错：
容错有多种级别。在实现RTMP集群时，可以指定N个上层。发生错误时的切换不会影响下层或客户端。另外，RTMP流没有标识符，切换到其他服务器的流可以继续播放。 HLS流媒体热备切换并不是那么容易。如果直播对容错性要求较高，比如减少出现问题的概率，RTMP会是一个不错的选择。
可监控：
从监控系统或者运维系统的角度来看，流式协议应该更适合监控。 HTTP流量监控感觉不太完整。这不是绝对的优势，但是相对有利。
劣势：
播放兼容性差：
RTMP最大的弱点是，由于是Adobe专有协议，很多设备无法直接播放，比如iOS，需要外接第三方解码器，会带来发热、耗电等问题。 HTML5无法直接播放RTMP，所以你在手机网页上看到的很多直播都是下面通过HLS推送的。
协议复杂：
RTMP 协议比HTTP 复杂得多，导致性能较低。
测试发现，当两台服务器直连100Gbps网络时，HTTP可以跑到60Gbps，但RTMP只能跑到10Gbps，而且RTMP的CPU占用率要高很多。复杂的协议使得在开发、扩展和维护软件系统时不如HTTP方便。所以现在HTTP服务器很流行，比如apache/nginx/tomcat，HTTP服务器也有很多。 RTMP协议虽然早已公开，但它确实是大规模分布式的。没有一个人表现出色。 Adobe自己的FMS在CDN上经常出现问题。
Cache麻烦：
缓存恶意协议不方便。比如点播，如果使用RTMP流媒体协议，在边缘缓存RTMP会非常麻烦。如果是HTTP的话，缓存其实是很麻烦的，但是HTTP服务器缓存已经做了很长时间了，所以只需要使用它就可以了。这就是所有点播服务都使用HTTP 的原因。
有累积延迟：
技术必须了解其弱点。 RTMP 的一大弱点是累积误差。原因是RTMP是基于TCP的，不会丢包。因此，当网络状况较差时，服务器会对数据包进行缓存，造成累积延迟；当网络状况好转时，它们会一起发送给客户端。解决办法是当客户端的缓冲区很大时断开连接并重新连接。
HTTP-FLV协议
HTTP-FLV 与RTMP 类似，都是针对FLV 视频格式的直播分发流。然而，两者之间存在很大差异。
很简单，直接发起长连接，下载对应的FLV文件头信息。现在市场上比较常用的是HTTP-FLV进行播放。但由于手机上不支持，H5的HTTP-FLV也是一个痛点。不过，现在flv.js可以帮助高版本浏览器通过mediaSource进行解析。 HTTP-FLV 使用起来也非常简单。与HLS 一样，只需添加一个连接：
对象类型=’application/x-shockwave-flash’ src=’xxx.flv’/object
H5直播方案
使用flv.js进行直播：flv.js是Bilibli的开源项目。它解析FLV 文件并将其提供给原生HTML5 Video 标签来播放音频和视频数据，使浏览器无需使用Flash 即可播放FLV。原理：flv.js 只做一件事。获取FLV格式的音视频数据后，通过原生JS对FLV数据进行解码，然后通过Media Source Extensions API喂给原生HTML5 Video标签。 （HTML5原生只支持播放mp4/webm格式，不支持FLV）为什么flv.js要绕一圈，从服务器获取FLV，解码转换，然后喂给Video标签呢？原因如下： 1、兼容当前的直播解决方案：当前大多数直播解决方案的音视频业务均采用FLV容器格式来传输音视频数据。 2、FLV容器格式比MP4格式更简单，解析更快更方便。
兼容方案
PC端1、优先考虑HTTP-FLV，延迟小，性能好。 1080P流畅。 2. 如果不支持flv.js，请使用Flash播放器播放RTMP流。 Flash兼容性非常好，但其性能较差，并且被许多浏览器默认禁用。 3.如果不想使用Flash兼容也可以使用HLS，但PC端只有Safari支持HLS。
移动端1.优先考虑HTTP-FLV，因为它延迟低，并且支持HTTP-FLV的设备性能足以运行flv.js。 2. 如果不支持flv.js，则使用HLS，但HLS延迟很大。 3、如果不支持HLS，则无法进行直播，因为移动端不支持Flash。
我们简单说一下这些协议的优缺点：
看完上面的协议，你一定注意到了一个问题，那就是“延迟”。所有协议都有延迟，最低延迟为500ms。那么为什么会发生这种情况呢？接下来就跟大家简单聊聊“延迟”。
延迟简介
这里简单说一下rtmp和rtsp的延迟。先说rtmp的延迟。圈内有人整理了一张直播延迟（rtmp）的图，我就开门见山说实话。
看完上图你大概就能明白rtmp的延迟是和gop挂钩的。
那么，为什么rtsp延迟比rtmp低呢？因为它是精确控制的，所以你可以以gop 组为单位跳出控制。
RTSP延迟已经是上述四种协议中最低的，那么还有更低延迟的空间吗？
如何减少延迟
经过多次测试，我们公司发现UDP可以直接发送裸流，并且延迟控制在80ms到170ms范围内。
既然直接通过UDP发送裸流的延迟这么低，为什么不流行呢？
原因很简单。 UDP是不可靠传输，丢包，乱序。而且直接裸流的稳定性很差，更不用说兼容性了。没有编码器可以与您连接。这是一项骑自行车走钢丝的工作。这是一个困难的举动。要能够胜任这项工作，你必须是一个技术精湛、胆识过人的人。
附流媒体技术图
用户评论
念旧是个瘾。
直播延迟真的让人头疼，不知道是网络问题还是技术原因，感觉现在的直播平台都存在这个问题。
有6位网友表示赞同！
颓废i
直播延迟的确是个大问题，我在看游戏直播时，总是因为延迟而错过精彩瞬间，希望平台能解决这个问题。
有14位网友表示赞同！
她的风骚姿势我学不来
直播延迟是怎么产生的？我觉得很大一部分原因是因为服务器压力大，希望直播平台能优化一下。
有16位网友表示赞同！
颜洛殇
直播延迟这个问题我已经习惯了，但每次看到延迟高的直播，心里还是有点不舒服。
有6位网友表示赞同！
羁绊你
直播延迟可能是多种原因造成的，除了网络，还有可能是编码和解码问题，希望技术人员能深入研究。
有12位网友表示赞同！
惯例
看直播时总是遇到延迟，感觉像是被欺骗了一样，这样的体验真的太差了。
有9位网友表示赞同！
凉月流沐@
直播延迟是技术难题，但我觉得平台应该承担更多责任，提升服务质量。
有19位网友表示赞同！
﹎℡默默的爱
直播延迟的问题我已经反馈多次了，但效果不明显，真是让人失望。
有9位网友表示赞同！
。婞褔ｖīｐ
直播延迟确实影响观看体验，有时候甚至会导致游戏玩家被坑，希望平台能重视起来。
有10位网友表示赞同！
剑已封鞘
直播延迟是怎么产生的？我觉得这可能是行业发展的一个必经阶段，希望未来能越来越好。
有8位网友表示赞同！
龙卷风卷走爱情
直播延迟的问题，我觉得和网络环境有很大关系，我换个网络环境，延迟就明显好转了。
有19位网友表示赞同！
浅笑√倾城
直播延迟对内容创作者也是一大挑战，延迟高的话，直播效果就大打折扣。
有19位网友表示赞同！
绳情
看直播时总是担心延迟，特别是看体育比赛，错过关键瞬间真的很遗憾。
有20位网友表示赞同！
瑾澜
直播延迟可能是由于直播平台没有足够的带宽支持，希望平台能加大投入，提高服务质量。
有11位网友表示赞同！
_心抽搐到严重畸形っ°
直播延迟的问题，我觉得观众和主播都有责任，观众要选择稳定的网络，主播要选择合适的平台。
有6位网友表示赞同！
陌潇潇
直播延迟是现代直播行业的一个通病，但我觉得随着技术的发展，这个问题终将被解决。
有10位网友表示赞同！
追忆思域。
直播延迟对观众和主播都是一个考验，希望双方都能共同努力，提升直播质量。
有7位网友表示赞同！