【音视频】 RTP 与 RTMP 协议异同对比
RTP (Real-time Transport Protocol) 和 RTMP (Real Time Messaging Protocol) 是流媒体领域两个核心协议，它们设计初衷不同，因此在特性和应用场景上有着鲜明的对比。为了让你快速把握全貌，下面这个表格清晰地汇总了它们的核心差异。
| 对比维度 | RTP (实时传输协议) | RTMP (实时消息协议) |
|---|---|---|
| 协议层次与基础 | 通常位于传输层与应用层之间，核心基于UDP | 典型的应用层协议，基于TCP |
| 核心设计目标 | 极致实时性，容忍丢包以换取低延迟 | 可靠传输与流控制，保证数据完整有序 |
| 延迟特性 | 极低（毫秒级至秒级），适用于交互式应用 | 较低（秒级，通常2-5秒），但在网络不佳时延迟会累积 |
| 可靠性机制 | 不保证可靠传输，依赖上层协议或应用处理丢包 | 保证可靠传输，通过TCP机制实现数据重传 |
| 典型应用场景 | 视频会议（Zoom, WebRTC）、IP电话（VoIP）、视频监控 | 直播推流（OBS推流）、互动直播、Flash视频点播 |
| 协议生态 | 常与RTCP（质量控制）和信令协议（如SIP）协同工作 | 协议本身集成音视频传输、控制信令和数据传输 |
| 现状与发展 | 在交互式实时通信（如WebRTC）中地位核心，前景广阔 | 作为推流协议仍广泛使用，但播放端正被HLS、HTTP-FLV等替代 |
🔍 工作机制与核心差异
上述表格中的差异，根源于两者完全不同的设计哲学和技术实现。
1. 传输层基础：UDP vs TCP
这是所有差异的根源。
- RTP over UDP：RTP 通常运行在 UDP 之上。UDP 是无连接的，不保证数据包一定到达或按序到达。这听起来是个缺点，但对于实时音视频却是关键优势。因为音视频数据是持续不断的流，偶尔丢失一个数据包（表现为画面瞬间花屏或音频轻微卡顿）通常比等待重传导致整个播放停滞或延迟大增更能让人接受。RTP 在 UDP 的基础上增加了序列号和时间戳，使接收端能够检测丢包和乱序，并实现平滑播放和音画同步。
- RTMP over TCP：RTMP 基于 TCP。TCP 要求建立连接，并保证数据可靠、有序地传输。这意味着一旦有数据包丢失，TCP 会强制重传，直到该包成功到达。在网络波动时，这种重传机制会导致延迟不断累积，可能使直播流产生数秒甚至更长的延迟。虽然牺牲了部分实时性，但换来了数据的完整性，适用于对数据完整性要求高的场景。
2. 协议架构与功能
- RTP：专注传输，需伙伴配合：RTP 本身功能非常纯粹，就是传输带有时序信息的媒体流。它通常需要一个“姐妹”协议 RTCP 来监控传输质量（如丢包率、抖动），并将这些信息反馈给发送端，以便动态调整编码策略。此外，建立和管理 RTP 会话需要依赖外部的信令协议，如 SIP 或 WebRTC 的信令通道。
- RTMP：自成一体，功能全面：RTMP 是一个“全栈”协议。它在一个连接上通过不同的“块”来复用音视频数据、控制命令（如播放、暂停）和元数据。协议本身定义了完整的交互流程，从握手、建立连接到控制播放，无需其他协议辅助。
3. 错误恢复与头部开销
- 错误恢复：由于基于 TCP，RTMP 在网络层自动进行错误恢复（重传）。而 RTP 自身不处理丢包，但上层应用或配套协议（如 WebRTC）可以实现更智能的恢复策略，比如前向纠错或重传关键帧，在实时性和完整性间取得平衡。
- 头部开销：RTP 包头相对较小且固定（12字节基础头），更高效。RTMP 的块头结构在不同大小的数据包上可能会产生相对可变的开销。
🎯 如何选择：遵循应用场景的需求
选择哪种协议，完全取决于你的应用场景最优先考虑什么。
选择 RTP 的场景
当你的应用将低延迟和实时交互置于首位时，应优先考虑 RTP。
- 视频会议与在线教育：需要保证双方对话的实时性，延迟必须控制在毫秒级，避免对话不同步。
- IP电话：音频对延迟极其敏感，少量丢包可以接受，但高延迟会严重影响通话体验。
- 视频监控与物联网：需要低延迟地查看实时画面，并能容忍偶尔的图像瑕疵。
典型技术栈：WebRTC，其媒体传输核心正是基于 SRTP（安全的 RTP），是目前构建 Web 端实时音视频应用的事实标准。
选择 RTMP 的场景
当你的应用侧重于可靠的、高质量的流媒体分发，且对秒级的延迟不敏感时，RTMP 仍是重要选项。
- 直播推流：主播使用 OBS 等软件将视频流推送到媒体服务器，RTMP 因其稳定性和广泛支持度，至今仍是推流协议的首选。
- 低延迟互动直播：虽然延迟高于 WebRTC，但相比 HLS（延迟可达10-30秒），RTMP 的2-5秒延迟在需要一定互动的直播场景中仍有优势。
典型工作流：主播端 OBS --(RTMP推流)–> 云服务器 --(转协议为 HLS/HTTP-FLV)–> 观众端播放。这是一种“RTMP进，其他协议出”的混合架构，兼顾了推流的稳定性和终端播放的兼容性。
💎 总结与趋势
总结来说，RTP 和 RTMP 代表了流媒体传输的两种不同权衡。
- RTP 代表了 “实时优先” 的思路，为交互式通信而生。
- RTMP 代表了 “可靠优先” 的思路，为高质量流媒体分发而生。
未来趋势是 WebRTC（基于RTP）的崛起。随着实时交互需求爆炸式增长，WebRTC 因其原生支持浏览器、极强的实时性和端到端加密能力，正在不断侵蚀原本属于 RTMP 的领域，如直播和在线教育。然而，RTMP 在推流端的成熟生态和稳定性使其在相当长的时间内仍将扮演重要角色。理解它们的本质差异，将帮助你在纷繁的技术选型中做出最合适的决策。