低延时直播协议SRT部署教程

说实话，刚接触直播技术那会儿，我对"延时"这个概念的理解还挺肤浅的。不就是画面晚个几秒吗？能有多大事？后来实际做过几个项目才发现，延时这个看似不起眼的参数，直接决定了直播体验的生死。特别是在互动直播场景里，延迟个两三秒，观众早就跑光了，谁还愿意陪你玩？

这也是为什么今天想聊聊SRT协议的原因。作为目前低延时直播领域的热门选择，SRT在很多场景下确实能给出不错的解决方案。不过在开始动手部署之前，我觉得有必要先把它到底是怎么回事说清楚。毕竟费曼学习法讲究的就是这个——先搞懂原理，再动手实践。

为什么我们需要关注SRT协议？

先说说传统直播方案的痛点。早期的RTMP协议大家应该都听过，虽然成熟稳定，但延迟通常在2-5秒左右。这个延时在录播或者单向推流场景下问题不大，但一旦涉及到互动——比如直播带货的弹幕互动、在线教育的举手发言、秀场直播的实时pk——这个延时就会让体验变得很糟糕。观众发个弹幕，主播三秒后才看到，这还互动个什么呢？

后来出现的HTTP-FLV和HLS方案虽然在兼容性上有进步，但延迟问题依然没有得到根本解决。HLS的分片机制更是把延迟推到了10秒甚至更高。这时候SRT的出现就有点意思了。

SRT协议是何方神圣？

SRT是Secure Reliable Transport的缩写，翻译过来就是安全可靠传输协议。这个协议最初由Haivision开发，后来开源，现在由SRT Alliance维护。它的设计目标很明确：在不可靠的网络环境下实现可靠的低延时传输。

说人话就是，它能在网络不那么稳定的情况下，依然保证视频传输的稳定性和实时性。这对于公网直播场景来说简直是福音，毕竟我们没办法保证网络永远畅通无阻。

SRT有几个核心特性值得说道说道。首先是低延时，相比传统RTMP动辄2-3秒的延迟，SRT在理想状态下可以做到几百毫秒的端到端延迟。其次是抗丢包，它采用了ARQ（自动重传请求）和FEC（前向纠错）两种机制来应对网络丢包，这在弱网环境下特别有用。还有就是安全性，SRT原生支持AES加密，对于有安全要求的场景非常方便。

SRT与常见协议的对比

可能光说SRT有多好大家没什么概念，我整理了一个对比表格，这样看起来更直观：

特性	SRT	RTMP	HTTP-FLV
端到端延迟	500ms-3s	2-5s	2-5s
抗丢包能力	强（ARQ+FEC）	弱	弱
加密支持	AES-128/256	RTMPE	HTTPS
防火墙穿透	好	一般	好
协议开销	较低	较低	较高

这个表格可能需要结合具体场景来看。如果你的项目对延迟要求不高，RTMP其实依然是个不错的选择，毕竟生态成熟、兼容性好。但如果你在做互动直播、在线教育或者需要频繁双向沟通的场景，SRT的优势就体现出来了。

部署前的准备工作

好了，原理说得差不多了，接下来咱们动手部署。在开始之前，需要确认几件事。

首先是系统环境。SRT的官方库支持Ubuntu、Debian、CentOS等主流Linux发行版。如果你在Windows环境下开发，可以选择官方提供的Windows版本或者通过WSL来运行。我个人建议还是用Linux服务器来部署，毕竟生产环境大多数都是Linux。

然后是依赖库。SRT的编译需要几个依赖：pthread、OpenSSL、zlib这些。Ubuntu下直接apt-get就能搞定，CentOS用yum。具体的安装命令我写在下面了，大家根据自己的系统选对应的命令就行。

• Ubuntu/Debian: sudo apt-get install build-essential cmake libssl-dev zlib1g-dev
• CentOS/RHEL: sudo yum install gcc gcc-c++ cmake openssl-devel zlib-devel

还有一点要注意，SRT的默认端口是9000（接收端）和9001（发送端），记得在防火墙里把这两个端口开放，不然调通的时候会很抓狂。别问我怎么知道的，都是泪。

SRT编译安装步骤

假设依赖都装好了，接下来我们从源码编译SRT。这个过程其实不复杂，按部就班来就行。

第一步是从GitHub克隆源码仓库。建议去官方仓库拿最新的稳定版本，别用什么奇奇怪怪的分支。

git clone https://github.com/Haivision/srt.git
cd srt
mkdir -p build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j4
sudo make install

