直播推流这类问题，表面看是在问协议，实际是在问直播系统的取舍。方案设计之前，我们先不要进到具体的问题比如RTMP 推流、WebRTC 推流、RTC 连麦到底选哪个？而是先拆清楚场景，避免把“能播”“低延迟”“能连麦”“能大规模分发”混成一个问题。
这里说的拆场景，比如直播是单向观看，还是强互动；观众规模、端类型、延迟目标、是否要连麦、是否要接 CDN、是否要录制回放。协议只是技术实现，业务场景才是选型起点。

RTMP、WebRTC 和 RTC 连麦分别解决什么问题

RTMP、WebRTC 和 RTC 连麦不是同一种能力的三个名字。RTMP 更常用于成熟直播推流和 CDN 分发。它的优势是生态成熟，推流工具、转码、录制、CDN 分发链路都比较清晰，适合单向观看、活动直播、带货直播、课程直播这类场景。WebRTC 更适合低延迟互动。浏览器原生支持是它的重要优势，适合网页实时音视频、低延迟观看、互动课堂、视频通话、会议和一些轻量实时互动场景。RTC 连麦解决的是实时互动，不只是推流。主播和嘉宾、主播和观众、老师和学生之间要实时对话、同屏、打断、抢答、PK，这类场景更接近 RTC 房间和媒体转发问题。
可以简单这样区分：

所以，推流方案不是“谁更快”这么简单，而是看你要优先解决稳定分发、低延迟互动，还是多人实时沟通。

不同直播场景下，怎么选择合适的推流协议

推流协议的选择，不能只看“延迟低不低”，还要看直播类型、互动强度、观看规模、端侧环境和后续媒体处理链路。
如果是活动直播、品牌发布会、课程直播这类单向观看场景，观众主要是看，互动通常通过评论、弹幕或表单完成。此时更重要的是稳定播放、清晰度、CDN 分发、录制回放和成本控制，RTMP 推流加 CDN 分发通常是更成熟的选择。
如果是电商带货、互动导购、教育答疑、专家讲座这类半互动场景，推流链路就要看互动强度。普通商品讲解或课程讲授可以继续优先考虑 RTMP / CDN；但如果主播需要即时回应评论、连麦咨询、抽奖抢答、倒计时抢购或和 IM 聊天室强同步，就要考虑低延迟直播、WebRTC 或 RTC 连麦能力。
如果是视频会议、在线问诊、远程协作、多人连麦、语聊房这类强互动场景，重点就不再是“把一路直播流推给很多人”，而是让多人实时发布、订阅、打断和交流。此时 WebRTC 或 RTC SDK 更适合承载实时音视频互动，RTMP 更适合作为旁路推流或录制分发链路。
如果是大规模公开直播，比如赛事、晚会、公开课或大型活动，通常要优先考虑 CDN 分发能力。低延迟可以优化体验，但高并发、稳定性、转码、录制、回源和容灾往往更关键。需要互动时，可以把主播、嘉宾和少量互动用户放在 RTC 链路里，把普通观众放在 CDN 或低延迟直播链路里。
可以按下面这张表先做初步判断：

低延迟不是单纯为了“更快”，而是为了让互动动作和音视频内容处在同一个节奏里。只要场景里出现实时问答、连麦、抢答、倒计时、协作或多人讨论，协议选择就要从“能不能推流”升级为“能不能实时互动”。

推流、播放、连麦和 IM 要分开设计

一个可运营的直播间通常至少包括四条链路：

RTMP 可以解决一部分推流播放问题，但它不负责聊天室、商品互动、用户权限和连麦逻辑。WebRTC 可以解决低延迟音视频问题，但也不等于完整直播间。RTC 连麦可以解决互动，但大规模观看通常还要配合 CDN 或低延迟直播链路。这也是为什么很多实时互动服务商会把 RTC、超低延迟直播、CDN、IM 和录制能力组合在一起。
以即构这类第三方服务商为例，实时音视频能力覆盖音视频通话、音视频直播、直播连麦、用户权限控制、通话质量监测、网络测速、音视频录制等模块；ZIM 即时通讯则覆盖会话、房间、群组、消息、历史消息、系统通知和呼叫邀请等能力。对开发团队来说，这种组合的价值在于把“推流”“连麦”“消息”和“回放”拆开评估，再按业务阶段接入。

