直播为什么比点播延迟高？聊聊 RTMP、WebRTC 与 SRT 三种直播协议
看直播时左下角总有"3 秒延迟"的提示；但视频通话却几乎同步。同样是"实时画面"，为什么差距这么大？这背后是三套直播传输协议在较劲：RTMP（老将）、WebRTC（实时派）、SRT（新贵）。本文拆开它们的原理，让你看懂直播延迟的来龙去脉。
TL;DR：RTMP 基于 TCP 推流，稳定但延迟 3-5 秒；WebRTC 基于 UDP 直连，延迟 < 500ms；SRT 在 UDP 上加纠错，兼顾低延迟与可靠性。直播平台选型取决于场景——一人对万人用 RTMP+HLS，一对一通话用 WebRTC，远距离专业传输用 SRT。
目录
一、直播流的完整链路
先看清一条直播流从主播到观众的完整路径：
主播端 服务端 观众端
摄像头 ─RTMP推流→ CDN/媒体服务器 ─HLS/FLV拉流→ 播放器
(上传) │ │ (分发)
切片 转码
TS 多码率
推流端负责上传（上行带宽要够），服务端负责转码分发（CPU 要强），拉流端负责播放（下行稳定就行）。延迟主要卡在"推流 + 转码 + 分发"这三个环节，不同协议优化的重点不同。
二、RTMP：直播界的老黄牛
RTMP（Real-Time Messaging Protocol）是 Adobe 2002 年推出的协议，至今仍是直播推流的事实标准。
| 特性 | RTMP |
|---|---|
| 传输层 | TCP（可靠、有序） |
| 延迟 | 3-5 秒 |
| 推流端支持 | OBS / FFmpeg / 几乎所有直播软件 |
| 播放端支持 | 需 Flash（已淘汰）或转封装为 FLV/HLS |
RTMP 基于 TCP，数据必须完整到达、按序交付。在网络抖动时，TCP 的重传机制会导致后续数据排队等待——这就是延迟的根源。但它稳定、成熟，所以至今仍被广泛用于推流端（OBS 推流到服务器）。
# ffmpeg 推 RTMP 流
ffmpeg -re -i input.mp4 -c copy -f flv rtmp://live.example.com/app/streamkey
到播放端，RTMP 已经很少直接用了。服务器收到 RTMP 推流后，通常会转成 HLS 或 HTTP-FLV 再分发给观众——这一步又增加了 3-10 秒的切片缓冲延迟。
三、WebRTC：实时通话的标配
WebRTC 走的是另一条路——UDP + P2P 直连，专为"毫秒级延迟"设计。
RTMP 链路：主播 → TCP → 服务器 → HLS切片 → CDN → 观众 (3-10秒)
WebRTC ：主播 ←── UDP P2P 直连 ──→ 观众 (<500ms)
WebRTC 的代价是：UDP 不可靠，网络差时会丢包、花屏、卡顿。但对通话场景来说，流畅 > 完美画质。更多细节见 直播连麦和视频通话是怎么"秒通"的？聊聊 WebRTC 实时通信。
四、SRT：在公网上"可靠地快"
SRT（Secure Reliable Transport）是 2017 年开源的新协议，定位是在不可靠的公网上实现低延迟 + 高可靠的视频传输。
| 特性 | RTMP | WebRTC | SRT |
|---|---|---|---|
| 传输层 | TCP | UDP | UDP + 纠错 |
| 延迟 | 3-5s | < 500ms | 1-2s |
| 抗丢包 | TCP 重传（慢） | 无保护（花屏） | ARQ + FEC 双重纠错 |
| 适用场景 | 推流到服务器 | 通话/会议 | 远程制作/跨国传输 |
SRT 的杀手锏是前向纠错（FEC）：发数据时顺带多发一些冗余包，接收端丢了几个包可以用冗余包算回来，不需要重传。再加上 AES 加密和防火墙穿透，SRT 在广播电视行业正快速取代专线和卫星。
五、三种协议怎么选
场景 推荐协议
───────────────────────────────────
OBS 推流到直播平台 RTMP（最兼容）
一对一视频通话 WebRTC（最低延迟）
跨国远程制作 / 专业传输 SRT（抗丢包）
直播带货 / 游戏直播 RTMP 推 + HLS/FLV 拉
多人会议 WebRTC + SFU 服务器
现实中的大型直播平台往往混用：RTMP 推流 → 服务器转码 → SRT 跨区域分发 → 边缘节点 HLS 输出给观众。每一段选最合适的协议，整体效果最优。
六、对"下载直播"意味着什么
直播下载比点播下载难得多：
- RTMP 流：可以 ffmpeg 拉流录制，但需要知道推流地址和密钥（通常不公开）；
- HLS 直播：和普通 m3u8 下载类似，但分片在实时生成，需要持续拉取；
- WebRTC 流：P2P 直连，无静态地址，只能端上录制；
- SRT 流：需要 SRT 客户端（如 ffmpeg 编译了 libsrt），门槛较高。
# ffmpeg 录制 RTMP 直播流
ffmpeg -i rtmp://live.example.com/app/stream -c copy output.mp4
# ffmpeg 录制 SRT 直播流
ffmpeg -i "srt://server:port?streamid=live" -c copy output.mp4
七、合规与温馨提示
技术是中性的，用法见人心。我们强烈建议：
- 仅下载你自己拥有版权或平台明确允许保存的内容；
- 尊重创作者与平台服务条款，不用于盗版传播、商业侵权；
- 下载内容请用于个人学习、备份与离线观看。
直播协议的演进方向很清晰：从 TCP 走向 UDP，从"可靠但慢"走向"又快又稳"。RTMP 会继续活在很多推流端，WebRTC 统治实时通话，SRT 则在专业传输领域加速替代专线。理解了这三兄弟，你就看懂了整个直播行业的传输骨架。
本文由 VidDown 技术博客原创发布。VidDown 是一个免费、本地优先的在线视频解析与开发者工具站，支持多平台视频下载、格式转换、m3u8 合并等实用功能，所有数据处理均在本地完成，保护你的隐私。欢迎访问 www.viddown.cn 体验。