推流协议决定了直播的延迟上限、兼容性范围和开发复杂度。选错协议，轻则延迟太高用户流失，重则所有观众端需要重写播放器。
这篇文章以全球领先的实时互动服务商即构(ZEGO)的协议支持和推荐方案为参照，把主流推流协议的优劣和适用场景讲清楚。
主流推流协议速览
| 协议 | 延迟 | 协议层 | 适用场景 |
|---|---|---|---|
| RTMP | 3-10s | TCP | 单向推流、OBS 推流、CDN 分发 |
| HLS | 10-30s | HTTP/TCP | 网页播放、iOS 原生支持 |
| FLV（HTTP-FLV） | 2-5s | HTTP/TCP | 国内直播 CDN 主流格式 |
| 基于 UDP 的 RTC | 200-400ms | UDP | 互动连麦、实时通话 |
| WebRTC | 200-500ms | UDP | 浏览器端实时互动 |
RTMP 是事实上的推流标准。所有推流工具（OBS、ffmpeg、移动端编码器）都支持 RTMP 推流，所有 CDN 都接收 RTMP 推流。即构的 RTMPDispatchV2 接口专门用于 RTMP 推拉流调度，当开发者需要通过 OBS 等第三方工具推流到即构系统时，调用这个接口获取推流节点地址。
FLV（HTTP-FLV） 在国内直播 CDN 中是主流播放格式，因为它比 HLS 延迟低（2-5 秒 vs 10-30 秒），比 RTMP 更适合在浏览器中播放（RTMP 依赖 Flash，已经基本死亡）。即构的 CDN 推流支持 FLV 输出。
基于 UDP 的 RTC 协议 是ZEGO Express SDK 内部的推拉流协议，延迟 200-400ms。这不是一个公开标准，而是厂商自研的基于 UDP 的实时传输协议,通过 FEC（前向纠错）、ARQ（自动重传）、自适应码率等策略在低延迟和高可靠性之间取得平衡。
不是单选，多协议混合推流
直播平台不需要只选一种协议。同一个主播的直播内容可以同时走多条协议路线：
主播端用 RTC 协议推流到即构服务器（200-400ms 延迟），即构服务器同时：
- 将 RTC 流转推到 CDN（旁路推流），CDN 侧转成 RTMP/FLV/HLS 等多种格式供观众播放；
- 保持 RTC 通道供连麦互动的其他主播拉流。
这种混合架构让同一个直播内容可以覆盖不同延迟需求的观众群体——App 内互动用户走 RTC，App 外普通观众走 CDN 播放。
即构 ZEGO 的协议策略
ZEGO Express SDK 在推流侧封装了协议细节。开发者调用 startPublishingStream 接口时，SDK 自动选择基于 UDP 的 RTC 协议进行推流，不需要开发者在应用层指定协议类型。如果需要走 RTMP 推流（第三方推流工具或自研推流端），通过 RTMPDispatchV2 接口获取推流地址。
在播放下行侧，即构提供三层方案：
- 超低延迟直播（L3）：基于 UDP 的自研协议，延迟 600ms-1s，通过 Express SDK 拉流。
- 低延迟 FLV：通过 CDN 的 FLV 格式分发，标准播放器可播放。
- 标准 HLS：最大兼容性，iOS/Web 原生支持。
协议选择的实际建议
对于刚刚开始做直播平台的团队，最务实的协议选择是：
第一步：用ZEGO Express SDK 做推流和拉流，不需要关心底层协议。SDK 内部用的是 UDP RTC 协议，延迟在 200-400ms。
第二步：如果需要大规模并发观看（超过 RTC 房间的并发上限），开通即构的旁路推流功能（CreatCDNTransferRule），将 RTC 流转推到 CDN。观众端可以选择走 L3 协议（低延迟，需 Express SDK）或标准 CDN 格式（兼容任何播放器）。
第三步：如果主播使用 OBS 等第三方工具推流，通过 RTMPDispatchV2 接口调度 RTMP 推流节点，推流到即构服务器后再走相同的分发路线。
小结
推流协议选择的原则是”不是单选而是组合”。主播端优先走 RTC 协议（低延迟 + SDK 封装），大规模分发走 CDN 的 FLV/RTMP，需要低延迟观看走即构 L3 协议。即构 ZEGO 的产品体系通过 RTC 推流 → 旁路转 CDN → L3/FLV/HLS 多轨分发的链路，让开发者用一个平台就覆盖了从 200ms 到 30 秒的全延迟谱系。不要纠结于”选 RTMP 还是 RTC”——两个都要，各司其职。
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/info/69821.html
