RTSP 协议基础：从概念到实战
各位同学好，我是你们这门课的老朋友。今天咱们聊聊 RTSP 协议。说实话，我最早接触 RTSP 是在做安防监控项目的时候，那时候刚入行，被各种流媒体协议搞得晕头转向。后来踩了不少坑，才慢慢摸清楚 RTSP 到底是个什么东西。
RTSP，全称 Real-Time Streaming Protocol，中文叫实时流协议。它由 IETF 在 1998 年标准化，RFC 2326 就是它的身份证。你想想看，一个协议活了二十多年还在广泛使用，说明它确实有两把刷子。
核心要点：RTSP 是一个应用层协议，负责控制多媒体流的建立、播放、暂停、录制等操作。它本身不传输媒体数据，而是充当“遥控器”的角色。
RTSP 协议概述
RTSP 的设计哲学很有意思。它借鉴了 HTTP 的很多思想，比如文本格式、请求-响应模型，但两者有本质区别。HTTP 是无状态的，请求完就断开；RTSP 是有状态的，它需要维护一个会话（Session），记录当前播放进度、传输方式等信息。
我个人习惯把 RTSP 理解为“流媒体的 VCR 遥控器”。你想想看，用遥控器控制录像机播放、暂停、快进、后退，RTSP 干的就是类似的事。它通过以下几个核心方法来实现控制：
- DESCRIBE：获取媒体描述信息，比如视频编码格式、分辨率、音频采样率等
- SETUP：建立传输通道，协商传输方式（UDP/TCP）和端口
- PLAY：开始播放，可以指定播放范围（比如从第10秒开始）
- PAUSE：暂停播放，保持会话状态
- TEARDOWN：终止会话，释放资源
我在项目中遇到过一个问题：客户端发送 PLAY 请求后，服务器没响应。排查了半天，发现是 SETUP 阶段没协商好传输端口。嗯，这里要注意，RTSP 的每个方法都有严格的顺序依赖，乱序调用会导致各种奇怪的问题。
实战小技巧：调试 RTSP 时，可以用 Wireshark 抓包，过滤条件设为 rtsp，能清晰看到每个请求-响应的交互过程。我曾经靠这个定位过一个诡异的“播放5秒后卡死”的 bug。
RTSP 与 RTMP/HTTP 对比
很多新手会问：RTSP、RTMP、HTTP 到底选哪个？说实话，没有银弹，每种协议都有自己的适用场景。我整理了一张对比表，方便大家直观理解：
| 对比维度 | RTSP | RTMP | HTTP（HLS/DASH） |
|---|---|---|---|
| 传输层 | TCP/UDP | TCP | TCP |
| 延迟 | 低（200ms-1s） | 低（1-3s） | 高（5-30s） |
| 控制能力 | 强（播放/暂停/快进） | 弱（仅播放） | 弱（仅播放） |
| 防火墙友好 | 差（需开放多端口） | 中（使用单一端口） | 好（使用80/443） |
| 适用场景 | 安防监控、视频通话 | 直播推流、互动直播 | 点播、OTT 视频 |
为什么 RTSP 延迟低？因为它可以用 UDP 传输，省去了 TCP 的三次握手和拥塞控制。但代价就是防火墙穿透困难。我曾经在一个客户现场部署 RTSP 推流，客户网络策略严格，UDP 端口全被封了，最后只能切到 TCP 模式，延迟从 300ms 涨到了 800ms，但至少能用了。
RTMP 呢？它由 Adobe 发明，最初用于 Flash 播放器。现在虽然 Flash 已死，但 RTMP 作为推流协议依然活跃。很多直播平台都用 RTMP 做上行推流，然后转成 HLS 做下行分发。说白了，RTMP 是“推流之王”，RTSP 是“控制之王”。
HTTP 协议（HLS/DASH）最大的优势是兼容性。任何支持 HTTP 的设备都能播放，CDN 分发也成熟。但延迟是硬伤，HLS 的切片机制决定了它至少有一个切片的延迟（通常 6-10 秒）。
避坑指南：我曾经在一个项目中用 RTSP 做直播，结果用户反馈“画面卡顿、声音断续”。排查后发现是网络丢包导致 UDP 传输的 RTP 包丢失。解决方案：在 RTSP SETUP 阶段强制使用 TCP 传输模式（Transport: RTP/AVP/TCP），虽然增加了一点延迟，但稳定性大幅提升。
RTSP 应用场景分析
RTSP 的应用场景其实很聚焦，不像 HTTP 那么通用。我根据实际项目经验，总结了几个典型场景：
- 安防监控：这是 RTSP 最大的应用领域。海康、大华等厂商的摄像头都支持 RTSP 协议，可以直接拉取视频流。我在做智慧工地项目时，就是通过 RTSP 从 50 多个摄像头拉流，然后做 AI 分析。
- 视频通话/会议：RTSP 配合 RTP/RTCP 可以实现低延迟的音视频传输。不过现在更多被 WebRTC 取代，但一些老系统还在用。
- IPTV/数字电视：很多 IPTV 系统使用 RTSP 实现频道切换、暂停、回看等功能。它的 VCR 控制能力在这里发挥得淋漓尽致。
- 远程教育/医疗：需要低延迟、可控制的场景。比如远程手术示教，老师可以控制视频流的播放进度，学生实时观看。
你可能会问：RTSP 能用于直播推流吗？当然可以。实际上，很多专业直播设备（如编码器）都支持 RTSP 推流。但要注意，RTSP 推流和 RTMP 推流在架构上有区别。RTSP 推流通常需要先建立会话，然后持续发送 RTP 包；而 RTMP 推流是建立一个长连接，持续发送 FLV 标签。
下面这张图展示了 RTSP 推流的典型架构，我画了个 SVG 方便大家理解：
从这张图可以看出，RTSP 推流的核心是“控制与数据分离”。推流端先通过 RTSP 信令建立会话，然后持续发送 RTP 数据包。拉流端同样先通过 RTSP 信令获取媒体描述，然后接收 RTP 数据。整个过程就像打电话：先拨号（信令），然后通话（媒体），最后挂断（TEARDOWN）。
关键认知：RTSP 本身不传输媒体数据，它只负责“指挥”。真正的媒体数据由 RTP（Real-time Transport Protocol）传输，RTCP（RTP Control Protocol）负责质量反馈。这三者配合，构成了完整的流媒体传输体系。