2. RTSP协议基础
RTSP（Real-Time Streaming Protocol，实时流传输协议）是推流与拉流链路中的“控制面”协议。它本身不搬运音视频数据，而是负责建立会话、协商传输方式、控制播放状态。真正承载音视频码流的是 RTP，负责传输质量反馈的是 RTCP，而描述媒体信息（编码格式、分辨率、时钟频率等）的是 SDP。理解这四者的分工，是后续做推流调优的前提。
一、RTSP在协议栈中的定位与协作关系
RTSP 常被类比为“流媒体的 HTTP”，但二者有本质区别：HTTP 是无状态、请求-响应后即结束；RTSP 是有状态的会话协议，一次 SETUP 之后会维持会话上下文，PLAY 之后服务端持续推送 RTP 流，直到 PAUSE 或 TEARDOWN。RTSP 默认使用 TCP 554 端口，也可通过 TCP 承载 RTP 以穿越防火墙。
四者协作可以这样理解：客户端先用 RTSP 的 DESCRIBE 拿到 SDP，从 SDP 中得知有几路媒体、每路用什么编码、用什么传输协议；再用 SETUP 为每路媒体建立传输通道；最后用 PLAY 触发服务端通过 RTP 发送数据，同时 RTCP 周期性地回传丢包、抖动、往返时延等统计信息，用于拥塞控制和音视频同步。
二、RTSP请求响应模型与状态机
RTSP 采用客户端-服务端请求响应模型，但与传统 HTTP 不同，它允许服务端主动向客户端发送通知（如 ANNOUNCE、REDIRECT）。每个请求包含方法、URI、协议版本、头部字段和可选消息体；响应包含状态码和原因短语。常见状态码包括 200 OK、401 Unauthorized、404 Not Found、454 Session Not Found、500 Internal Server Error。
RTSP 会话有明确的状态迁移：INIT → READY → PLAYING → PAUSE → PLAYING → TEARDOWN。SETUP 使会话从 INIT 进入 READY；PLAY 进入 PLAYING；PAUSE 回到 READY；TEARDOWN 结束会话。若在 PLAYING 状态下直接发送 SETUP，多数服务端会返回 455 Method Not Valid In This State。
三、常见方法详解与典型交互流程
| 方法 | 方向 | 作用 | 关键参数/头部 |
|---|---|---|---|
| OPTIONS | 客户端 → 服务端 | 查询服务端支持的方法集合 | Public 响应头 |
| DESCRIBE | 客户端 → 服务端 | 获取媒体描述（SDP） | Accept: application/sdp |
| SETUP | 客户端 → 服务端 | 建立传输通道，分配 Session ID | Transport: RTP/AVP;unicast;client_port |
| PLAY | 客户端 → 服务端 | 启动或恢复流传输 | Session、Range |
| PAUSE | 客户端 → 服务端 | 暂停流传输，保留会话 | Session |
| TEARDOWN | 客户端 → 服务端 | 终止会话，释放资源 | Session |
一次完整的拉流交互通常如下：OPTIONS 探测能力 → DESCRIBE 获取 SDP → SETUP 建立音视频通道 → PLAY 开始播放 → 播放中 RTCP 反馈 → PAUSE 暂停 → TEARDOWN 结束。推流场景中，客户端角色由推流端承担，服务端为 RTSP 媒体服务器，ANNOUNCE 和 RECORD 方法会被使用。
OPTIONS rtsp://192.168.1.10:554/live RTSP/1.0
CSeq: 1
User-Agent: RTSPClient/1.0
RTSP/1.0 200 OK
CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN
DESCRIBE rtsp://192.168.1.10:554/live RTSP/1.0
CSeq: 2
Accept: application/sdp
RTSP/1.0 200 OK
CSeq: 2
Content-Type: application/sdp
Content-Length: 312
v=0
o=- 0 0 IN IP4 192.168.1.10
s=Live Stream
t=0 0
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:trackID=0
SETUP rtsp://192.168.1.10:554/live/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001
RTSP/1.0 200 OK
CSeq: 3
Session: 12345678
Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001
PLAY rtsp://192.168.1.10:554/live RTSP/1.0
CSeq: 4
Session: 12345678
Range: npt=0.000-
RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
Range: npt=0.000-
四、案例场景与常见误区复盘
场景一：某安防项目拉流首帧耗时超过 3 秒。排查发现客户端在 DESCRIBE 之后未复用连接，每次 SETUP 都重新建立 TCP，导致握手开销叠加。优化方式是在同一 RTSP 连接上顺序完成 OPTIONS→DESCRIBE→SETUP→PLAY，并开启 TCP 复用。
场景二：推流端 PLAY 后服务端无数据。抓包发现 SETUP 的 Transport 头中 client_port 与推流端实际监听端口不一致，RTP 包被发往错误端口。修正 Transport 参数后恢复正常。