低延迟直播的核心目标，是让观众端看到的画面与主播端发生的动作之间的时间差控制在可接受范围内，通常低于两秒才能满足互动类场景。在云服务器上利用RTMP协议与SRS（Simple RTMP Server）搭建推流服务，是目前性价比最高、可控性最强的方案之一。RTMP本身是基于TCP的流媒体协议，天生适合推流；而SRS是专为低延迟设计的中国开源流媒体服务器，支持RTMP、WebRTC、HLS等多种协议输出，配置灵活。
很多人误以为直播延迟高是因为带宽不够，其实绝大多数情况源于协议链路选择和缓冲参数配置不当。例如直接使用默认HLS切片，延迟往往超过十秒；而RTMP直推加SRS的RTMP转发，配合调小缓冲，就能轻松做到亚秒级。下面我们从云服务器准备开始，逐步说明完整搭建过程。
一、云服务器基础准备与网络环境配置
选择云服务器时，不必盲目追求高配。对于千人以内的低延迟直播，两核CPU、4G内存、按量计费的云主机通常足够。系统推荐使用Ubuntu 20.04或CentOS 7，这两类系统对SRS的依赖库支持最完善。需要特别注意的是，云服务器厂商的安全组必须手动放行1935（RTMP）、1985（SRS HTTP API）、8080（SRS内置控制台）以及WebRTC使用的UDP端口范围，否则推流会直接失败。
除了安全组，系统内部防火墙也要同步处理。以Ubuntu为例，执行 ufw allow 1935/tcp 等命令开放对应端口。另外，建议为云服务器绑定弹性公网IP，并在DNS侧做好A记录，方便主播端使用固定域名推流而非记忆IP。如果预算允许，选择大陆节点并备案域名，能进一步降低跨国链路的抖动，对低延迟有实质帮助。
磁盘方面无需大容量，但最好使用SSD系统盘，因为SRS在启动和加载配置时涉及少量随机读写，HDD在并发稍高时可能成为隐性瓶颈。完成上述步骤后，通过 ssh 登录服务器，更新系统源，即可进入下一阶段的软件部署。
二、SRS服务器编译安装与基础运行
SRS采用源码编译方式安装，这能保证我们启用所需的低延迟模块。首先从官方仓库获取代码：执行 git clone -b 4.0release https://github.com/ossrs/srs.git 然后进入 srs/trunk 目录。编译前需安装基础工具链，包括 gcc、make、libssl-dev 等，CentOS下对应包名为 openssl-devel。配置阶段使用 ./configure --with-ssl --with-hls 开启必要功能，再 make 即可，整个过程在两核机器上约三到五分钟。
编译完成后，启动命令为 ./objs/srs -c conf/srs.conf。此时SRS以默认配置运行，提供标准RTMP推流地址 rtmp://服务器IP/live/流名。我们可以用OBS或FFmpeg测试推流：ffmpeg -re -i 本地视频.mp4 -c copy -f flv rtmp://IP/live/test。若能通过VLC打开 rtmp://IP/live/test 看到画面，说明基础链路已通。
不过默认配置并未优化延迟，此时从推流到播放大概有三点五秒左右延迟，主要源于SRS的队列缓冲和RTMP的拥塞控制。我们需要修改配置文件，进入真正的低延迟调优环节。SRS的配置是纯文本格式，修改后重启进程生效，这对生产环境来说足够灵活。
三、RTMP与SRS低延迟核心参数详解
打开 conf/srs.conf，在 listen 1935 的默认块中，重点调整以下几个指令。首先是 queue_length，它控制每个连接的发布队列长度，默认值为0表示自动，低延迟场景建议显式设为较小值如30；其次是 reduce_sequence_header，设为 on 可减少头部重复发送。最重要的是在 vhost 中开启 min_latency on 和 tcp_nodelay on，前者让SRS优先转发最新帧，后者禁用Nagle算法，避免小包等待。
另一个关键点是 gop_cache，默认 on 会缓存一个关键帧组以便新观众秒开，但会增加延迟，低延迟互动直播应设为 off。同时，将 publish 下的 mr 即合并读关闭，设置 mw_latency 为0。以下为精简配置片段示例：
listen 1935;
max_connections 1000;
vhost __defaultVhost__ {
min_latency on;
tcp_nodelay on;
gop_cache off;
queue_length 30;
publish {
mr off;
mw_latency 0;
}
}
修改后重启SRS，再次用FFmpeg推流并用VLC播放，延迟通常降到八百毫秒到一点二秒。若想进一步压到五百毫秒内，可改用SRS的WebRTC输出，但RTMP推流端不变，仅播放端走RTC协议，这对主播上行设备要求更低。下面用表格对比不同配置下的实测表现。
| 配置模式 | 推流协议 | 播放协议 | 实测延迟 | 适用场景 |
|---|---|---|---|---|
| 默认SRS | RTMP | RTMP | 3500ms | 传统直播 |
| 低延迟调优 | RTMP | RTMP | 900ms | 电商互动 |
| WebRTC输出 | RTMP | WebRTC | 400ms | 秀场连麦 |
从表中可见，仅通过调整SRS参数，不需改动主播推流方式，就能获得接近三分之一的延迟下降。这对于绝大多数云服务器用户来说，是成本最低、风险最小的优化路径。实际部署时，还应监控云服务器的CPU软中断，避免网络栈处理成为新瓶颈。
四、常见问题排查与容量规划建议
搭建完成后，最常遇到的是推流成功但播放黑屏。这类问题九成是因为安全组未放行1935，或SRS进程监听在127.0.0.1而非0.0.0.0。检查办法是 netstat -anp | grep 1935，确认显示为 0.0.0.0:1935 才表示对外可接受连接。另外，若观众端位于严格NAT网络，RTMP TCP能穿透而WebRTC可能失败，此时应保留RTMP播放兼容。
容量方面，单台两核云服务器处理纯RTMP转发，每路流约占5% CPU，理论可带二十路并发推流、数百路拉流。若开启转码则CPU消耗陡增，低延迟场景应坚持转码放在主播端、服务器只做转发的原则。当业务增长，可使用SRS的集群模式，配置边缘节点，源站仍在中心云服务器，边缘用按量云主机弹性扩容。
最后提醒，直播内容若涉及公开传播，请确认云服务器所属主体已完成ICP备案与视听资质申请。技术搭建只是第一步，合规运营才能长期稳定。按照上述RTMP加SRS的组合，普通开发者完全可以在一个下午内拥有自己的低延迟直播推流服务。