RTSP 拒绝消亡，因为它依然运行良好

每隔几年，就会有人发表一篇”RTSP已死”的文章。他们会指出，这个协议诞生于1998年，无法在浏览器中运行，不能接入CDN，也不支持自适应码率。结论是：直接用WebRTC就完事了。

但如果你看看实际的部署基数呢？IP摄像头、NVR（网络视频录像机）、无人机、医疗机器人、工业监控系统——几乎所有设备都默认使用 RTSP。更换这些设备将耗费整个行业数十亿美元。因此，这个协议之所以延续至今，不是因为工程师懒惰或无知，而是因为它在自身设计的应用场景中，确实比大多数替代方案更胜任。

这篇文章将探讨RTSP到底是什么、它是如何运作的、它在哪些领域仍然胜出，以及当你在今天构建系统时，应该如何做出务实的决策。

RTSP 实际上做了什么（以及它没做什么）

大多数人搞错的第一件事：RTSP并不传输你的视频。它从来没有。 实时流传输协议（Real Time Streaming Protocol）是一个控制协议。你可以把它想象成流媒体会话的遥控器，即负责建立、拆除、播放和暂停。实际的视频数据走另外的通道，通常通过RTP（实时传输协议）传输，而RTCP（实时控制协议）则在旁边运行，负责报告质量和同步信息。

这种关注点分离是刻意为之的。RTSP控制媒体会话，而音频和视频通过独立的端口经由RTP传输。这种设计让你可以在不将控制层与载荷格式耦合的情况下协商传输选项。

IETF于1998年将RTSP标准化为RFC 2326，随后RTSP 2.0于2016年以RFC 7826的形式发布。该协议由RealNetworks、Netscape和哥伦比亚大学合作开发，源自1996年底提交的草案。IETF 将其描述为”多媒体服务器的网络遥控器”，这个描述出奇地经得起时间考验。

一个会话遵循固定的握手流程：

• OPTIONS：客户端询问服务器支持哪些方法
• DESCRIBE：客户端请求SDP文件，获取编解码器、码率和传输详情
• SETUP ：客户端选择媒体的传输方式（UDP、TCP交织、组播）
• PLAY：服务器开始发送RTP数据包
• PAUSE / TEARDOWN ：客户端暂停或结束会话

关于SETUP步骤有一点值得注意：客户端实际上可以自主选择传输机制，这使得RTSP作为一个老旧协议来说异常灵活。你可以在本地网络上使用UDP承载RTP以获得最低开销，也可以在需要穿透防火墙时将所有内容交织在TCP上。实践中，TCP几乎普遍用于RTSP控制通道，而媒体载荷的传输方式则取决于网络条件。

技术概览

在深入用例之前，先看看你实际在处理的是什么：

• 支持的视频编解码器： H.264（AVC）、H.265（HEVC）、VP8、VP9、MJPEG
• 支持的音频编解码器： AAC、AAC-LC、HE-AAC+ v1和v2、MP3、Opus、Speex、Vorbis
• 默认端口： 554（TCP），有时用8554用于次要流
• 安全性： 原生RTSP没有内置加密。RTSPS（基于TLS的RTSP）运行在端口322上，对控制通道进行加密。对于媒体载荷，SRTP（安全RTP）负责加密。截至2024年底，Axis、Bosch、FFmpeg、GStreamer等多家厂商已支持RTSPS。
• CDN友好性： 否。RTSP使用持久连接和有状态会话，不适合CDN分发模型。
• 浏览器播放： 原生不支持。在浏览器中观看RTSP流需要媒体服务器转码为HLS、DASH或WebRTC。

人们引用的典型延迟数据，如本地网络环境下低于500毫秒，有时甚至低于100毫秒是真实的。RTSP实现了低于500毫秒的延迟，使其非常适合实时监控和控制场景。RTP是如何实现这一点的值得理解：它通过小型UDP数据包发送音频和视频，每个数据包的头部都包含序列号和时间戳。接收方可以从这些头部重建时序，即使数据包乱序到达，这就是无需等待丢包重传即可实现流畅播放的原理。

为什么它在2026年仍然活跃

安装基数庞大且不会消失

