低延时直播的协议选择：RTMP还是webrtc？

如果你正在搭建一个直播系统，或者正在为现有系统选择新的传输协议，那么"到底该用RTMP还是webrtc"这个问题，你一定绕不开。我自己也曾经在这个选择上纠结过，所以今天咱们就一起来聊聊这个话题，看看这两种协议到底有什么区别，分别适合什么场景，以及怎么做出最适合自己的选择。

先搞懂这两个协议到底是什么

在说区别之前，我觉得有必要先说说这两个协议的基本情况，毕竟理解底层原理才能做出正确的选择。

RTMP这个协议其实是Adobe在很久以前搞出来的，全称叫Real Time Messaging Protocol。从名字就能看出来，它一开始就是为实时消息传输设计的。早期因为Flash播放器特别流行，RTMP几乎是网页视频播放的事实标准。虽然现在Flash已经退出历史舞台了，但RTMP这个协议因为成熟、稳定、生态丰富，所以在直播领域依然占有一席之地。很多推流工具、CDN服务商、转码服务都是围绕RTMP构建的，整个技术栈非常完善。

WebRTC的情况就不太一样了。它全称叫Web Real-Time Communication，是Google主导开发的一套开源技术。和其他协议不太一样的是，WebRTC从一开始就不是单纯的文件传输协议，它是一套完整的实时音视频通信解决方案，里面包含了采集、编解码、传输、渲染等一整套东西。更关键的是，它原生支持P2P通信，也就是说数据可以直接在两个终端之间传输，不需要经过服务器中转，这对降低延迟有非常大的帮助。

延迟这个事儿，到底差多少？

说到直播，大家最关心的可能还是延迟问题。毕竟直播互动体验好不好，延迟说了算。那这两个协议的延迟表现究竟如何呢？

我们先看传统的RTMP方案。一般来说，RTMP的端到端延迟大概在2到5秒这个区间。这个延迟主要来自几个方面：首先，RTMP本身是基于TCP协议的，TCP要保证数据可靠性，就会有重传和确认机制，这在网络不好的时候会明显增加延迟。其次，传统的RTMP直播架构通常需要经过多个环节——主播端推流到RTMP服务器，服务器再转码，再通过CDN分发到各个边缘节点，最后观众端拉流。每个环节都会贡献一定的延迟，累积起来就不是一个小数字了。

WebRTC在这方面的优势就体现出来了。因为它原生支持UDP传输，而且有自己的一套丢包控制和拥塞控制机制，再加上很多场景下可以走P2P路线，所以在网络条件良好的情况下，端到端延迟可以控制在500毫秒以内，一些优化得比较好的场景甚至可以做到200毫秒左右。这个延迟水平基本上已经可以满足实时互动的要求了——主播和观众之间的对话、连麦PK这些场景都不会有明显的感觉。

不过这里我要说个但是的事儿。刚才说的延迟数据都是在理想情况下的表现，实际应用中会受到很多因素影响。比如网络质量、服务器处理能力、编解码效率等等。而且WebRTC虽然延迟低，但它对网络的要求其实更高，如果网络波动比较大，WebRTC的体验反而可能不如RTMP稳定。

除了延迟，还需要考虑什么？

选协议不能只看延迟，还得综合考虑其他因素。让我给你列个表格对比一下，这样看得更清楚。

对比维度	RTMP	WebRTC
延迟	2-5秒	200-500毫秒
传输协议	TCP	UDP
生态成熟度	非常成熟，工具链完善	相对较新，但发展迅速
移动端适配	需要额外开发	原生支持
CDN支持	几乎所有CDN都支持	支持相对有限
浏览器兼容性	需要Flash或插件	原生支持
P2P支持	不支持	支持

生态和兼容性这个事儿

RTMP因为出来得早，整个生态已经非常完善了。你去市场上找推流软件，十个里面有九个都支持RTMP。各种云服务商的直播解决方案也基本上都是基于RTMP构建的。如果你需要用CDN来分发内容，RTMP基本上是必选，因为这是CDN厂商最擅长处理的协议。

WebRTC的浏览器兼容性反而是它的优势之一。现在主流的Chrome、Firefox、Safari、Edge都原生支持WebRTC，不需要任何插件就可以直接用。这一点对于Web端应用来说非常友好。但是CDN支持方面，WebRTC确实不如RTMP成熟。虽然这几年有一些厂商开始提供WebRTC的CDN服务，但整体覆盖率和RTMP还是有差距的。

移动端的表现

现在直播的主要场景都是在移动端，所以移动端的适配很重要。RTMP在移动端其实需要做不少额外的工作——你需要自己处理采集、编码、推流这些环节，Android和iOS的适配工作也不轻松。而WebRTC在移动端的支持其实做得不错，它的SDK封装得比较好，很多底层的东西已经帮你处理好了，开发起来相对省心一些。

不同场景下该怎么选？

