4. RTSP协议详解
RTSP（Real Time Streaming Protocol，实时流协议）是一个应用层控制协议，用于控制流媒体服务器上的音视频数据。它本身不传输媒体数据，而是像“遥控器”一样，负责建立、播放、暂停和关闭媒体会话。理解 RTSP 的关键，在于掌握它的一组标准请求方法及其响应交互过程。本节将围绕 OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN 六个核心方法，结合真实抓包场景，讲清它们的作用、报文格式和典型响应。
一、核心原理：RTSP 是“带外控制”协议
RTSP 的交互模型类似 HTTP：客户端发送请求，服务器返回响应，默认端口为 554。但 RTSP 与 HTTP 有一个本质区别：RTSP 是有状态的。一次完整的推流或拉流会话，会经历从建立到销毁的多个状态，每个请求方法都在推动状态迁移。RTSP 只负责“控制”，真正的音视频数据通常由 RTP/RTCP 承载，通过 SETUP 阶段协商好的传输通道发送。
RTSP 请求报文由请求行、首部字段和消息体组成，请求行格式为：方法 URI RTSP/1.0。响应报文由状态行、首部字段和消息体组成，状态行格式为：RTSP/1.0 状态码 原因短语。所有请求和响应都必须携带 CSeq（命令序列号），用于请求与响应的配对。
二、方法流程：六个请求的职责与报文要点
OPTIONS 是能力探测请求，客户端用它询问服务器支持哪些方法。服务器在响应首部 Public 中列出所有可用方法。这一步不是必须的，但在调试和兼容性验证时非常有用。
DESCRIBE 用于获取媒体描述信息，服务器返回 SDP（Session Description Protocol）文本。SDP 中包含了媒体类型、编码格式、时钟频率、轨道数量等关键参数。客户端只有拿到 SDP，才知道后续 SETUP 要建立几条轨道。
SETUP 是建立传输通道的关键步骤。客户端在请求中通过 Transport 首部指定传输方式（如 RTP/AVP/UDP 或 RTP/AVP/TCP）以及客户端接收端口。服务器在响应中返回 Session 标识符，后续所有请求都必须携带这个 Session ID。每条媒体轨道都需要单独 SETUP 一次。
PLAY 通知服务器开始发送媒体数据。请求中可携带 Range 首部指定播放时间范围。服务器响应中的 RTP-Info 提供了 RTP 序列号和时间戳的起始信息，帮助客户端同步。
PAUSE 暂停媒体流，但保持会话和传输参数不变，之后可以再次 PLAY 恢复。它适合需要临时停止但不想重新协商的场景。
TEARDOWN 终止会话，释放服务器资源。请求中携带 Session ID，服务器响应 200 OK 后，整个 RTSP 会话结束。
OPTIONS rtsp://192.168.1.100:554/live RTSP/1.0
CSeq: 1
User-Agent: LibVLC/3.0.20
RTSP/1.0 200 OK
CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN
DESCRIBE rtsp://192.168.1.100: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.100
s=Live Stream
t=0 0
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
三、案例场景：一次完整的 RTSP 拉流交互
假设客户端要从 rtsp://192.168.1.100:554/live 拉取一路 H.264 视频流。典型交互如下：
- 客户端发送 OPTIONS，确认服务器支持的方法集合。
- 客户端发送 DESCRIBE，获取 SDP，得知只有一条视频轨道，编码为 H264，负载类型 96。
- 客户端发送 SETUP，指定
Transport: RTP/AVP/UDP;unicast;client_port=8000-8001，服务器返回Session: 12345678和服务器端口。 - 客户端发送 PLAY，携带 Session ID，服务器开始通过 RTP 向客户端 8000 端口发送视频数据。
- 用户点击暂停，客户端发送 PAUSE，服务器停止发送 RTP 包，但保留会话。
- 用户关闭播放器，客户端发送 TEARDOWN，服务器释放资源，会话结束。
四、误区与复盘：常见问题与排查思路
| 常见误区 | 现象 | 正确做法 |
|---|---|---|
| 忽略 Session ID | PLAY 返回 454 Session Not Found | SETUP 响应中的 Session 必须保存，后续请求全部携带 |
| 只 SETUP 一条轨道 | 只有视频没有音频，或播放失败 | SDP 中每条 m= 行都要单独 SETUP |
| DESCRIBE 后直接 PLAY | 服务器返回 455 Method Not Valid | 必须先 SETUP 建立传输，再 PLAY |
| PAUSE 后重新 DESCRIBE | 会话混乱，资源重复占用 | PAUSE 后直接 PLAY 恢复，无需重新协商 |
| 不发送 TEARDOWN | 服务器会话泄漏，端口长期占用 | 播放结束主动 TEARDOWN，释放 Session |
复盘时，建议用 Wireshark 过滤 rtsp 协议，逐条检查 CSeq 是否连续、Session 是否一致、Transport 端口是否匹配。RTSP 的状态性决定了任何一个环节的缺失都会导致后续请求失败。掌握这六个方法的职责边界和依赖顺序，是排查 RTSP 推拉流问题的基本功。