1. RTSP协议概述：从背景到实战

各位同学好，我是老张。做流媒体这行十几年了，RTSP 算是我打交道最多的协议之一。今天咱们就聊聊 RTSP 的来龙去脉，以及它跟 RTP、RTCP 到底怎么配合的。

说实话，很多人一上来就啃 RFC 文档，结果越看越迷糊。我建议换个思路——先搞清楚 RTSP 为什么诞生，它解决了什么问题，然后再看细节。

RTSP 全称 Real Time Streaming Protocol，由 RealNetworks、Netscape 和哥伦比亚大学在 1996 年共同提出。1998 年正式成为 RFC 2326 标准。

那个年代，互联网上想看点视频可费劲了。要么下载完整个文件才能播放，要么用 RealPlayer 那种私有协议。我记得当时为了看一段 30 秒的新闻片段，得等好几分钟缓冲。

RTSP 的出现，说白了就是解决一个问题：让客户端能像控制 DVD 一样控制网络上的视频流。播放、暂停、快进、后退，这些操作在本地播放器上很自然，但在网络上实现起来并不简单。

核心要点：RTSP 是一个应用层控制协议，它本身不传输媒体数据。它的职责是建立和控制媒体会话，类似于视频流的"遥控器"。

为什么叫"流媒体"？因为数据像水流一样，一边接收一边播放，不用等全部下载完。RTSP 就是管理这条"水流"的阀门和开关。

这是初学者最容易搞混的地方。我直接说结论：RTSP 负责控制，RTP 负责传输，RTCP 负责监控。

你想想看，一个完整的流媒体系统，至少需要三件事：

我在项目中遇到过不少新人，上来就问"RTSP 的推流延迟怎么优化"。其实延迟主要出在 RTP 传输和网络抖动上，跟 RTSP 本身关系不大。RTSP 只是帮你把通道建好，真正跑数据的是 RTP。

协议	端口（默认）	职责	传输层
RTSP	554	会话控制（播放、暂停、停止）	TCP（通常）
RTP	动态（如 5004）	媒体数据传输	UDP（通常）
RTCP	动态（RTP端口+1）	质量反馈、同步	UDP

小技巧：抓包分析时，先看 RTSP 的 DESCRIBE 和 SETUP 请求，里面会告诉你在哪个端口收发 RTP 数据。我曾经调试一个摄像头，死活看不到视频流，最后发现是 RTSP 协商的端口被防火墙拦了。

这里有个关键点：RTSP 和 RTP 可以走不同的传输通道。RTSP 通常走 TCP，保证控制命令的可靠性；RTP 走 UDP，追求实时性。当然，RTP 也可以走 TCP，比如在 NAT 穿透困难的场景下。

RTSP 不是万能的，但在某些领域，它依然是首选。我按实际使用频率排个序：

这是 RTSP 最大的应用场景。你去看看市面上的 IP 摄像头，十有八九都支持 RTSP 协议。为什么？

我曾经给一个园区做过监控系统，300 多路摄像头，全部走 RTSP 拉流。刚开始用 RTMP 试过，延迟高不说，还经常断流。换成 RTSP 后，稳定多了。

这里要分清楚：RTSP 更多用于"拉流"（客户端从服务器取流），但也可以做"推流"（客户端向服务器发流）。

直播场景中，RTSP 的优势在于：

不过现在直播推流更多用 RTMP 或 SRT，RTSP 在直播领域占比在下降。但如果你做的是低延迟直播（比如体育赛事、在线教育），RTSP 依然值得考虑。

早期的视频会议系统很多基于 RTSP。但现在更流行 WebRTC，因为它浏览器原生支持，不需要额外插件。

不过在一些专业视频会议设备（比如思科、宝利通的硬件终端）上，RTSP 仍然是底层协议之一。我调试过一套视频会议系统，终端之间用 SIP 做信令，媒体传输走的就是 RTSP + RTP。

避坑指南：RTSP 不适合大规模分发场景。如果你要做 CDN 分发，建议用 HLS 或 DASH。RTSP 是会话型协议，服务器需要维护每个客户端的状态，连接数一上去，资源消耗很大。我曾经在 5000 路并发时踩过这个坑，后来加了负载均衡才解决。

下面这张图，是我自己总结的 RTSP 知识体系。建议你保存下来，后面每学一章，回来对照一下，看看自己学到哪个位置了。

RTSP 不是最年轻的协议，也不是最流行的协议，但它在安防监控领域的位置，短期内很难被替代。理解 RTSP 的关键，在于分清它和 RTP/RTCP 的职责边界。

嗯，这一章就到这里。记住一句话：RTSP 是导演，RTP 是演员，RTCP 是场务。后面我们会一步步拆解，看看导演是怎么喊"Action"的。