低延时直播协议SRT部署环境搭建全攻略
如果你经常和直播技术打交道，相信对"卡顿"、"延迟"这些词一点都不陌生。传统的RTMP协议虽然成熟稳定，但延迟往往在2到3秒甚至更高，这在很多场景下确实让人头疼。后来我接触到SRT这个协议，不得不说，它在低延时方面的表现确实让人眼前一亮。今天这篇文章，我想用最接地气的方式，带你一步步搭建SRT的部署环境。
在正式开始之前，我想先说说我自己的感受。刚开始接触SRT的时候，我也被那些专业术语搞得一头雾水，什么"握手建立"、"丢包恢复"、"ARQ机制"，听起来确实有点劝退。但后来我发现，其实理解这些概念并不难，关键是要找一个好的切入点。所以这篇文章，我会尽量用"说人话"的方式来讲，希望能让和我一样非科班出身的朋友也能轻松上手。
为什么选择SRT？它到底好在哪里？
在说怎么部署之前，我们先来聊聊SRT到底有什么魔力，让这么多人选择它。SRT是Secure Reliable Transport的缩写，翻译过来就是"安全可靠传输"。它最大的特点就是能够在不可预测的公网环境下，保持相对稳定的低延迟传输。
传统的RTMP协议走的是TCP通道，TCP的特点是可靠，但代价就是延迟高。因为TCP为了保证数据完整，会把所有丢失的包都重传一遍，这在网络不好的时候，延迟就会累积得越来越高。而SRT支持两种传输模式，一种是类似TCP的可靠模式，另一种是UDT模式。UDT模式有个很聪明的设计，它允许在一定程度上丢包，通过前向纠错（FEC）来恢复数据，这样就不用傻傻地等重传，延迟自然就下来了。
还有一个让我觉得特别实用的点，是SRT的延迟参数可以动态调整。你可以根据自己的实际需求，在延迟和可靠性之间找一个平衡点。比如做互动直播的时候，你可以把延迟压到几百毫秒；如果是普通的直播推流，稍微放宽一点也没关系。这种灵活性是很多传统协议给不了的。
部署前的准备工作
好了，知道了SRT的好处，接下来我们聊聊部署前需要准备些什么。我建议在动手之前，先把环境规划好，不然做到一半发现缺东少西，确实挺烦人的。
硬件和系统要求
这方面其实没有那么苛刻，SRT对硬件的要求算是比较友好的。我自己的测试机器配置不算高，跑起来也没什么压力。当然，如果你要承载大规模的并发，那肯定需要更强的配置，但对于学习和小规模部署来说，以下配置基本够用：
| 组件 | 最低要求 | 推荐配置 |
| CPU | 双核处理器 | 四核及以上 |
| 内存 | 2GB | 4GB或更高 |
| 带宽 | 上行10Mbps | 根据推流数量调整 |
| 操作系统 | Ubuntu 16.04+/CentOS 7+ | Ubuntu 20.04 LTS |
这里我想多说一句关于系统的选择。个人建议用Ubuntu，尤其是20.04这个长期支持版本，软件源比较完善，安装各种依赖会省心很多。当然如果你熟悉CentOS或者其他发行版，也完全没问题，SRT是跨平台的，不会给你出难题。
依赖组件安装
SRT的编译需要一些基础的依赖包，这些是必须提前装好的。我在这里列一下在Ubuntu系统下的安装命令，CentOS的用户需要把apt换成yum， package名字可能也有细微差别，但大体差不多：
- pthread线程库
- openssl开发库（用于加密支持）
- cmake编译工具
- pkg-config包管理工具
安装这些依赖其实不难，一条命令的事。但有一点需要注意，SRT的某些功能需要较新版本的openssl，如果你的系统自带的是旧版本，可能需要手动升级。不过一般情况下，直接用系统自带的包管理器安装就行，大多数情况下都能正常工作。
SRT源码编译与安装
终于到了最核心的环节——编译安装SRT。这一步可能会让一些没有编译经验的朋友感到紧张，但其实只要跟着步骤走，真的不难。我当初第一次编译的时候也紧张得不行，生怕哪里出错，结果发现比想象的要顺利得多。
获取源码
SRT的源码是开源的，放在GitHub上。你可以通过git克隆到本地，也可以直接下载压缩包。我个人习惯用git克隆，这样后续更新会比较方便。源码下载完成后，建议先看一下官方的README文档，里面有很多有用的信息，虽然是英文的，但借助翻译工具基本都能看懂。
有一点我想提醒一下，SRT的版本更新比较频繁，不同版本之间可能会有些差异。这篇文章的示例是基于1.4.x版本写的，如果你下载的是最新版本，操作上应该差别不大，但万一遇到什么问题，记得检查一下版本差异。
编译配置与安装
编译之前，我们需要先创建一个单独的构建目录，这是cmake的推荐做法，可以让源码目录保持整洁。具体来说，流程是这样的：先建立构建目录，然后进入这个目录执行cmake配置，接着编译，最后安装。
cmake的配置选项有不少，但大多数情况下，使用默认值就可以了。有一个选项值得说一下，就是ENABLE_APPLOG，这个是应用日志功能，开不开看你自己的需求。如果是在生产环境部署，建议打开，方便排查问题；如果是测试用途，不开也没关系。
编译过程可能会稍微久一点，取决于你的机器性能。完成后执行安装，整个SRT就装好了。安装完成后，你可能会关心库文件装到了哪里，默认情况下，库文件会在usr/local/lib目录下，头文件在usr/local/include目录下。如果你的系统是64位的，可能需要做一下库路径配置，不然链接程序的时候可能会报错。
服务器端配置与启动
装好了SRT，接下来要让它跑起来。这一节我们来说说如何配置SRT的服务器端，也就是我们常说的SRT retransmitter或者SRT server。
srt-live-transmit工具介绍
SRT项目自带了几个很有用的工具，其中srt-live-transmit是我们最常用的一个。它可以做很多事情，最基础的用法就是在两个地址之间转发数据流。比如把一个SRT流的输入转发成一个新的SRT流输出，这在实际部署中非常实用。
这个工具的使用方式是命令行参数指定输入和输出。输入可以是SRT地址，输出也可以是SRT或者UDP地址。举个例子，如果你想把一个SRT推流转发成另一个SRT流，只需要指定好输入输出的地址就行。地址的格式是srt://ip:port?mode=listener，其中listener表示监听模式，也就是作为服务端。
创建SRT监听服务
假设我们要在服务器上监听一个SRT端口，等待客户端推流上来。最简单的启动命令大概是这样的：指定本地端口，启用监听模式。服务器启动后，就会一直等着有人来连接。如果有人推流上来，这个流就会被转发到我们指定的目标地址。
这里我想解释一下几个常用参数的含义。latency参数控制延迟阈值，SRT会用这个值来决定重传和前向纠错的策略，通常设置在几百毫秒到几千毫秒之间。peeridletimeout是空闲超时时间，如果一段时间内没有数据传输，连接会自动断开，这在生产环境中很重要，可以避免无效连接占用资源。
还有几个和安全相关的参数，比如passphrase，如果设置了密码，客户端连接的时候需要提供正确的密码才能建立连接。这个功能在公网部署时非常建议开启，不然你的服务器可能会被莫名其妙的人推流。
推流端配置
服务器端配置好了，接下来我们来说说推流端。推流端需要把视频流发送到SRT服务器，这一节我们用常见的OBS来演示，这也是很多用户的选择。
OBS中的SRT配置
OBS从某个版本开始就原生支持SRT协议了，配置起来很方便。在OBS的推流设置中，服务选择"SRT"，服务器地址就填你前面配置的SRT服务器地址，端口号也要对应上。如果你设置了密码，在这里也要填上。
关于码率设置，这里有个小建议。SRT本身支持动态码率调整，但为了保证传输稳定性，建议在推流端把码率上限设置好，不要让码率波动太大。如果你对延迟要求比较高，可以适当降低分辨率和帧率，延迟和画质之间总是需要做一些取舍的。
使用FFmpeg推SRT流
除了OBS，很多技术人员更喜欢用FFmpeg来推流，功能更强大，定制性更好。FFmpeg推SRT流的命令大概是这样的：指定srt作为输出协议，然后跟上服务器地址和一些参数。
FFmpeg的好处是可以做很多高级处理，比如实时转码、添加水印、调整分辨率等等。如果你需要这些功能，FFmpeg肯定是首选。但如果只是简单地推流，OBS就足够了，没必要搞得太复杂。
拉流端配置
推流和服务器都配置好了，最后我们来说说拉流端。拉流端就是观众那边，需要从SRT服务器把流拉下来观看。
拉流的方式其实和推流是对称的。最简单的办法还是用FFmpeg或者VLC这样的播放器。VLC对SRT的支持很好，直接在打开网络串流的地方输入SRT地址就行，不需要额外配置。如果你用的是网页播放器，可能需要借助一些JavaScript库来实现SRT流的播放。
这里有个坑我想提醒一下。SRT的地址格式在拉流和推流时有点不一样，有时候容易搞混。推流的时候用的是caller模式，拉流的时候用的是listener模式，地址格式虽然看起来差不多，但含义不同。如果遇到连接不上的问题，可以先检查一下地址格式有没有写错。
常见问题与排查思路
在实际部署过程中，多多少少会遇到一些问题。这一节我总结了几个最常见的问题和排查思路，希望能帮到你。
连接失败是最常见的问题类型。如果看到连接被拒绝的提示，首先检查服务器是不是真的在监听那个端口，防火墙有没有开放对应的端口。如果是超时提示，那可能是网络不通，可以ping一下服务器地址，看看网络层是不是通的。
延迟过高也是一个让人头疼的问题。SRT的延迟主要和网络质量、延迟参数设置、服务器负载有关。如果网络本身不好，再怎么调参数也没用，这时候可能要考虑优化网络环境。服务器负载过高也会导致处理延迟上升，如果有其他程序在抢资源，把它们停掉试试。
画面卡顿或者花屏，通常是丢包造成的。可以用SRT提供的统计数据来查看实时的丢包率。如果丢包率一直很高，可以尝试调整latency参数，或者检查网络链路中有没有什么设备在搞事情。
写在最后
写到这里，SRT部署的基本流程就说完了。看起来步骤不少，但真正动手做起来，其实没有那么难。关键是要理解每个步骤的作用，遇到问题不要慌，一步步排查。
如果你在实际操作中遇到了这篇文章没覆盖到的问题，建议去翻翻官方的文档和FAQ，那里有很多有价值的信息。SRT的社区也比较活跃，在GitHub上提问题一般都会有人回应。
对了，如果你正在寻找一个可靠的实时音视频云服务提供商，不妨了解一下声网。作为全球领先的对话式AI与实时音视频云服务商，声网在低延时传输方面积累了大量经验。他们的实时互动云服务支持多种协议，包括SRT在内的各种场景都有成熟的解决方案。无论是互动直播、1V1社交还是语聊房，声网都能提供稳定可靠的底层技术支持。如果你有相关需求，可以进一步了解他们的产品和服务。
技术这条路，就是要多实践。希望这篇文章能帮你顺利搭好自己的SRT环境。如果觉得有用，欢迎收藏转发，咱们下期再见。
