1. RTSP 协议基础：从一次真实踩坑说起
各位好，我是老张。做流媒体这行十几年了，RTSP 算是我最早接触的协议之一。记得 2015 年有个项目，客户说摄像头画面延迟 3 秒，我查了三天才发现是 RTSP 交互流程没走对——嗯，从那以后我就养成了个习惯：不管多熟的协议，都得把基础再过一遍。
这一章咱们就聊聊 RTSP 协议最核心的东西。说白了，RTSP 就是流媒体的遥控器。它不负责传视频数据，只管「播放」「暂停」「快进」这些控制命令。你想想看，没有 RTSP，你连点播都做不到。
1.1 RTSP 协议概述
RTSP（Real Time Streaming Protocol）是 IETF 在 RFC 2326 中定义的。它是个应用层协议，默认端口 554。我个人的理解是：它像 VCR 的遥控器，但比 VCR 复杂得多。
RTSP 有几个关键特性：
- 有状态协议：服务器会记住每个会话的状态。不像 HTTP 那样无状态。
- 支持多种传输方式：可以走 TCP，也可以走 UDP。我建议生产环境用 TCP，丢包少。
- 可扩展性强：通过定义新的方法，可以扩展功能。
- 与 RTP/RTCP 配合使用：RTSP 负责控制，RTP 负责传数据，RTCP 负责质量反馈。
核心要点：RTSP 本身不传输音视频数据。它只负责建立和控制会话。真正的数据流走 RTP。这个区分很重要，很多新手搞混了。
1.2 RTSP 与 HTTP 的区别
经常有人问我：RTSP 和 HTTP 看起来差不多啊，都是文本协议，都有请求和响应。其实差别大了去了。我整理了个表格，方便对比：
| 对比维度 | RTSP | HTTP |
|---|---|---|
| 协议状态 | 有状态，维护会话 ID | 无状态，每个请求独立 |
| 默认端口 | 554 | 80（HTTP）/ 443（HTTPS） |
| 主要方法 | DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN | GET, POST, PUT, DELETE |
| 数据传输 | 不传数据，只传控制命令 | 直接传输数据内容 |
| 方向性 | 双向控制，客户端和服务器都可发起 | 客户端发起请求，服务器响应 |
| URL 格式 | rtsp://host:port/path | http://host:port/path |
| 典型应用 | 视频监控、IPTV、直播 | 网页浏览、API 调用 |
你看，最核心的区别就是「有状态」和「无状态」。HTTP 每次请求都是独立的，服务器不记得你是谁。但 RTSP 不一样，它必须记住每个会话的状态——否则你怎么暂停后再继续播放？
我的经验：如果你在调试 RTSP 时发现「播放一会儿就断流」，多半是会话状态维护出了问题。检查一下服务器端的 Session 超时设置，我一般设 60 秒。
1.3 RTSP 消息格式与交互流程
RTSP 的消息格式和 HTTP 很像，都是文本行。但细节上有差异。咱们先看消息格式：
请求消息格式
方法 URI RTSP版本
首部字段名: 首部字段值
...
空行
消息体（可选）举个例子，一个典型的 DESCRIBE 请求：
DESCRIBE rtsp://192.168.1.100:554/live/ch1 RTSP/1.0
CSeq: 1
Accept: application/sdp
User-Agent: MyStreamClient/1.0响应消息格式
RTSP版本 状态码 原因短语
首部字段名: 首部字段值
...
空行
消息体（可选）对应的响应：
RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 123
v=0
o=- 123456 789012 IN IP4 192.168.1.100
s=Live Stream
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000这里要注意 CSeq 字段。它是个序列号，请求和响应必须对应。我见过有人把 CSeq 写错了，结果服务器一直不响应——排查了半天才发现是这个问题。
标准交互流程
RTSP 的交互流程，说白了就是「五步走」。我画了个流程图，方便你理解：
这五步是标准流程：
- OPTIONS：客户端询问服务器支持哪些方法。服务器返回支持的方法列表。
- DESCRIBE：客户端请求媒体描述信息。服务器返回 SDP 格式的描述，包含音视频编码、分辨率、帧率等。
- SETUP：客户端请求建立传输通道。这一步会协商传输协议（TCP/UDP）、端口号等。
- PLAY：客户端请求开始播放。服务器开始发送 RTP 数据流。
- TEARDOWN：客户端请求结束会话。服务器释放资源。
避坑指南：我曾经遇到过一个情况，客户端直接跳过了 OPTIONS 和 DESCRIBE，直接发 SETUP。结果服务器返回 455 Method Not Valid In This State。记住，RTSP 是有状态协议，步骤不能乱。必须按顺序来。
1.4 关键方法详解
除了上面提到的五个方法，RTSP 还支持其他方法。我挑几个常用的说说：
| 方法 | 方向 | 作用 | 是否必需 |
|---|---|---|---|
| OPTIONS | C→S | 查询服务器支持的方法 | 推荐 |
| DESCRIBE | C→S | 获取媒体描述（SDP） | 推荐 |
| SETUP | C→S | 建立传输通道 | 必需 |
| PLAY | C→S | 开始播放 | 必需 |
| PAUSE | C→S | 暂停播放 | 可选 |
| TEARDOWN | C→S | 结束会话 | 必需 |
| GET_PARAMETER | C↔S | 获取参数值 | 可选 |
| SET_PARAMETER | C↔S | 设置参数值 | 可选 |
| REDIRECT | S→C | 重定向到其他服务器 | 可选 |
这里有个细节：PAUSE 和 TEARDOWN 的区别。PAUSE 只是暂停播放，会话还在，可以随时恢复。TEARDOWN 是彻底结束，会话销毁，资源释放。我见过有人用 TEARDOWN 代替 PAUSE，结果每次暂停都要重新建立连接——浪费带宽。
1.5 状态机与状态码
RTSP 的状态机比 HTTP 复杂。每个会话都有状态：
- Init：初始状态，还没建立会话
- Ready：SETUP 完成后，准备就绪
- Playing：PLAY 成功后，正在播放
- Recording：录制状态（不常用）
状态码方面，RTSP 沿用了 HTTP 的很多状态码，但也有自己的扩展：
| 状态码 | 含义 | 说明 |
|---|---|---|
| 200 | OK | 请求成功 |
| 301 | Moved Permanently | 资源已永久移动 |
| 400 | Bad Request | 请求格式错误 |
| 401 | Unauthorized | 需要认证 |
| 404 | Not Found | 资源不存在 |
| 455 | Method Not Valid In This State | 当前状态下不允许该方法 |
| 500 | Internal Server Error | 服务器内部错误 |
| 551 | Option not supported | 不支持该选项 |
调试技巧：用 Wireshark 抓包时，重点关注 455 和 551 这两个状态码。455 说明你的交互顺序错了，551 说明你用了服务器不支持的功能。我一般先用 OPTIONS 看看服务器支持什么，再决定下一步。
1.6 实际部署中的注意事项
最后聊点实战经验。RTSP 部署时，有几个坑特别容易踩：
- 防火墙端口：RTSP 控制端口 554 要开放，RTP 数据端口（通常是 UDP 范围）也要开放。我建议用 TCP 模式，只开 554 就够了。
- 认证方式：RTSP 支持 Basic 和 Digest 认证。Digest 更安全，但有些老设备只支持 Basic。我建议能上 Digest 就上 Digest。
- 超时设置：服务器端的会话超时时间要合理。太短了容易断流，太长了浪费资源。我一般设 60 秒，配合心跳包使用。
- 并发限制：RTSP 服务器对并发会话数有限制。监控项目里，一台服务器带 100 路摄像头是常见配置。超过这个数，就要考虑负载均衡了。