为什么现在的视频直播不使用WebRTC协议而是使用RTMP？流媒体协议RTMP和WebRTC优劣对比
融合通信~大型可视指挥调度平台VMS/smarteye，可同时支持私有协议和国标GB28181，即可私有亦可国标，既是私有又是国标，既可做国标上级主平台，亦可以下级平台方式向上级大平台级联，相比单纯的国标平台，具有更大的灵活性和优势，私有协议在传输效果上完胜针对窄带丢包信道的固有顽疾的GB28181；
一旦平台落定，可方便的控制后续设备、厂家的接入，可方便控标。
AIoT万物智联，智能安全帽、智能头盔、头盔记录仪、执法记录仪、车载DVR/NVR、布控球、智能眼镜、智能手电、无人机4G补传系统等统一接入大型融合通信可视指挥调度平台VMS/smarteye 。
多源视频融合通信可视指挥调度平台VMS/smarteye概述，https://www.besovideo.com/detail?t=1&i=240
免费的公网对讲平台(PoC/push2talk)，可私有化部署，免费的国标GB28181平台，提供丰富的标准restful规范的WEB SDK，可快速融合客户的业务系统平台，可以实现丰富多样的移动视频终端产品的统一接入，包括但不限于智能安全帽、执法记录仪、各种模拟/数字DMR对讲机、公网对讲机等、摄录手电、头盔天眼摄像头、智能布控球、GPS/北斗定位、车载NVR/DVR、无人机5G视频回传等，https://www.besovideo.com/detail?t=2&i=941
兼容百家的统一独立的执法记录仪可视指挥调度平台VMS/smarteye，作为中性中立的第三方平台，实现对各个厂家设备的统一接入和兼容，可方便的支持大量陈旧设备的升级改造，实现低成本利旧，实现国有资产保值， https://www.besovideo.com/detail?t=1&i=153
VMS/smarteye经历过省厅级别及如乌兹别克斯坦等国家级警署总局、上海市局等大系统大平台，近万台真实设备同时在线大并发的实战考验，单体服务器10G网络带宽，20万用户帐号，4000路设备并发推流，云端录像、2000路视频文件并发上传，千锤百炼，坚实稳定可靠。
关于可视指挥调度平台VMS/smarteye的说明，https://www.besovideo.com/detail?t=1&i=304
下面简单说一下这几种协议的优劣：
| 协议名称 | 优势 | 劣势 |
| rtmp | ● 实时性高：一般能做到3秒内。● 支持加密：rtmpe和rtmps为加密协议。● 稳定性高：在PC平台上flash播放的最稳定方式是rtmp，如果做CDN或者大中型集群分发，选择稳定性高的协议一定是必要的。● 一般主流编码器都支持该协议。 | ● 协议复杂：开发者写起来累，效率也不行。● Cache麻烦：流协议做缓存不方便。 |
| http | ● 性能很高：http的性能好，协议简单，高性能服务器也完善。如果分发的量特别大，譬如点播视频网站，没有直播的实时性要求，http协议是最好选择。● 没有碎片：http相比hls没有碎片。● 穿墙：http协议是互联网唯一肯定会开放的协议，所以不存在封端问题。 | ● 实时性差：延迟10s起步。● 原生支持不好：PC上flash对于http流支持还可以，但是移动端对于http的支持不是很完善 |
| hls | ● 性能好：和http一样。 ● 穿墙：和http一样。 ● 原生支持很好：iOS上支持完美，Android上支持差些。PC/flash上现在也有各种as插件支持HLS。 |
● 实时性差：与ts切片长度有关，大约3个切片长度时间的延迟，基本上HLS的延迟在10秒以上。● 文件碎片：若分发HLS，码流低，切片较小时，会导致太多的文件碎片 |
| rtsp | ● 延迟低，一般都能够做到500ms。● 带宽好，时效率高。● 倍速播放，主要是回放的时候提供的功能。● 控制精准，任意选择播放点。 | ● 服务端实现复杂。● 代理服务器弱：数量少，优化少。● 无路由器防火墙穿透● 管流分离：需要1-3个通道。 |
看了以上这些协议，想必各位都注意到了一个问题，那就是“延迟”。所有的协议里都有延迟，延迟最低的也有500ms。
然而基于WebRTC的标准或自有协议，在含有“互动”的直播场景已经突破到了400毫秒以内的延迟边界，对于常规的社交感，这已经非常低了。越低延时当然观看体验就越好，但是不是所有的直播都要选WebRTC这种技术来达到最小的延时效果呢，这就不一定了。
在说这个问题之前，我们先了解一下为什么会有延时这个问题。
信息的传递需要介质，而介质其实就是一个载体，打个比方，你要从深圳到北京，需要选择飞机、高铁等交通工具，而这个乘坐交通工具的过程就需要耗费一定的时间。而直播的过程中，也需要借助网络在一定的时间来完成信息的传输，所以会有一定的延时。
相关视频推荐：
LinuxC++音视频开发视频：免费】FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发
【文章福利】：小编整理了一些相关的音视频开发学习资料（资料包括C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等），qun994289133免费分享，有需要的可以加群领取哦！~点击裙994289133加入领取资料
不仅乘车的行程需耗时，包括登机、起飞、飞行天气、下机、拿行李，这些事也需要时间。这和直播数据传输类似，直播是一台设备端和另一台设备端的信息传输，在采集端的音话采集、前处理、编码，播放端的接受、解码、后处理，包括采集端传输数据到服务端、服务端传输数据到数据分发节点，再到播放端接收到数据都会遇到延迟，而且服务器之间也会有任务排队、编解码处理等延时。这就导致了直播信息传输的延时。
RTMP和RTSP这两者都是基于TCP协议。TCP诞生于40年前并为互联网的标准，意思是当设备A传输内容到设备B的时候，两台设备都要使用相同的TCP协议才能实现信息的发送与接受，发送数据前进行三次握手建立连接，而且发送的内容也会有一些拆分和拼接。
RTSP传输一般需要2-3个通道，命令和数据通道分离，而RTMP一般在一个通道上传输命令和数据。这就像奥运百米赛，RTSP是三个运动员站在三条跑道上冲刺，而RTMP是三个运动员站在一条跑道上，这个结果自然是RTSP要快一点。所以RTSP的延时一般在0.6s—1.2s，而RTMP延时要长一些，到了3s—7s。
RTSP虽然实时性最好，但是实现复杂，适合视频聊天和视频监控；RTMP强在浏览器支持好，加载Flash和RTMP的H5插件后就能直接播放。
随着技术的不断发展，谷歌开放的实时通信框架WebRTC在市场得到了广泛的应用，包括阿里、腾讯云、华为等大厂都采用了这个技术。
WebRTC与前两者不同，其不以TCP协议为主而是基于UDP协议来实现的，UDP是一个非连接的协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上，而且它不会对数据报文进行任何拆分和拼接操作，效率比TCP要高。另一方面，WebRTC的一些机制可以处理丢包、乱序、延时到达等情况。这使得传输不仅可以对抗弱网环境，还可以实现小于400毫秒的延时。
这样看WebRTC在弱网和低延时上好像是略高一筹？不过有个点还需要提及，就是其对CDN支持较差，所以后面才会出现基于WebRTC的自由封装协议。而RTMP和RTSP，对CDN支持良好，大部分主流的CDN厂商都可以支持。
那么，我们再回到最初的问题，WebRTC延时低，是不是所有直播就得选它，答案当然是否定的。WebRTC技术出现后，像RTMP、RTSP由于具备良好的实用性和推流的稳定性并没有被市场淘汰。除了RTMP、RTSP在性能的稳定外，成本也是重要因素。
在同样的视频画质下，WebRTC每人每分钟的成本是RTMP成本的三倍。细算之下，要是搞一天的万人直播会议，对比RTMP采用WebRTC技术，老板收到账单简直要瑟瑟发抖。
综上所述，我们可以知道，技术的应用是需要具体情况具体分析的，就像购物需要根据自己具体需求与预算来制定计划的。在实时音视频应用当中，每个行业对低延时的要求是不同的。
比如游戏直播，体育赛事，新闻直播这类规模较大但对延时要求不高的直播，有几秒延时不会产生本质影响，就可以采取RTMP技术。
而像视频会议，小班课教学，直播卖货这种人数较少、需要频繁互动的场景，就需要WebRTC技术来满足。因为用户对信息的滞后性，互动效果不佳，对整体会议、直播影响都很大。
产品的开发追求极致，想让延时低到极限。但理想丰满，现实骨感。一方面，延时是因多个阶段的数据处理、传输而产生的，无论何时都有其触及天花板的时候。另一方面，针对不同的企业直播场景应用，选择哪种直播技术需要综合延时、视频质量、行业特性、以及付出成本来权衡和选择。低延时可能是最好的，但不是最合适的。
最后，技术总是在不断前进与发展的，我们期待更好的科技带我们走进更美好的生活。