WebRTC 推流适合哪些场景

WebRTC 的优势是低延迟和浏览器能力。如果直播业务重点在 Web 端、实时课堂、网页会议、在线咨询、远程协作或小规模互动，WebRTC 往往更容易满足交互体感。用户打开浏览器就能进行实时音视频，不一定需要安装额外客户端。但 WebRTC 也不是“低延迟直播”的万能答案。你需要额外关注：

• 浏览器兼容和移动端 WebView 表现
• 服务端转发、混流、录制和旁路直播能力
• 弱网下的码率、分辨率和丢包策略
• 多人连麦时的上行和下行压力
• 是否要和 CDN 直播链路互通
• 运维团队是否能排查音视频质量问题

如果团队只是要把主播画面稳定推到 CDN，再让大量观众观看，WebRTC 未必是成本和运维上最轻的方案。如果团队要做低延迟互动、网页实时音视频或连麦，WebRTC 或 RTC SDK 才更值得优先评估。

RTMP 推流适合哪些场景

RTMP 的优势是成熟。很多推流工具、直播平台、CDN、录制和转码链路都对 RTMP 友好。对于单向直播、课程直播、活动直播、基础带货直播来说，RTMP 仍然很常见。RTMP 更适合这些场景：

• 主播端推流到固定直播地址
• 观众主要是单向观看
• 直播间互动以评论和商品点击为主
• 延迟目标不是最核心指标
• 需要接成熟 CDN 分发、录制和转码链路

团队希望用已有推流工具快速验证它的限制也很明确：当你需要强互动、实时连麦、多人同屏、低延迟问答时，RTMP 通常要和 RTC 或低延迟直播能力组合使用。

H.265 推流要单独评估

H.265 的优势是压缩效率更高，在同等画质下有机会降低码率。但它不是只在推流端打开一个开关。选 H.265 前，至少要确认：

• 推流端是否支持稳定编码
• 播放端是否支持解码
• 浏览器和小程序是否兼容
• CDN、转码、录制链路是否支持
• 低端机解码发热和耗电是否可接受
• 是否需要为不兼容终端准备 H.264 兜底

如果目标端复杂，H.265 不应该作为默认假设。更稳的做法是先按核心端测试，再决定是否分端启用。

推流方案选型要看哪些字段

选直播推流方案时，建议不要只问“支不支持 RTMP / WebRTC”。至少要准备一张选型表。

小结

RTMP、WebRTC 和 RTC 连麦不是互相替代的三个选项，而是对应不同直播需求的技术链路。RTMP 更适合成熟推流和 CDN 分发，WebRTC 更适合低延迟互动，RTC 连麦更适合多人实时沟通。
电商直播、教育直播、活动直播和互动导购对延迟、互动、成本和规模的要求不同，不能用同一套协议假设覆盖所有场景。
技术团队在选型时，建议先按“单向观看、低延迟互动、实时连麦、大规模分发”拆清楚直播类型，再决定 RTMP、WebRTC、RTC SDK、低延迟直播和 CDN 怎么组合。如果正在评估直播推流或低延迟互动直播，可以先查看直播 SDK 产品介绍，再结合端类型、延迟目标、连麦需求和 CDN 分发要求确认接入路径。

常见问题

1. RTMP 推流适合什么场景？适合成熟直播分发、单向观看和 CDN 链路较明确的场景。
2. WebRTC 推流适合什么场景？适合低延迟互动、浏览器实时音视频和对实时性要求更高的场景。
3. RTC 连麦和直播推流一样吗？不一样，RTC 连麦解决实时互动，直播推流主要解决内容分发。
4. 电商直播一定要 WebRTC 吗？不一定，是否需要取决于互动强度和延迟要求。
5. H.265 推流要注意什么？需要确认端侧编码、播放器、浏览器和分发链路是否支持。
6. 直播推流工具和 SDK 有什么区别？工具偏一次性操作，SDK 用于把直播能力集成进自有产品。
7. 低延迟直播成本会更高吗？可能会，具体取决于协议、并发、媒体处理和服务质量要求。
8. 选推流方案前要准备什么？要明确端类型、协议、延迟目标、并发、是否连麦、是否录制和是否接 CDN。