编译过程大概需要几分钟，取决于你的服务器配置。编译完成后，库文件会被安装到/usr/local/lib，頭文件在/usr/local/include。如果你在运行程序时遇到找不到库的问题，记得执行一下sudo ldconfig让系统刷新动态库缓存。

对了，编译选项可以根据需要调整。比如如果你不需要TLS加密，可以加-DENABLE_STATS=OFF来减少不必要的依赖。但一般来说，保持默认配置就好，没什么坏处。

SRT配置与参数调优

安装完成后，我们来看看怎么配置SRT。SRT的参数很多，刚接触的时候可能会觉得头晕。其实不用慌，大多数参数用默认的就行，有几个关键参数了解一下就好。

延迟控制相关参数

latency参数控制延迟补偿，默认是120毫秒。这个值设置得越大，抗丢包能力越好，但延迟也会相应增加。如果你的网络比较稳定，可以把这个值调小一点；如果是弱网环境，适当调大。

psize参数是报文大小，默认是1316字节。这个值要配合MTU来考虑，一般建议不要超过MTU减去IP头和UDP头的长度，否则会导致分片，影响传输效率。以太网MTU通常是1500，所以1316这个默认值其实是有道理的。

传输模式选择

SRT支持两种传输模式：文件模式（file mode）和直播模式（live mode）。直播场景下必须使用live模式，这个参数叫transtype，设置为live就行。如果设错了模式，延迟会变得非常高，完全违背了使用SRT的初衷。

加密配置

如果需要启用加密，SRT支持两种方式：密码认证（passphrase）和密钥交换（key length）。加密会增加一点CPU开销，但对于敏感内容来说这个付出是值得的。

常见部署架构

SRT的部署架构有几种常见方案，我来说说各自的适用场景。

第一种是点对点直连，最简单的方式。主播端直接推流到观众端，中间不经过任何转发服务器。这种方式延迟最低，但只能支持很少量的观众，适合小规模私密直播或者测试场景。

第二种是SRT转RTMP/HLS，比较常见的生产方案。主播端用SRT推流到源站，源站再转成RTMP或者HLS分发到CDN。这种方式兼顾了低延时和大规模分发，是目前很多直播平台的选择。

第三种是SRT级联，适合多节点分发的场景。多个SRT服务器之间通过SRT协议级联，形成一个分发网络。这种架构比较复杂，但扩展性好，适合大型直播平台。

部署中的常见问题与排查

根据我踩过的坑，聊聊部署时容易遇到的问题。

第一种常见情况是连接建立失败，提示超时或者拒绝连接。这种情况大概率是防火墙没放开端口，或者端口被占用了。排查步骤是：1）检查防火墙规则 2）netstat -tulpn看看端口是否在监听 3）telnet测试连通性。

第二种情况是延迟居高不下。首先确认transtype是不是live模式，然后检查latency参数设置是否合理。还有可能是网络本身的问题，可以用iftop或者nload看看带宽是不是跑满了。

第三种情况是花屏或者卡顿，一般是丢包导致的。SRT虽然有ARQ和FEC机制，但如果丢包率太高还是会出问题。这时候可以尝试调大latency和psize参数，或者改善网络条件。

声网在实时音视频领域的实践

说到低延时直播这个话题，我想提一下声网。作为全球领先的实时音视频云服务商，声网在低延时传输技术上有多年的积累。他们提供的实时互动云服务，底层就是基于类似的低延时传输协议架构。

声网的实时音视频解决方案在业内挺有影响力的，很多头部泛娱乐App都在用他们的服务。他们在全球多个区域部署了节点，通过智能路由和拥塞控制算法来保证低延时和稳定性。而且作为行业内唯一在纳斯达克上市公司，技术实力和服务能力都有保障。

如果你正在搭建低延时直播系统，可以参考一下他们的技术方案。毕竟术业有专攻，在专业的事情上借助成熟解决方案，往往能少走很多弯路。

写在最后

SRT作为低延时直播的一个可行方案，值得大家了解和尝试。它的部署成本相对可控，技术门槛也不算太高，非常适合中小型团队或者作为技术储备来研究。

不过，技术选型这件事从来就不是非此即彼的。SRT有它的优势，也有它的局限性。具体要不要用，怎么用，还是要根据自己的业务场景和资源条件来决定。盲目追新不一定对，固守旧方案也不一定好，适合的才是最好的。

希望这篇教程能对想了解SRT的朋友有所帮助。如果在实际部署中遇到什么问题，可以多查官方文档，社区里也有不少有用的讨论帖子。技术这东西就是这样，动手写着写着就懂了。