WebRTC推流能否替代RTMP？低延迟直播方案深度解析

我做了几年直播相关的东西，从最早的RTMP分发到后来的SRT、WebRTC低延迟方案，算是把直播这条链路从头到尾摸了一遍。最近总有人问我同一个问题：WebRTC推流到底行不行，能不能把RTMP那一套给替换掉？今天就借这个机会，把WebRTC推流这件事掰开揉碎聊一聊，包括它的原理、落地姿势、服务器选型、弱网表现，以及在哪些场景下它确实能成为“主要方案”，哪些场景下还撑不起台面。

先说结论：WebRTC推流在低延迟互动直播里已经是事实上的最优解之一，但在泛娱乐大流量直播里，它还不能全面替代RTMP/CDN组合。这个结论背后的逻辑，值得每一个做直播的人搞清楚。

1. 为什么现在大家都盯着WebRTC推流

1.1 从RTMP的痛点说起

传统直播链路里，推流端最常见的就是RTMP。RTMP当年能火，靠的是Adobe的Flash生态，一统PC端浏览器。后来Flash淘汰了，RTMP却靠着直播平台的存量体系活了下来，直到今天还有很多云厂商的推流地址是rtmp://开头的。但RTMP的问题一直很要命：基于TCP长连接，遇到丢包就头大，延迟普遍在3到10秒，弱网下还会越推越卡，甚至直接断流。

我做直播技术选型时，最头疼的就是RTMP的延迟问题。观众发一条弹幕，主播几秒后才看到，互动体验极差。后来有了HLS，延迟更高，动不动十几秒，但胜在兼容性好、分发成本低，于是被短视频平台拿去做了点播和延时直播。可对于连麦、带货、在线教育、云游戏这类强互动场景，RTMP和HLS都顶不住。

这个时候WebRTC出现了。它最初是Google推给浏览器用的实时通信方案，主打P2P音视频传输，用在视频会议里。后来有人发现它的传输层设计（UDP + 拥塞控制 + 抖动缓冲）天然适合低延迟直播，于是WebRTC推流开始被逐步搬进直播系统。

1.2 WebRTC推流和拉流到底是个啥

很多新手容易把 WebRTC推流 和 拉流 搞混。推流指的是把采集端（比如主播的摄像头、麦克风、屏幕）的音视频数据编码后发送到服务器；拉流指的是播放端从服务器拉取音视频数据并解码播放。WebRTC推流就是主播端用WebRTC协议把流推到服务器，WebRTC拉流就是观众端用WebRTC协议从服务器拉流观看。

更具体一点，WebRTC推流通常走的是WHIP协议（WebRTC-HTTP Ingestion Protocol），这个协议被很多云厂商用作标准接入方式；WebRTC拉流则是WHEP协议（WebRTC-HTTP Egress Protocol）。这两个协议把传统推拉流的握手、鉴权、SDP交换都封装成HTTP请求，实现起来比纯WebRTC信令要简单很多。

这个架构里，WebRTC不管推流还是拉流，都是基于UDP的SRTP加密传输，加上NACK重传、FEC前向纠错、动态码率调节这些机制，弱网表现确实比RTMP好不少。这一点后面我单独讲。

2. WebRTC推流能否成为主要方案，先看这几个硬指标

2.1 延迟：WebRTC的碾压优势

你说直播主要方案，核心KPI肯定是延迟。传统RTMP延迟多少？我实测过，在不做任何优化的情况下，从主播推流到观众看到画面，大概3到8秒，如果加上转码、分发链路，10秒也是常事。HLS就更夸张，切片间隔默认6秒，再加上播放缓冲，端到端延迟通常在10到30秒。

WebRTC呢？在局域网或者优质公网下，端到端延迟能做到500毫秒以内。即使跨省跨运营商，经过正规的媒体服务器分发，一般也能控制在1秒左右。这个差距是革命性的，因为它决定了互动方式：3秒延迟只能单向看，1秒以内才能双向聊。

我记得之前做过一个在线钢琴教学的直播系统，用RTMP时老师和学生完全没法同步弹奏，老师说“看这个键”，学生3秒后才看到，根本没法教。后来切到WebRTC推拉流，延迟降到800毫秒左右，教学体验直接上了一层楼。这个场景下，WebRTC推流不只是“能成为主要方案”，而是“必须成为主要方案”。

2.2 弱网表现：UDP + 自适应码率是关键

再一个硬指标就是弱网卡顿。RTMP基于TCP，TCP为了保证可靠性，一旦丢包就重传，重传导致延迟增加、吞吐下降，网络抖动时就会严重卡顿，甚至断流。WebRTC底层用UDP，但自带了拥塞控制和丢包恢复机制。

具体来说，WebRTC里有三个东西在弱网时起作用：

• NACK（Negative Acknowledgement）：接收端发现自己没收到某个包，会立刻请求发送端重传，只针对丢的包，而且有时间窗限制。
• FEC（Forward Error Correction）：发送端额外发一些冗余包，接收端即使丢了一部分包也能通过冗余信息恢复出原始数据。
• 码率自适应（Ada