【流媒体协议】RTSP / RTP / RTCP 协议全景介绍

发布时间：1996 年
标准文档：RFC 1889 → 后被 RFC 3550（2003）取代
推动背景 ：
- 1990 年代初，互联网开始支持音频会议（如 VAT）、视频会议（如 nv）等应用；
- 这些应用各自使用私有传输机制，缺乏互操作性；
- IETF 成立 AVT（Audio-Video Transport）工作组，目标是定义一个通用、轻量、可扩展的实时数据传输框架。
核心思想 ：RTP 不保证可靠传输（不重传、不纠错），而是专注于时间戳、序列号、负载类型标识，将 QoS 控制交给上层或配套协议（即 RTCP）。

2.2 RTSP：流媒体的"遥控器"（1998年）

发布时间：1998 年
标准文档：RFC 2326
推动背景 ：
- 随着流媒体点播（VOD）和直播需求兴起，需要一种类似 HTTP 的控制协议，但支持"播放/暂停/快进"等 VCR 式操作；
- RTP 虽能传数据，但无法动态控制会话状态；
- RealNetworks、Netscape、Columbia University 等联合提出 RTSP，填补"控制平面"空白。
设计哲学 ：RTSP 是无状态的文本协议 （类似 HTTP），运行在 TCP 上，负责建立、操控、终止媒体会话 ，但不传输媒体本身。

三、协议详解

3.1 RTP（Real-time Transport Protocol）

核心功能

为实时音视频数据提供端到端传输；
支持时间同步、负载识别、序列排序。

报文结构（关键字段）

字段	长度	说明
Version (V)	2 bit	固定为 2
Marker (M)	1 bit	标记帧边界（如 H.264 中一帧结束）
Payload Type (PT)	7 bit	编码类型（如 96=H.264, 111=OPUS）
Sequence Number	16 bit	检测丢包与乱序
Timestamp	32 bit	采样时钟（视频通常 90kHz）
SSRC	32 bit	同步源标识（唯一标识一路流）

特点

通常基于 UDP（低延迟优先）；
不提供可靠性、加密或带宽控制；
依赖应用层或 RTCP 补充这些能力。

3.2 RTCP（RTP Control Protocol）

核心功能

监控传输质量（丢包率、抖动）；
提供参与者信息（CNAME）；
实现多流同步（如音视频对齐）。

常见报文类型

类型	作用
SR（Sender Report）	发送端报告已发包数、时间戳等
RR（Receiver Report）	接收端反馈丢包、抖动等 QoS 指标
SDES（Source Description）	携带 CNAME（跨会话唯一标识）
BYE	通知某源退出会话

工作机制

RTCP 带宽通常限制为 RTP 总带宽的 5%；
报告间隔随会话人数动态调整（避免广播风暴）；
接收方可根据 RR 包中的 Fraction Lost 判断网络状况。

3.3 RTSP（Real Time Streaming Protocol）

核心功能

控制媒体流的生命周期；
协商传输参数（如 RTP 端口、编码格式）。

关键方法（Method）

方法	作用
`DESCRIBE`	获取媒体描述（SDP）
`SETUP`	建立传输通道（指定 RTP/RTCP 端口）
`PLAY`	启动流传输
`PAUSE`	暂停（保持会话）
`TEARDOWN`	终止会话
`OPTIONS`	查询服务器支持的方法（常用于保活）

传输模式

UDP 模式（默认） ：
- RTP/RTCP 走独立 UDP 端口；
- 低延迟，但可能被防火墙拦截。
Interleaved 模式（TCP 封装） ：
- RTP/RTCP 包封装在 RTSP TCP 连接中（以 $ 开头）；
- 兼容性好，但延迟较高。

四、三大协议的关系与分工

维度	RTSP	RTP	RTCP
角色	控制平面（Control Plane）	数据平面（Data Plane）	反馈平面（Feedback Plane）
是否传媒体	❌	✅	❌
传输层	TCP（主流）	UDP（主流）	UDP（与 RTP 配对）
交互方向	客户端 ↔ 服务器	服务器 → 客户端（单播）或组播	双向（周期性）
依赖关系	依赖 RTP/RTCP 传输媒体	可独立使用（如 WebRTC）	必须与 RTP 配对使用

协作流程图：

bash 复制代码

[Client] --(RTSP DESCRIBE)--> [IPC]
[IPC] --(返回 SDP)--> [Client]
[Client] --(RTSP SETUP: client_port=8000-8001)--> [IPC]
[IPC] --(开始向 8000 发 RTP, 8001 发 RTCP)--> [Client]
[Client] --(RTSP PLAY)--> [IPC]
[Client] <--(RTP Video Frames)--- [IPC]
[Client] <-->(RTCP Reports) <--> [IPC]

五、在 IPC 领域的典型应用场景

5.1 实时视频预览

用户通过 NVR 或手机 App 请求 IPC 的主码流；
平台使用 RTSP 建立会话，接收 RTP 视频流；
RTCP 用于监测网络质量，触发"降分辨率"等自适应策略。

5.2 录像回放（部分厂商支持）

通过 RTSP 的 Range 头请求指定时间段；
IPC 从存储中读取录像，按 RTP 流式发送。

5.3 双向语音对讲

音频也通过 RTP 传输（通常 G.711/AAC）；
RTCP 确保音视频同步（通过 timestamp 对齐）。

5.4 跨网段/公网访问

使用 RTSP over TCP（Interleaved） 穿透企业防火墙；
配合 P2P 或云转发服务实现远程查看。

六、与其他技术的对比与演进

技术	与 RTP/RTSP 关系	适用场景
HTTP-FLV / HLS	替代方案，基于 HTTP 分块传输	Web 浏览器兼容性好，但延迟高（>3s）
WebRTC	内部仍使用 RTP/RTCP，但信令用 WebSocket/SIP	超低延迟（<500ms），适合浏览器点对点通信
ONVIF	基于 SOAP 的设备管理协议，可配合 RTSP 使用	多厂商设备统一接入（如发现 IPC、获取 RTSP URL）

趋势：RTSP/RTP 在局域网、专业安防领域仍是主流；WebRTC 在消费级应用中快速普及；HLS/FLV 主导 Web 直播。

七、总结

RTP/RTCP（1996） 解决了"如何高效传实时数据"的问题；
RTSP（1998） 解决了"如何灵活控制媒体会话"的问题；
三者共同构成了传统 IPC 视频流传输的事实标准；
虽然新兴技术（如 WebRTC）正在崛起，但在稳定性、兼容性、硬件支持度上，RTSP+RTP 仍是工业级 IPC 的首选方案。