📚 课程目录第3章 RTSP协议入门

3. RTSP协议入门

RTSP（Real-Time Streaming Protocol，实时流传输协议）是流媒体领域最经典的“控制协议”之一。很多初学者第一次接触 RTSP 时，会把它和 HTTP 混为一谈，因为两者都使用文本请求、都有方法名、都跑在 TCP 之上。但真正理解 RTSP 的关键，是先明确它的定位：RTSP 不负责传输音视频数据本身，它负责的是“控制”——像遥控器一样，对一路已经存在的媒体流执行播放、暂停、定位、停止等操作。真正承载音视频码流的，通常是 RTP/RTCP，或者在某些场景下是裸 RTP over TCP/UDP。

因此，RTSP 更像是一个“会话控制层”协议，而不是“数据传输层”协议。它位于应用层，和 HTTP 同层，但设计目标完全不同：HTTP 面向“请求—响应—断开”的短连接资源获取，RTSP 面向“建立会话—持续控制—多状态切换”的长连接流媒体控制。

一、RTSP 的定位：流媒体的“遥控器”

在典型的 RTSP 推流/拉流链路中，各协议分工如下：

RTSP：负责会话建立、方法交互、播放控制、参数协商。
RTP：负责承载 H.264/H.265/AAC 等音视频数据包。
RTCP：负责传输质量反馈、丢包统计、同步信息。
SDP：通常由 DESCRIBE 响应携带，描述媒体类型、编码、端口、payload type 等。

所以，当你在 VLC 或 FFmpeg 中打开一个 rtsp:// 地址时，背后并不是“RTSP 在传视频”，而是 RTSP 先完成握手和协商，随后 RTP 才开始把音视频包源源不断地送过来。RTSP 的核心价值，是让客户端和服务器对“这路流怎么播、播到哪、什么时候停”达成一致。

二、RTSP 与 HTTP 的关系：像，但不一样

RTSP 在语法风格上借鉴了 HTTP：请求行由“方法 URI 版本”组成，头部字段是 Key: Value 形式，状态码也是三位数字。但两者的语义和状态管理差异很大。

对比维度	HTTP	RTSP
主要用途	获取网页、图片、文件等资源	控制实时音视频流的播放
连接模型	短连接为主，请求-响应后关闭	长连接会话，可多次方法交互
状态管理	无状态	有状态，依赖 Session ID
数据承载	响应体直接返回数据	媒体数据由 RTP 承载，RTSP 只控制
典型方法	GET、POST、PUT、DELETE	OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN
默认端口	80 / 443	554 / 8554

一个常见的误区是：认为 RTSP 和 HTTP 可以互相替代。实际上，HTTP 适合点播文件、HLS/DASH 切片分发；RTSP 更适合低延迟、可交互的实时流控制。两者不是竞争关系，而是不同场景下的不同工具。

三、典型交互流程：从 OPTIONS 到 TEARDOWN

下面是一次标准的 RTSP 拉流交互流程。客户端先探测服务器能力，再获取媒体描述，然后建立传输通道，最后开始播放。

C -> S: OPTIONS rtsp://192.168.1.10:554/live/test RTSP/1.0
        CSeq: 1

S -> C: RTSP/1.0 200 OK
        CSeq: 1
        Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN

C -> S: DESCRIBE rtsp://192.168.1.10:554/live/test RTSP/1.0
        CSeq: 2
        Accept: application/sdp

S -> C: RTSP/1.0 200 OK
        CSeq: 2
        Content-Type: application/sdp
        Content-Length: 218

        v=0
        o=- 0 0 IN IP4 192.168.1.10
        s=Live Stream
        m=video 0 RTP/AVP 96
        a=rtpmap:96 H264/90000

C -> S: SETUP rtsp://192.168.1.10:554/live/test/track1 RTSP/1.0
        CSeq: 3
        Transport: RTP/AVP/TCP;unicast;interleaved=0-1

