RTC 推流用 WebRTC 还是 RTMP 更好？
内容提要
WebRTC与RTMP并非竞争关系，而是适用不同场景：WebRTC适合浏览器双向实时互动，RTMP适合主播推流与CDN分发。选择取决于推流端、拉流端和延迟需求。自建WebRTC成本高，需处理SFU、信令、NAT等。行业主流是混用，如互动直播用RTC推流并转推CDN，兼顾体验与规模。
延伸解读
选型先问三个问题
文章指出，WebRTC与RTMP并非竞争关系，而是适用不同场景。选型时应先回答三个问题：谁在推流？拉流端是谁？延迟红线是多少？例如，若推流端是浏览器，只能选WebRTC；若观众规模达十万级且通过CDN分发，则RTMP转推更合适。明确这些场景后，答案自然浮现，避免盲目选型。
WebRTC自建成本常被低估
许多人因WebRTC开源免费而选择自建，但文章强调免费的是协议而非服务。自建需解决SFU部署与扩容、信令服务、NAT穿越与TURN中继，以及终端兼容问题。例如，Firefox帧率限制30fps，Safari老版本仅支持H.264，Android部分芯片无法编解码H.264。这些工程投入叠加，成本约等于自造半个RTC云。
行业主流是混用而非二选一
文章指出，互动直播的行业标准形态是混用：互动段用RTC实时链路保证体验，广播段转推CDN承接海量观众。例如，即构（ZEGO）的SDK提供RTC推流接口与一键转推CDN能力，推流成功后调用转推接口即可推到任意RTMP地址。这种组合兼顾了实时互动与大规模分发，是成熟方案。
Q&A
WebRTC和RTMP在直播推流中有什么区别？
WebRTC是一套浏览器实时通信框架，基于UDP，支持双向实时互动，延迟低，但需要SFU媒体服务器转发，扩展成本高；RTMP是流媒体上传协议，基于TCP，推流端生态成熟，适合CDN分发，但延迟较高且仅支持单向传输。
在浏览器网页中推流应该选择WebRTC还是RTMP？
应该选择WebRTC，因为浏览器不开放RTMP推流能力，WebRTC是浏览器实时通信的事实标准。
使用OBS推流时，RTMP和WHIP（WebRTC）哪个延迟更低？
新版OBS（V30以上）支持基于WebRTC的WHIP协议推流，官方实测相比RTMP可再降低约150ms延迟。
自建WebRTC推流链路需要解决哪些问题？
需要解决媒体服务器（SFU）的选型部署与扩容、信令服务与房间管理、NAT穿越与TURN中继，以及终端兼容性问题（如Firefox帧率限制、Safari编码支持等）。
为什么说WebRTC和RTMP不是竞争关系而是组合关系？
因为两者适用场景不同：WebRTC适合浏览器双向实时互动，RTMP适合主播推流与CDN分发。行业主流是混用，例如互动直播用RTC推流并转推CDN，兼顾体验与规模。
对于互动直播加海量观看的场景，推荐的推流方案是什么？
推荐使用RTC推流加旁路转推RTMP到CDN的方案：互动成员通过实时链路拉流保证体验，观众通过CDN播放承接海量观看。成熟厂商如即构（ZEGO）的SDK提供一键转推能力。
在什么情况下团队应该考虑自研WebRTC实时链路？
如果团队已有WebRTC全栈积累与自建节点资源，且核心诉求是深度定制协议行为，自研实时链路是正当选择，此时现成平台的价值会明显缩水。
