SRS、SRT、RTMP 流媒体协议详解：如何搭建低延迟直播系统？

最近看到不少朋友在讨论流媒体相关的技术，尤其是 SRS、SRT 和 RTMP 这几个关键词出现的频率越来越高。很多人可能刚接触这一块，对它们的关系和区别还不是特别清楚，今天就借这个机会，用大白话给大家梳理一下，顺便聊聊在实际应用中该怎么选。

RTMP 推流原理示意图

RTMP 协议工作原理示意图

先说 RTMP（Real-Time Messaging Protocol），这应该算是流媒体界“老资格”了。早年间 Flash 盛行的时候，RTMP 几乎统治了直播推流的半壁江山。

SRT 协议抗抖动传输示意图

SRT 协议在不稳定网络下的传输优势

优点：兼容性极强。不管是 OBS 还是 FFmpeg，甚至是早些年的直播软件，对 RTMP 的支持都是原生且完善的。部署简单，资料丰富，遇到问题随便一搜就能找到解决方案。
缺点：基于 TCP，这就意味着延迟很难降下来。通常 RTMP 的延迟在 3-5 秒甚至更高，对于即时互动性要求高的场景（比如连麦、云游戏）来说，这个延迟是硬伤。而且，随着 Flash 的淘汰，RTMP 在浏览器端播放需要依赖转码插件（如 flv.js），但这目前还算是个成熟的后备方案。

SRS 流媒体服务器架构图

SRS 服务器多协议转换架构图

SRT（Secure Reliable Transport）是近年来非常火的一个协议，主打的就是在 unstable network（不稳定网络）下的低延迟传输。

优点：基于 UDP，但加入了重传机制，既保证了低延迟（通常能控制在几百毫秒），又保证了数据的可靠性。跨运营商、跨国传输的时候，SRT 的抗抖动能力非常强，画面不容易卡顿。
缺点：生态圈相对 RTMP 来说还在成长中。虽然 OBS 和 FFmpeg 都支持了，但一些老旧的小众软件可能就不认 SRT。此外，调试和排查问题稍微复杂一点。

OBS 推流设置界面示例

使用 OBS 进行 RTMP 推流的配置示例

很多人会把 SRS（Simple Realtime Server）和上面的协议搞混，其实 SRS 是一个流媒体服务器软件，它本身支持多种协议。

定位：它是一个开源的高性能服务器，既可以作为 RTMP 服务器接收推流，也可以作为 SRT 服务器，同时还支持 HTTP-FLV、HLS、WebRTC 等分发协议。简单说，SRS 是一个“集大成者”，它能帮你把推进来的流转换成各种终端能播放的流。
特点：社区活跃，中文文档写得非常棒（作者也是国人），对于国内开发者非常友好。它的架构设计得比较轻量，资源占用低，适合在配置不高的 VPS 上搭建。

明白了它们的区别，结合实际需求来选就简单多了。

常规直播、拉推流门槛低：如果你就是想把 OBS 推出来的流分发给观众，对延迟要求不高（允许 5 秒左右），且不想折腾复杂的配置，那么 RTMP + SRS 依然是性价比最高的选择。推流用 RTMP，分发用 HTTP-FLV 或 HLS，技术成熟稳定。
跨地域、弱网环境、低延迟：如果你打算做跨国直播，或者网络环境很差（比如丢包率较高），同时又希望延迟在 1 秒以内，那么 SRT 是首选。利用 SRS 作为中转服务器，让 OBS 使用 SRT 协议推流给 SRS，SRS 再转码分发，能极大提升用户体验。
超低延迟互动（<500ms）：这种场景下，单纯靠 SRT 或 RTMP 可能都不够。这时候需要 SRS 结合 WebRTC 来实现。WebRTC 能在浏览器端实现极低延迟的播放，适合直播连麦、在线教育等强互动场景，但对服务器性能和带宽要求稍高。

如果你是第一次尝试搭建流媒体服务，建议从 SRS 部署开始。

这样一套流程走通后，你就可以根据实际体验，尝试把推流端换成 SRT，或者把分发端换成 WebRTC，逐步优化你的直播系统。

流媒体技术水很深，但只要理清协议和服务器的关系，就能根据业务需求找到最合适的那个“解”。希望大家少踩坑，早日搭建出满意的直播环境！