S -> C: RTSP/1.0 200 OK
        CSeq: 3
        Session: 12345678
        Transport: RTP/AVP/TCP;unicast;interleaved=0-1

C -> S: PLAY rtsp://192.168.1.10:554/live/test RTSP/1.0
        CSeq: 4
        Session: 12345678

S -> C: RTSP/1.0 200 OK
        CSeq: 4
        Session: 12345678
        RTP-Info: url=track1;seq=1000;rtptime=200000

C -> S: TEARDOWN rtsp://192.168.1.10:554/live/test RTSP/1.0
        CSeq: 5
        Session: 12345678

S -> C: RTSP/1.0 200 OK
        CSeq: 5
        Session: 12345678

这段交互中，CSeq 用于请求与响应配对，Session 用于标识一次会话，Transport 决定 RTP 走 TCP 还是 UDP，RTP-Info 则告诉客户端从哪个序列号和时间戳开始播放。理解这些字段，是排查 RTSP 推拉流问题的基本功。

四、核心方法：每个方法都在解决什么问题

RTSP 的方法不多，但每一个都对应明确的控制语义。下面用清单方式梳理：

OPTIONS：查询服务器支持哪些方法，常用于能力探测。
DESCRIBE：获取媒体描述，响应体通常是 SDP，告诉客户端有几路媒体、编码是什么、时钟频率是多少。
SETUP：为某一路 track 建立传输参数，决定 RTP 走 UDP 还是 TCP，并返回 Session ID。
PLAY：启动播放，可携带 Range 指定播放区间，响应中常带 RTP-Info。
PAUSE：暂停播放，会话保持，后续可继续 PLAY。
TEARDOWN：结束会话，释放服务器资源。
GET_PARAMETER / SET_PARAMETER：读取或设置会话参数，也常被用作保活心跳。

提示：很多 RTSP 服务器要求客户端定期发送 OPTIONS 或 GET_PARAMETER 作为心跳，否则会因会话超时被断开。如果你发现推流几分钟后自动中断，优先检查心跳机制。

五、案例与排障：一次 RTSP 拉流失败的复盘

假设你用 FFmpeg 拉流时出现如下错误：

ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.10:554/live/test -c copy out.mp4

[rtsp @ 0x...] method DESCRIBE failed: 404 Not Found
rtsp://192.168.1.10:554/live/test: Server returned 404 Not Found

这个错误的含义是：RTSP 服务器收到了 DESCRIBE 请求，但找不到对应的流路径。排查顺序应该是：

确认 URL 路径是否正确，大小写、斜杠、流名称是否匹配。
确认流是否已经由推流端发布到服务器，服务器上是否存在该流。
确认端口是否正确，554 是默认端口，但很多服务使用 8554 或其他端口。
用 ffprobe 或 VLC 单独测试，排除播放器自身问题。

如果错误变成 401 Unauthorized，则说明需要认证，通常要在 URL 中携带用户名密码，例如 rtsp://admin:password@192.168.1.10:554/live/test。如果错误是 461 Unsupported Transport，则说明客户端请求的传输方式服务器不支持，可以尝试切换 -rtsp_transport udp 或 tcp。

常见误区：把 RTSP 当成“视频流协议”本身。实际上 RTSP 只负责控制，真正传输视频的是 RTP。排查问题时，如果 RTSP 握手成功但画面黑屏，问题往往在 RTP 端口、防火墙、SDP 协商或编码参数上，而不是 RTSP 方法本身。

六、小结：抓住“控制”与“承载”的分层

理解 RTSP，最重要的是建立分层思维：RTSP 负责会话控制，SDP 负责媒体描述，RTP/RTCP 负责数据承载与质量反馈。它与 HTTP 形似而神不同，HTTP 是无状态资源获取，RTSP 是有状态流控制。掌握 OPTIONS、DESCRIBE、SETUP、PLAY、TEARDOWN 这条主线，再结合 CSeq、Session、Transport、RTP-Info 等关键字段，你就具备了阅读 RTSP 交互日志和排查推拉流问题的基本能力。