IP摄像头自20世纪90年代末起就内置RTSP支持。安防系统、交通监控基础设施、工地视频、零售监控运行这些的硬件是经过数年和数十年安装的，而非几个月。用原生WebRTC的硬件替换它们，在大多数运营预算中都不是一个行项目。RTSP就是摄像头协议的首选，毫无争议，这一事实使它对任何构建需要对接真实硬件的平台的人都有意义。

ONVIF标准定义了不同制造商IP摄像头的互操作性，以RTSP作为其核心流传输机制。如果你构建的VMS（视频管理系统）或NVR不支持RTSP，你将被绝大多数可用硬件拒之门外。

客户端-服务器模型比你想象的更简单

WebRTC因其低于250毫秒的延迟和浏览器支持而备受关注。但较少被提及的是，WebRTC是作为点对点协议设计的，并因此带有相应的开销。每个连接都需要ICE（交互式连接建立）用于NAT穿越、DTLS用于加密握手，以及一个独立的信令通道——通常是WebSocket，或者越来越多地使用WHIP，该协议于2025年3月被标准化为RFC 9725。

RTSP从设计之初就是客户端到服务器的模式，跳过了上述大部分复杂性。单个TCP连接处理所有控制消息。在本地网络中不需要NAT穿越仪式。如果你构建的系统是许多摄像头与同一子网上的媒体服务器通信，如仓库、医院楼层、制造产线，RTSP更简单的连接模型会给服务器带来明显更低的负载，并允许每个节点承载更多并发流。

毫秒级应用场景容不得抽象层

为急救人员提供画面的无人机。使用远程临场机器人的远程手术。边境监控。排爆设备。这些不是小众应用；它们是活跃的、不断增长的市场，需要数百毫秒级别的延迟，而非秒级。

一架无人机将RTSP传输到媒体服务器，然后通过WebRTC分发给授权观众，端到端延迟低于一秒。通过HLS运行相同的工作流会增加6到30秒的延迟。到那时你看到的不是实时画面，而是近期历史。对于引导机器人穿越燃烧建筑的人来说，这种区别不是小事。

这些关键系统的实际架构通常是将RTSP推流到媒体服务器集群，然后转换为WebRTC供观众端播放。你在摄像头端获得RTSP的硬件兼容性和简洁性，在观众端获得WebRTC的浏览器覆盖和加密能力。

RTSP 与同类协议对比

将RTSP与HLS或MPEG-DASH等播放协议进行比较没有意义。它们解决的是流水线中不同环节的问题。RTSP是推流协议，HLS是分发协议。把它们放在一个对比表中对双方都是误导。真正的比较应该是RTSP与其他推流和贡献协议之间的对比。

RTSP vs. RTMP

RTMP是OBS和Wirecast等软件编码器的默认输出，仍然是YouTube Live、Facebook Live和Twitch的推流机制。它运行在TCP上，协议开销比RTSP更大，延迟通常在250毫秒到3秒之间，而RTSP在本地网络上可以低于100毫秒。RTMP是向平台进行直播事件推流的正确选择。RTSP是将IP摄像头推流到自有基础设施的正确选择。

RTSP vs. SRT

SRT（安全可靠传输）专为在不可预测网络上进行流传输而设计——公共互联网、卫星链路、不稳定的移动连接。它包含丢包恢复、加密和自适应重传。在稳定的本地网络上，RTSP更简单且同样快速。在公共互联网上，SRT更稳健。根据Haivision的广播转型报告，2025年SRT在视频专业人士中的采用率达到了77%。

RTSP vs. MPEG-TS 组播

广播和IPTV环境使用UDP组播上的MPEG-TS向同一网络上的多个接收方高效发送单个流。这对于酒店、体育场和有线电视前端等已有组播基础设施的固定环境非常出色。但这不适用于公共互联网。RTSP在单播模式下对于混合环境更灵活。

RTSP vs. WebRTC（推流端）

如果你的源设备是浏览器或支持WHIP的现代编码器，WebRTC推流越来越实用，能提供端到端加密和低于250毫秒的延迟。代价是信令的复杂性，以及基本上没有IP摄像头支持WebRTC这一事实。在可预见的未来，任何以硬件为主的部署，推流端都将与RTSP共存。

