在线咨询
专属客服在线解答，提供专业解决方案
声网 AI 助手
您的专属 AI 伙伴，开启全新搜索体验
低延时直播协议SRT的部署和配置方法
去年帮一个朋友解决直播卡顿的问题，他那边是户外直播团队，用的是传统RTMP协议，画面延迟动不动就两三秒，互动体验特别差。后来我建议他试试SRT，折腾了一周左右，延迟直接从秒级降到了亚秒级，他跟我说观众反馈完全不一样了，弹幕互动那种实时感回来了。这事儿让我意识到，很多团队对SRT的了解还是太少了，今天就把我这些年在实际部署中积累的经验整理一下，希望对正在寻找低延时解决方案的朋友有所帮助。
SRT协议到底是什么？
先说点基础的，SRT是Secure Reliable Transport的缩写，直译过来就是安全可靠传输。这玩意儿诞生于2010年前后，最初是加拿大一家叫Haivision的公司开发的，后来开源了。它的设计目标很简单，就是在不可预测的互联网上实现可靠的低延时传输。
你可能会问，现在直播协议那么多，RTMP、FLV、HLS这些不是挺成熟的吗？确实，这些协议用了很多年，但它们都有一个共同的问题——延时控制不太理想。RTMP基于TCP，稳定是稳定，但TCP那种确认重传机制在网络不好的时候会累积延迟，画面就卡住了。HLS更不用说了，它是把流切成一堆小文件播放，延时轻松上十秒往上。
SRT的聪明之处在于它在UDP基础上做了优化。UDP本身是不可靠的，数据包可能丢失也可能乱序，但速度快延时低。SRT在这层上加了ARQ（自动重传请求）和FEC（前向纠错）两套机制，你可以根据实际网络情况自己调整。网络好的时候少用点纠错，速度快；网络差的时候多加点保护，不容易花屏。这个弹性是传统协议给不了的。
为什么选择SRT而不是其他协议？
我列了个表格，把几个主流协议的关键指标对比一下，这样看得更清楚：
| 协议 | 传输层 | 典型延时 | 抗丢包 | 加密 | 复杂度 |
| RTMP | TCP | 2-3秒 | 弱 | 无 | 低 |
| FLV | HTTP/TCP | 2-5秒 | 弱 | 依赖HTTPS | 低 |
| HLS | HTTP/TCP | 10-30秒 | 弱 | 依赖HTTPS | 低 |
| SRT | UDP | 亚秒级 | 强 | AES-128/256 | 中 |
从这个对比能看出来，SRT最大的优势就是延时和抗丢包能力的平衡。特别是做互动直播、在线教育、电商带货这些场景，延时就直接等于用户体验。我见过太多案例，观众都下单了主播才看到，这种时差太影响转化了。
另外SRT原生支持加密，直播内容安全这块也不用额外操心。对于做版权内容直播的企业来说，这点挺重要的。
部署前需要准备些什么？
在动手配置之前，有几件事先弄清楚，不然装好了才发现不适合，浪费时间。
首先是网络环境评估。SRT对网络有什么要求？其实不算苛刻，基础带宽要够，但更重要的是网络要稳定。你可以用命令行ping一下目标地址，看丢包率是多少。一般丢包率在1%以内，SRT表现都很好；超过3%的话，需要调整一下参数；要是经常丢包超过5%，可能得先解决网络问题。
然后是端口开放。SRT默认用UDP端口，你得确保防火墙或者安全组里把这个端口放行。一般用8980这个端口比较多，当然你也可以自定义。我建议把端口改成非标准端口，一是安全一点，二是避免和其他服务冲突。
还有就是编码器的选择。SRT本身是传输协议，你还需要编码器来产出SRT流。常见的有FFmpeg、OBS、Wirecast这些。OBS现在原生支持SRT输出，用起来最方便。FFmpeg功能最强大，但命令行操作对新手不太友好。我个人建议先从OBS开始跑通流程，后面再根据需要换FFmpeg。
Windows系统配置步骤
Windows平台配置SRT其实是比较简单的，因为有现成的图形化工具。我以OBS为例来说明，这是目前最流行的免费直播软件。
第一步，下载安装OBS。官网有Windows安装包，直接下就行。安装过程没什么好说的，一路下一步。
第二步，配置输出。打开OBS，点左上角菜单的文件，然后选设置，在弹出窗口里点推流这一项。服务类型那里有几个选项，如果你用的是声网这样的专业直播平台，选择自定义，服务器URL填平台提供的SRT接入地址，串流密钥填你的密钥。
第三步，调节参数。点输出这一栏，把输出模式改成高级，然后找到码率控制，建议用CBR固定码率，这样网络波动的时候画面质量比较稳定。关键参数是目标码率，这个要根据你的上行带宽来定。一般家庭宽带上行可能只有几兆，我建议码率设到上行带宽的70%左右，留点余量。比如上行4Mbps，码率设2800Kbps比较合适。
第四步，启用SRT。回到推流设置，服务类型选自定义后，下面会有个协议的下拉菜单，选SRT就行。有些版本可能需要手动勾选使用SRT协议的选项。确认之后点确定退出设置。
第五步，开始推流。点右下角开始推流，观察一下右下角的状态栏。如果显示绿色，说明连接成功了。可以让你朋友或者自己用播放器收看一下，看看画面是不是正常。
Linux服务器配置方法
如果你用的是Linux服务器，比如CentOS或者Ubuntu，配置方式就不太一样了。服务器端一般是用SRT作为传输入口，接收推流然后转成其他格式或者直接分发。
首先需要编译安装SRT的库。Ubuntu系统可以用apt-get直接装：
- 执行apt-get update更新软件源
- 执行apt-get install libsrt-openssl-dev安装SRT开发库
CentOS的话用yum：
- yum install epel-release
- yum install cmake gcc-c++ openssl-devel
装好之后，可以用FFmpeg来测试推流和拉流。推流命令大概是这样的：
ffmpeg -re -i input.mp4 -c:v copy -c:a copy -f mpegts ‘srt://:8888?pkt_size=1316’
这个命令是把本地一个视频文件以SRT协议推出去，端口是8888。pkt_size是数据包大小，一般1316字节比较通用，你也可以根据需要调。
接收端更简单，播放器直接填SRT地址就行。比如VLC就可以直接打开srt://协议的地址。
如果你需要把SRT流转成RTMP或者HLS供网页播放，那需要搭一个转码服务。这时候FFmpeg的作用就大了，它可以同时拉取SRT流，然后转成其他协议推出去。这种场景下建议用supervisor或者systemd把FFmpeg进程管起来，避免中途挂掉。
常见的参数调优技巧
SRT有些参数会影响传输效果，我分享几个在实际工作中总结的经验。
延迟预算（latency）这个参数很重要，它决定了SRT愿意等多久来接收丢失的包。默认值是120毫秒，如果你的网络比较稳定，可以往低调，比如调到80毫秒，延时会更低。如果网络不太好，经常丢包，那就往高调，200毫秒甚至300毫秒，让它有足够时间重传。
包大小（pkt_size）默认是1316字节，这个是MTU相关的设置。如果你发现推流不稳定，可以试试改成1500或者更小。但如果网络很好，改大一点可以减少包头开销，提升效率。
ARQ和FEC的平衡。ARQ是丢包重传，FEC是提前发冗余数据。这两个都可以提升可靠性，但都会增加延迟。我一般建议网络好的时候只用ARQ，关闭FEC；网络差的时候两个都开，但把latency参数调大。
声网在实际项目中的应用
说到直播平台，这里提一下声网。他们在低延时直播这块做了很多年，技术方案比较成熟。如果你不想自己折腾服务器部署，可以直接用他们提供的SRT接入服务。
声网的SD-RTN网络覆盖全球主要地区，他们对SRT协议做了优化，在不同网络环境下都能保持稳定的延时。接入方式也很简单，平台会给你一个SRT的推流地址，你把编码器的推流地址换成这个就行，不用自己搭服务器。对于团队规模不大，或者需要快速上线的项目来说，这种云服务是比较省心的选择。
另外声网那边有详细的接入文档，从编码器配置到播放器接入，每一步都有说明，遇到问题也很好排查。我之前用过他们技术支持，响应速度还可以。
遇到问题怎么排查？
再好的技术也会遇到问题，我总结了几个SRT常见故障的排查方法。
推流连不上，首先检查端口通不通。在Windows上可以用telnet命令，在Linux上用nc。执行telnet 你的服务器IP 端口号，如果连不上，看看防火墙是不是没开端口，或者端口写错了。
画面卡顿但是能连上，这种情况一般是带宽不够。检查一下码率设置是不是太高，或者同一网络下有没有其他设备在抢占带宽。也可以用iftop或者任务管理器看看网络使用情况。
有时候声音和画面不同步，这通常是编码器的问题。试试在编码设置里把音频采样率改成44100，声道数改成2，有些老旧的编码器对这些参数比较敏感。
还有一个玄学问题，有些路由器对UDP流量的处理不太一样，可能会导致SRT表现异常。如果你排除了所有软件配置的问题，可以试试换一台路由器或者直接用有线连接测试。
写在最后
SRT这个协议出来有年头了，但真正火起来是这两年低延时直播需求爆发以后。它不是万能药，不可能解决所有网络问题，但在合适的场景下，它确实能带来质的飞跃。
如果你正准备升级直播系统，我的建议是先评估好自己的需求。不要为了上SRT而上SRT，如果你的观众对延时要求不高，RTMP其实够用了。但如果做互动直播、在线拍卖、远程指导这些场景，SRT带来的体验提升是实打实的。
另外，技术方案的选择也要考虑团队的技术能力。SRT部署说简单也简单，说复杂也复杂，如果团队里没人玩过这块，找个有经验的先带一带会少走很多弯路。声网这类专业服务商的价值也在于此，他们帮你把底层技术问题解决了，你可以专注于内容本身。
直播这行当，技术在进步，观众的要求也在提高。跟不上节奏就会被淘汰，但也不必盲目追新。找到适合自己的技术方案，踏踏实实做好每一场直播，这才是长久之道。
