为什么现在的视频直播不使用WebRTC协议而是使用RTMP？流媒体协议RTMP和WebRTC优劣对比

融合通信~大型可视指挥调度平台VMS/smarteye，可同时支持私有协议和国标GB28181，即可私有亦可国标，既是私有又是国标，既可做国标上级主平台，亦可以下级平台方式向上级大平台级联，相比单纯的国标平台，具有更大的灵活性和优势，私有协议在传输效果上完胜针对窄带丢包信道的固有顽疾的GB28181；

一旦平台落定，可方便的控制后续设备、厂家的接入，可方便控标。

VMS/smarteye经历过省厅级别及如乌兹别克斯坦等国家级警署总局、上海市局等大系统大平台，近万台真实设备同时在线大并发的实战考验，单体服务器10G网络带宽，20万用户帐号，4000路设备并发推流，云端录像、2000路视频文件并发上传，千锤百炼，坚实稳定可靠。

下面简单说一下这几种协议的优劣：

看了以上这些协议，想必各位都注意到了一个问题，那就是“延迟”。所有的协议里都有延迟，延迟最低的也有500ms。

然而基于WebRTC的标准或自有协议，在含有“互动”的直播场景已经突破到了400毫秒以内的延迟边界，对于常规的社交感，这已经非常低了。越低延时当然观看体验就越好，但是不是所有的直播都要选WebRTC这种技术来达到最小的延时效果呢，这就不一定了。

在说这个问题之前，我们先了解一下为什么会有延时这个问题。

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技术来满足。因为用户对信息的滞后性，互动效果不佳，对整体会议、直播影响都很大。

产品的开发追求极致，想让延时低到极限。但理想丰满，现实骨感。一方面，延时是因多个阶段的数据处理、传输而产生的，无论何时都有其触及天花板的时候。另一方面，针对不同的企业直播场景应用，选择哪种直播技术需要综合延时、视频质量、行业特性、以及付出成本来权衡和选择。低延时可能是最好的，但不是最合适的。

最后，技术总是在不断前进与发展的，我们期待更好的科技带我们走进更美好的生活。