1. RTSP协议基础：从概念到交互流程
RTSP，全称 Real Time Streaming Protocol，中文叫实时流传输协议。说白了，它就是用来控制音视频流的「遥控器」。你想想看，我们看视频的时候，需要播放、暂停、快进、后退，这些操作在本地播放器里很自然，但放到网络上呢？RTSP 就是干这个的。
我记得刚接触流媒体那会儿，总把 RTSP 和 RTP 搞混。后来才明白，RTSP 负责「控制」，RTP 负责「传输数据」。打个比方：RTSP 是导演，RTP 是演员，导演喊「Action」，演员才开始演。
1.1 RTSP协议概述
RTSP 是 IETF 在 1998 年发布的 RFC 2326 标准。它是个应用层协议，默认端口是 554。它的设计思路和 HTTP 很像——都是文本协议，都有请求和响应。但有个关键区别：HTTP 是无状态的，RTSP 是有状态的。
什么叫有状态？就是服务器得记住每个客户端当前在干什么。比如你发了个 PLAY 请求，服务器得知道你现在处于「准备播放」的状态，而不是「刚连接」的状态。这个设计让 RTSP 能精确控制流媒体的播放流程。
核心特点：
- 支持多种传输方式：单播、组播
- 支持多种底层传输协议：TCP、UDP
- 可扩展性强：可以自定义方法
- 与 RTP/RTCP 配合使用，实现完整的流媒体方案
1.2 RTSP与RTMP/HTTP对比
做流媒体开发，这三个协议你肯定绕不开。我刚开始选型的时候也纠结过，后来踩了些坑，才摸清楚各自的适用场景。
| 特性 | RTSP | RTMP | HTTP（HLS/DASH） |
|---|---|---|---|
| 传输层 | TCP/UDP | TCP | TCP |
| 延迟 | 低（200-500ms） | 低（1-3s） | 高（5-30s） |
| 控制能力 | 强（播放/暂停/快进） | 中（仅播放） | 弱（仅播放） |
| 防火墙友好 | 差（需要开放多个端口） | 中（使用单一端口） | 好（使用80/443端口） |
| 适用场景 | 安防监控、IP摄像头 | 直播推流、互动直播 | 点播、OTT视频 |
我个人习惯是：做安防项目首选 RTSP，因为它延迟低、控制灵活。做直播互动用 RTMP，因为 Adobe 生态成熟。做点播视频用 HLS，因为兼容性好、能穿透防火墙。
避坑指南：我曾经在一个监控项目里用 RTMP 替代 RTSP，结果发现延迟从 300ms 飙到了 3 秒。后来才意识到，RTMP 的握手和缓冲机制不适合实时性要求高的场景。所以选协议之前，一定先搞清楚你的延迟要求。
1.3 RTSP消息格式
RTSP 的消息格式和 HTTP 几乎一样。我刚开始学的时候，直接用 HTTP 的思维去理解，发现八九不离十。消息分为两种：请求和响应。
请求消息格式：
方法 URI RTSP版本
首部字段名: 首部字段值
...
空行
消息体（可选）响应消息格式：
RTSP版本 状态码 原因短语
首部字段名: 首部字段值
...
空行
消息体（可选）举个例子，一个典型的 SETUP 请求：
SETUP rtsp://example.com/video RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001对应的响应：
RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001
Session: 12345678嗯，这里要注意 CSeq 字段。它是个序列号，用来匹配请求和响应。客户端发的每个请求，CSeq 都要递增。服务器响应时，CSeq 必须和请求一致。这个设计很简单，但很实用——我在调试的时候经常靠 CSeq 来排查丢包问题。
1.4 RTSP交互流程
RTSP 的交互流程，说白了就是「五步走」。我画了个图，你看一眼就明白了。
这个流程我拆解一下：
- OPTIONS：客户端问服务器「你支持哪些方法？」。服务器回复「我支持 DESCRIBE、SETUP、PLAY、TEARDOWN」。
- DESCRIBE：客户端问「这个流是什么格式？」。服务器返回 SDP 描述，包含视频编码、分辨率、音频采样率等信息。
- SETUP：客户端说「我要用 UDP 传数据，端口是 8000-8001」。服务器分配端口，建立传输通道。
- PLAY：客户端说「开始播放」。服务器开始发送 RTP 数据包。
- TEARDOWN：客户端说「结束」。服务器释放资源，关闭会话。
注意事项：我曾经在 SETUP 阶段踩过一个坑——客户端端口和服务器端口必须配对。比如客户端声明 client_port=8000-8001，服务器回复 server_port=9000-9001。如果端口不匹配，RTP 数据就传不过去。调试的时候记得用 Wireshark 抓包看看端口号对不对。
1.5 状态机：RTSP的核心
RTSP 的状态机是理解协议的关键。说白了，就是客户端和服务器之间有个「约定」——你当前处于什么状态，才能发什么请求。
状态有三种：
- INIT（初始状态）：刚建立 TCP 连接，还没做任何操作。
- READY（就绪状态）：SETUP 完成后，传输通道已建立，等待播放。
- PLAYING（播放状态）：PLAY 请求后，正在传输数据。
状态转换规则很简单：
- INIT → READY：执行 SETUP
- READY → PLAYING：执行 PLAY
- PLAYING → READY：执行 PAUSE
- 任何状态 → INIT：执行 TEARDOWN
我刚开始写 RTSP 客户端的时候，没注意状态机，直接发了 PLAY 请求，结果服务器返回 455 Method Not Valid In This State。嗯，从那以后我就记住了——状态不对，请求白费。
调试技巧：如果你用 VLC 做 RTSP 客户端，可以在「工具→消息」里看到完整的 RTSP 交互日志。我经常用这个来验证自己的服务器实现是否正确。另外，rtspdump 也是个好工具，能帮你抓取 RTSP 消息。