介绍
TMP 和 RTP/RTCP 是两套完全独立、技术体系互不兼容的流媒体协议，没有包含与被包含的关系，也不能互通。
它们只是在功能目标上相似 ------ 都能传输实时音视频，但底层的设计思路、协议栈、封装格式、控制逻辑完全是两条技术路线。
很多人会说「RTSP + RTP/RTCP ≈ RTMP 」，这个说法只在功能层面近似 ------ 两者都能实现 "播放控制 + 音视频传输" 的完整流媒体能力。
但在技术实现上，它们是完全平行的两套方案：
- 方案 A：RTSP（控制） + RTP（传数据） + RTCP（传反馈）
- 方案 B：RTMP（一个协议全包）
两者没有任何包含、复用关系，是同类竞品，不是上下级关系。
RTP/RTCP ：属于传输层协议，只解决「数据包怎么打包、传输质量怎么反馈」这一件事。它本身没有建连、播放控制、会话管理能力，必须搭配 RTSP、SIP 这类上层控制协议才能完整工作。
RTMP ：属于完整的应用层流媒体协议，从握手建连、鉴权、会话控制（播放 / 暂停 / 推流）到音视频数据传输，全套能力都在协议内部闭环完成，不需要依赖任何外部传输控制协议。
区别
RTMP 主打「公网直播的一体化便捷性」，而 RTP/RTCP 主打「极致实时性 + 场景灵活性」，很多 RTMP 做不好、甚至做不了的场景，必须靠 RTP/RTCP 来实现。两者是互补关系，不是替代关系。
1. 极致低延迟场景：RTMP 的 TCP 底层天生做不到
这是最核心的原因，也是两类协议的本质分界。
- RTMP 基于 TCP 传输，TCP 的可靠重传、拥塞控制机制会天然累积延迟，端到端通常在 1~3 秒，这是协议底层的特性，再优化也很难稳定降到 500ms 以内。
- RTP 默认运行在 UDP 之上，不做强制重传，丢包就丢包（仅通过 RTCP 反馈给发送端调整码率），端到端延迟可以轻松做到 100ms 以内，局域网甚至只有几十毫秒。
典型场景：安防监控摄像头、实时视频会议、工业视觉、云游戏。这些场景对延迟的要求远高于 "绝对不丢帧"------ 宁可画面轻微花屏，也不能慢半拍，RTMP 根本满足不了这种级别的实时性。
2. 协议分层灵活，可适配不同上层控制、不同底层网络
- RTP/RTCP 是纯传输层协议 ，只负责两件事：把音视频数据包发出去、把传输质量反馈回来。上层可以自由搭配不同的控制协议，适配不同行业：
- 配 RTSP → 安防监控、IPC 摄像头
- 配 SIP → 视频会议、VoIP 电话
- 配 WebRTC/SDP → 网页实时通话底层也可以自由选择：UDP 追求低延迟，TCP 追求可靠传输。
- RTMP 是封闭的 "全家桶" 协议：控制逻辑、传输方式、封装格式全部绑定死，只能用 TCP、只能用自己的信令体系，没法灵活拆分，也没法适配其他行业的控制标准。
比如嵌入式设备里，局域网用 UDP 追求低延迟，公网用 TCP 追求可靠，RTP 两种都能支持；RTMP 只能走 TCP，没得选。
3. 弱网 / 不稳定网络下：TCP 队头阻塞反而体验更差
- RTMP 走 TCP，只要有一个包丢失，后面所有数据都会被卡住，必须等这个包重传成功才能继续，表现为画面长时间卡住不动，恢复后突然快进，卡顿是连续的。
- RTP 走 UDP，丢包不会阻塞后续数据，表现为局部花屏 / 马赛克，下一帧就恢复，卡顿是瞬时的，整体实时性不受影响。
对于实时交互场景，瞬时的画质下降，远比长时间的画面卡顿可接受得多。
4. 行业标准与生态壁垒：很多领域只认 RTP 体系
不是技术上能不能替代，而是各个行业的生态和标准已经定型，RTMP 根本进不去：
- 安防行业：ONVIF 国际标准强制要求 RTSP + RTP/RTCP，所有摄像头、NVR、录像机都支持，这是事实标准，没有厂商会用 RTMP 做设备端输出。
- 视频会议 / VoIP：国际标准 SIP/H.323 体系，媒体流全部基于 RTP。
- WebRTC：网页实时通信，媒体传输层的标准就是 RTP + RTCP。
RTMP 的生态基本只集中在互联网直播推流、CDN 分发这一个领域；出了直播圈，绝大多数实时音视频领域都是 RTP 的天下。