说了这么多，到底该怎么选择呢？我觉得还是要看具体的业务场景。不同场景对延迟、稳定性、互动性的要求都不一样，不能一概而论。

秀场直播和PK连麦

如果是做秀场直播、连麦PK这种需要强互动的场景，那WebRTC几乎是必选。为什么呢？因为这类场景最核心的需求就是低延迟。想象一下，主播和观众在PK，观众刷礼物之后希望立刻看到效果，如果延迟好几秒，体验就会非常差。又比如连麦对话，两人如果隔着一两秒的延迟聊起天来会非常別扭，根本没法正常交流。

像秀场转1v1、多人连屏这些玩法，更是需要实时互动的基础。这时候WebRTC的低延迟优势就完全体现出来了。而且这类场景通常对画质要求没有那么极端，反而是对延迟更加敏感，所以WebRTC的编码效率问题也不会成为太大的瓶颈。

一对一的视频社交

1V1视频社交这个场景，其实和连麦直播有点类似，但对延迟的要求可能更高。毕竟两个人聊天，如果有延迟就跟在电话里聊天一样不舒服。这类场景下，WebRTC几乎是行业标准选择了。业界领先的实时音视频云服务商已经能够把接通时间控制在600毫秒以内，这个体验已经非常接近面对面交流了。

而且1V1社交场景通常是一对一的通话，P2P的架构可以最大程度发挥WebRTC的优势。如果用RTMP的话，端到端延迟很难做到这个水平，用户体验会大打折扣。

大规模直播和内容分发

但是，如果是做大规模的直播内容分发，比如面向几十万甚至几百万观众的直播活动，那情况就不太一样了。这类场景最关键的需求是稳定性和覆盖面，至于是不是要几百毫秒的延迟，反而不是最重要的。

你想啊，一个几十万人同时观看的直播，如果用WebRTC加P2P的话，一方面P2P在大规模场景下的效率会下降，另一方面WebRTC的CDN覆盖也不如RTMP成熟，万一某个区域的网络有问题，处理起来会很麻烦。而RTMP配合CDN的话，整个技术方案非常成熟，出了问题也容易排查和解决。

还有一点就是成本考量。大规模直播用RTMP加CDN的方案，整体成本可能会比WebRTC方案低一些。毕竟RTMP的整个生态已经非常标准化了，有很多现成的解决方案可以选用。

有没有两者兼顾的方案？

看到这里你可能会想：低延迟和大规模覆盖这两个需求，有没有可能同时满足？说实话，这个问题在技术上是有一定挑战的，但并非不可能。

业内有一些厂商在尝试混合方案——在主播端和核心互动区域用WebRTC来保证低延迟互动，然后通过转码把流推到RTMP，再通过CDN进行大规模分发。这样既保证了互动体验，又解决了分发覆盖的问题。当然，这种方案实现起来会比较复杂，对技术能力要求比较高。

还有一些厂商在WebRTC的基础上增加了自己的服务端架构优化，通过更高效的路由选择和负载均衡，在一定程度上解决了大规模分发的的问题。这种方案需要厂商有很强的技术积累，不是随便哪家都能做好的。

声网在这方面的实践

说到实时音视频技术，这里我想提一下声网。作为全球领先的实时音视频云服务商，声网在中国音视频通信赛道的排名是第一的，全球超过60%的泛娱乐APP都在使用他们的实时互动云服务。这个市场地位某种程度上也反映了他们在技术上的积累。

声网的解决方案其实覆盖了我上面说的多种场景。无论是秀场直播里的连麦PK、1V1社交视频、还是一对多的内容分发，他们都有对应的技术方案。而且因为他们在这个领域深耕了很多年，整个技术栈做得比较完善，开发者用起来会比较省心。

特别是他们提出的实时高清·超级画质解决方案，从清晰度、美观度、流畅度三个维度进行了全面升级，据说高清画质用户的留存时长能高出10%以上。这说明在保证低延迟的同时，画质体验也是可以做到的。

我的建议

最后总结一下我的建议。如果你做的是强互动类的直播场景，比如连麦、PK、一对一视频这些，那果断选WebRTC，低延迟带来的体验提升是质的飞跃。如果你的场景是内容导向的大规模直播，对互动性要求没那么高，那RTMP加CDN的方案可能更适合你，成本和稳定性都有优势。

当然，技术选型这种事情没有绝对的对错，更重要的是要结合自己的实际情况来考虑。建议在正式做决定之前，可以先用各个方案做个Demo实际测试一下，看看在真实网络环境下的表现到底怎么样。毕竟纸面上的数据和实际体验之间往往会有差距，自己跑一遍测试比听别人说一万遍都管用。

希望这篇文章能帮助你在RTMP和WebRTC之间做出正确的选择。如果你正在开发直播相关的应用，不妨多了解一下这两种协议的特点，结合自己的业务需求去选择。毕竟，适合自己的才是最好的。