当前实际架构落地方案

大多数构建严肃视频基础设施的团队最终采用的模式如下：

摄像头（RTSP）> 媒体服务器 > 观众端（WebRTC或HLS，取决于延迟需求）

中间的媒体服务器无论是Wowza、Ant Media、自托管的Mediamtx实例还是负责协议转换的托管平台。它接收RTSP流，解码RTP流，然后将媒体重新打包为观众端协议所需的格式。转封装（Transmuxing）在不重新编码的情况下重新打包，在保持质量的同时实现广泛的播放兼容性。

真正重要的架构决策不是”RTSP还是WebRTC”，而是在流水线的哪个阶段使用哪个协议，以及媒体服务器放在哪里。

关于安全性：文档中很少讲透的部分

原生RTSP没有内置加密。如果你的摄像头在防火墙后面的本地网络上，且从不暴露在公共互联网上，这在实践中通常是可接受的。如果你将RTSP端口暴露在互联网上，很多人这样做，因为这是远程查看摄像头最简单的方式，这就是真实的风险。

实用的加固清单：

• 在将每台摄像头接入网络之前更改默认凭据。许多摄像头出厂时使用admin/admin或根本没有密码。
• 在摄像头支持的情况下使用RTSPS（基于TLS的RTSP）。Axis、Bosch等厂商原生支持。
• 如果你的流水线支持，使用SRTP对媒体载荷进行加密。
• 将摄像头放在与网络其他部分隔离的专用VLAN中。
• 使用VPN或安全媒体服务器作为网关，而不是将原始RTSP端口直接转发到互联网。
• 如果使用云平台进行推流，摄像头与平台端点通信，观众永远不会直接连接到摄像头。

RTSP使用HTTP风格的认证（基本认证和摘要认证），这意味着它带有一些相同的漏洞，特别是在没有TLS包裹连接的情况下。这是一个已知问题，而非理论上的隐患。

实用决策框架

在以下情况使用RTSP：

• 你的源设备是IP摄像头、NVR或其他内置RTSP输出的硬件
• 你需要在本地网络上获得低于100毫秒的延迟
• 你的数据不能离开你的基础设施，且你运行自己的媒体服务器
• 你正在构建推流基础设施，而非面向观众的分发系统
• 运行环境是可控的（本地LAN、VPN、私有云）

在以下情况考虑通过WHIP使用WebRTC推流：

• 你的源是浏览器或现代软件编码器
• 你需要端到端加密而无需自己构建TLS层
• 信令复杂性对你的团队来说可控

在以下情况添加媒体服务器并转换为HLS或WebRTC进行分发：

• 你需要浏览器原生播放
• 你需要服务超过少量并发观众
• CDN分发是计划的一部分

在以下情况考虑SRT：

• 你需要在公共互联网或不稳定网络上进行可靠的贡献推流
• 你正在构建广播或专业制作工作流

展望未来

RTSP 2.0（RFC 7826）自2016年以来已经存在，解决了原始规范的若干不足，但摄像头制造商的采用一直缓慢。大多数硬件仍然输出RTSP 1.0流，大多数VMS平台默认仍然读取RTSP 1.0。

基于QUIC的媒体传输（MoQ）是业界正在推进的协议，旨在最终将推流和分发合并为一个单一的CDN原生协议栈，既能处理实时交互又能支撑大规模并发。2025年，Cloudflare在330个城市推出了首个MoQ中继网络。MOQT RFC预计将在2026年定稿。但MoQ对大多数用例尚未达到生产就绪状态，而且无论规范何时完成，硬件生态系统的跟进都将滞后数年。

在可预见的未来，任何构建与真实摄像头通信的实际基础设施的人，都将在与RTSP对话。不是因为更好的选择在某些场景中不存在，而是因为这个协议胜任这份工作、硬件在使用它、且替换的经济成本高昂。

这就是它依然存在的原因。这也是它短期内不会离开的原因。

作者：Daan Hoekstra
https://hackernoon.com/rtsp-refuses-to-die-because-it-still-works-just-fine
翻译：mazhu