SRS流媒体服务器搭建与测试：RTMP、HTTP-FLV、HLS及WebRTC延迟对比

1. 项目背景与核心需求拆解

做直播、做视频会议、做监控大屏，几乎绕不开一件事：需要一个靠谱的流媒体服务器。几年前我在某公司做视频中台项目时，团队花了两周时间试用过市面上主流的开源流媒体方案，最终落地使用的是SRS（Simple Realtime Server）。这是一个基于C++编写的高性能开源流媒体服务器，单机可以支撑数万路并发拉流，同时原生支持RTMP、HLS、HTTP-FLV、WebRTC、SRT等多个协议，在国产开源项目里算是生态非常完整的一套解决方案。

这次我搭建SRS的核心目标有两个：一是验证它在内网环境下的推流和拉流能力，二是对比不同协议之间的延迟表现，顺便把之前踩过的坑沉淀成一套可供团队参考的搭建手册。标题里说的“搭建与测试”，本质上是两条线并行推进——一条是服务器的安装、配置、启停、日志排查，另一条是用FFmpeg推流、用播放器验证、用工具测延迟压并发。

先明确一个认知：做流媒体服务器选型，最忌讳一上来就追大而全的平台。SRS最舒服的使用场景是“中小规模直播和低延迟交互”。如果你只是做企业内部培训直播，高峰期几百人观看，或者做远程巡店的监控画面回传，SRS单机部署加一台普通物理机就足够用了。如果一上来就上集群、上K8s、上微服务，运维成本会直接吞掉业务收益。

还要提一个关键点：SRS的配置文件和Nginx风格很接近，核心是一个srs.conf文件，所有模块通过配置开启。这意味着你对Nginx的理解可以平滑迁移过来，同时它也意味着如果你不熟悉它的配置体系，光看文档会看得很晕。我会在后面的章节里把每一个关键配置的作用和参数来历讲清楚，尽量避免“照着抄但不知道在抄什么”的情况。

2. 环境准备与CentOS 7部署实操

2.1 服务器规划与系统检查

部署SRS之前，先把服务器环境搞清楚。我用的是一台4核8G内存、100M带宽的云服务器，操作系统是CentOS 7.9。如果你的服务器配置更低，比如2核4G，跑演示和做小范围并发测试也够用，但如果目标是压测上万路并发，建议至少8核16G起步。

先做几个基础检查。第一，确认CPU架构是x86_64，SRS官方对ARM架构也有支持，但编译依赖的库版本可能不一致，容易踩坑；第二，确认系统盘剩余空间最好超过5G，因为编译安装时会生成不少中间文件；第三，关掉防火墙或者放行1935、1985、8080这几个端口——1935是RTMP默认端口，1985是SRS的HTTP API端口，8080是HTTP-FLV和HLS的默认端口。

在服务器上执行以下命令完成基础环境和依赖安装：

yum update -y yum install -y gcc gcc-c++ make patch unzip flex autoconf git \ libtool gperf pkgconfig openssl-devel

这里有几个依赖要单独说明一下。gcc和g++是编译SRS源码的核心工具链，版本太老会导致部分C++11特性编译不过；openssl-devel是必须的，因为SRS的WebRTC功能和HTTPS API都需要用到OpenSSL库。如果你的系统是最小化安装，可能还需要装kernel-devel和vim，但这不影响SRS本身的编译。

2.2 源码下载与版本取舍

SRS的发布版本很讲究。官方长期维护的分支是4.0和5.0，5.0是目前的主线版本，WebRTC能力最完整，接口也更规范。我这次选择的是SRS 5.0的最新release版本，原因是它把HTTP-FLV、HLS、WebRTC这几个核心协议的配置做了统一，一个配置文件里可以同时开多种协议，不需要像4.0那样额外加载复杂模块。

下载源码的命令：

git clone -b develop https://gitee.com/ossrs/srs.git cd srs/trunk

我的建议是直接用Gitee镜像，GitHub在国内拉取时的稳定性不可控——尤其是当你要编译的机器在办公网环境下时，一个连接超时就能浪费掉半小时。

切到5.0分支：

git checkout v5.0_r0

然后进行编译配置和构建。SRS的configure脚本提供了一系列参数，最常用的组合是：

./configure --full make -j4

这里解释一下--full的含义：它会编译SRS所有模块，包括WebRTC、SRT、HLS、DVR、转码（FFmpeg转码）等。如果只想编译核心播放推流功能，可以不加--full，但为了测试的完整性，我建议直接全量编译。-j4是并行编译参数，与服务器CPU核数对应，4核就填4，8核就填8，不要盲目填很大的数字，否则编译过程中内存可能被占满导致OOM。

编译过程视机器性能不同，通常在10到30分钟之间。编译完成后，会在trunk目录下生成objs/srs这个二进制文件，这就是SRS服务器本体。

2.3 默认配置启动与端口检查

SRS提供了一个默认的配置文件conf/srs.conf，里面默认开启了RTMP和HTTP API。启动之前先验证一下配置文件语法：

./objs/srs -c conf/srs.conf -t

-t参数表示只做配置检查，不真正启动。这是Nginx风格的参数设计，如果你用过Nginx，这里会感觉很熟悉。检查通过后，正式启动：

./objs/srs -c conf/srs.conf

启动后，用ss -lntp检查端口监听情况：

ss -lntp | grep -E '1935|1985|8080'

正常情况下，你应该看到1935和1985端口被SRS进程监听。8080端口此时不会出现，因为默认配置里HTTP服务端口是1985，而HTTP-FLV服务需要额外配置。

此时SRS已经可以接受RTMP推流了，但为了更好地测试多协议播放，我们需要把配置扩展一下。这就是整个搭建过程中最核心的动作：改配置、加模块、重启。

2.4 扩展配置：HTTP-FLV与HLS同时开启

SRS 5.0的配置结构比较清晰，核心是vhost和application两层。

我需要修改的srs.conf大致如下：

listen 1935; max_connections 1000; daemon on; srs_log_tank console; http_api { enabled on; listen 1985; } http_server { enabled on; listen 8080; dir ./objs/nginx/html; } vhost __defaultVhost__ { http_remux { enabled on; mount [vhost]/[app]/[stream].flv; hstrs on; } hls { enabled on; hls_path ./objs/nginx/html; hls_fragment 2; hls_window 10; } }

这个配置文件做了以下几件事：

第一，http_server块开启了8080端口的HTTP文件服务，主要是为了配合HLS播放；第二，http_remux块开启了RTMP流转HTTP-FLV的功能，这样播放端可以直接通过HTTP拉流，规避了RTMP在浏览器里无法直接播放的问题；第三，hls块开启了HLS切片输出，切片时长设为2秒，窗口设10秒。

这里重点说一下hls_fragment参数。它控制的是每个TS切片文件的时间长度。设得越小，直播延迟越低，但对磁盘IO和CPU的开销也越大。如果设成1秒，播放体验虽然好，但在磁盘性能一般的机器上可能会频繁出现TS文件写不完的情况。2秒是延迟和性能的平衡点。

改完配置后，无需停止SRS，直接执行：

killall -1 srs

SRS支持热重启，它会重新读取配置文件并平滑拉起新进程，不会中断正在进行的推流。这个特性非常实用，我通常在调整配置时不会停服务，只有改端口或改vhost名时才做完全重启。

3. 推流链路搭建：从RTMP到FFmpeg实测

3.1 FFmpeg安装与推流参数解析

测试推流，我用的是FFmpeg。如果你的服务器上没有装FFmpeg，可以快速安装：

yum install -y epel-release yum install -y ffmpeg

CentOS官方源里没有FFmpeg，需要依赖EPEL和RPMFusion源。如果安装不上，可以直接从FFmpeg官网下载静态编译包，解压到/usr/local/ffmpeg下，然后做软链：

ln -s /usr/local/ffmpeg/bin/ffmpeg /usr/bin/ffmpeg

这里有一个经验：静态编译包比源码编译安装省事得多，不需要处理一堆依赖库的版本问题。尤其是你只是拿FFmpeg当推流工具用的时候，源码编译纯属浪费时间。

接下来准备测试视频源。如果不方便下载测试视频，可以直接用FFmpeg的testsrc视频源：

ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=30 \ -f lavfi -i sine=frequency=440:sample_rate=44100 \ -vcodec libx264 -preset veryfast -tune zerolatency \ -acodec aac -f flv rtmp://127.0.0.1:1935/live/test

这条命令拆开来看比较清楚：

-re表示按视频原始帧率读取并推流，不加这个参数FFmpeg会以最快的速度把数据推完，这在直播场景下没有意义；testsrc是FFmpeg内置的测试画面源，会生成一个带滚动条和测试颜色的画面；sine是音频源，生成440Hz的测试音。

-tune zerolatency非常关键，它告诉libx264编码器不要为了追求画质而积累帧，而是以降低单帧编码延迟为最高优先级。实测开启zerolatency后，推流端到播放端的延迟可以降低约300到500毫秒。这在测试过程中是一个重要的体验因素。

推流命令执行后，终端会持续输出编码进度，说明RTMP流已经成功推入SRS。你也可以通过SRS的HTTP API验证当前活跃流：

curl http://127.0.0.1:1985/api/v1/streams/

返回的JSON里会包含stream名称、来源IP、视频编码、音频编码等信息。

3.2 拉流验证与播放器选择

推流成功以后，最直观的验证方式是通过播放器拉流。桌面端推荐使用VLC，打开网络串流，输入rtmp://服务器IP:1935/live/test，如果能看到画面，说明RTMP链路已经通了。

但RTMP播放器只适合桌面端验证。做Web端测试时，更推荐HTTP-FLV协议配合flv.js播放器。SRS官方提供的demo页面就是这个组合。

我测试时用的方式是直接在项目目录下起一个简单的Web服务，页面里用flv.js拉流：

<script src="https://cdn.jsdelivr.net/npm/flv.js/dist/flv.min.js"></script> <video id="video" controls muted></video> <script> if (flvjs.isSupported()) { var video = document.getElementById('video'); var flvPlayer = flvjs.createPlayer({ type: 'flv', url: 'http://服务器IP:8080/live/test.flv' }); flvPlayer.attachMediaElement(video); flvPlayer.load(); flvPlayer.play(); } </script>

注意一个细节：HTTP-FLV的URL和RTMP的URL结构是统一的，都是应用名/流名这种模式，这是SRShttp_remux配置中mount [vhost]/[app]/[stream].flv的含义。默认vhost下，这个URL就是/live/test.flv。

实测过程中，我遇到过一个很容易让人困惑的问题：HTTP-FLV播放显示404。排查之后发现是SRS的http_remux配置写在了vhost层级，但http_server配置没有开启对应端口。确认http_server里的listen和dir两个参数都正确后，播放就正常了。

3.3 RTMP与HTTP-FLV的延迟实测

延迟测试是整个搭建过程里最有意思的部分。我用的是秒表法：推流端播放一个计时器画面，播放端截屏对比时间差。

在同一台服务器、同一个网络环境下，RTMP播放延迟大约在1到2秒，HTTP-FLV延迟大约在0.5到1.5秒。HTTP-FLV之所以更低，是因为RTMP基于TCP长连接，播放器需要经过多次握手后才能开始拉流，同时RTMP的协议头更大，数据冗余更多。

不过这里要泼一盆冷水：HTTP-FLV虽然延迟低，但它是通过长连接推流的，对播放器的网络稳定性要求高，一旦网络抖动，客户端会直接黑屏。所以HTTP-FLV更适合局域网或者网络质量可控的场景，公网环境下建议优先考虑HLS。

3.4 公网拉流与防火墙放行

如果你的SRS部署在云服务器上，公网拉流测试是绕不开的一步。云服务器除了本机的iptables之外，还有一个安全组的概念。很多新手只放行了服务器的防火墙端口，却忘了安全组，导致拉流失败。

放行规则是这样的：TCP端口1935用于RTMP协议，TCP端口8080用于HTTP-FLV和HLS，TCP端口1985用于API请求。放行以后，建议用公网IP在本地电脑上测试一下端口是否通了：

telnet 你的服务器IP 8080

如果端口通了，再用播放器拉流，通常问题就解决了。如果端口不通，先查云控制台的安全组，再查本机firewalld，最后查SRS进程是否真的在监听。

4. HLS配置与低延迟场景测试

4.1 HLS切片机制详解

HLS（HTTP Live Streaming）是苹果公司提出的直播协议，它的工作原理是把连续的视频流切成一段一段的小文件（TS文件），客户端通过一个m3u8索引文件按顺序拉取这些TS文件进行播放。

SRS的HLS模块配置在前面已经贴过了：

hls { enabled on; hls_path ./objs/nginx/html; hls_fragment 2; hls_window 10; }

hls_path指定切片文件的输出目录，这个目录必须和http_server的dir指定目录一致，否则客户端无法通过HTTP访问到TS文件。

hls_fragment是单个TS文件的时间长度，单位是秒。这个参数直接决定了HLS播放的延迟上限。比如你对直播延迟要求不高，只是做课程回放，那hls_fragment设5到10秒都可以；如果你要做的是接近实时的互动直播，那需要设到1到2秒。

hls_window是播放窗口的总长度，它决定了客户端可以往后拖动多远的时间。10秒意味着切片列表里最多保留最近10秒的索引，超过这个时间范围的TS文件会被自动清理。

开启HLS后，推流端推一个流，SRS会自动在hls_path目录下生成一个以流名命名的子目录，里面放着m3u8文件和一组TS切片。

用VLC打开http://服务器IP:8080/live/test.m3u8，就可以看到HLS播放画面。

4.2 各协议延迟横向对比测试

我把RTMP、HTTP-FLV、HLS三种协议放在同一台机器上做了对比测试，测试条件是相同的视频源、相同的网络环境，结果如下：

• RTMP延迟约为1.8秒，播放稳定性一般，受网络抖动影响明显。浏览器端无法直接播放，必须借助Flash插件或扩展程序。
• HTTP-FLV延迟约为0.9秒，播放稳定性较好，浏览器可以通过flv.js播放，但高并发场景下需要合理设置缓存时间。
• HLS延迟约为4到8秒，播放稳定性最好，天然适配浏览器和移动端，但对实时性要求高的场景不太合适。

值得说明的是，SRS 5.0还支持WebRTC播放，延迟可以做到300毫秒以内，但WebRTC的部署复杂度会明显高于前三种协议。如果你做的是在线课堂或视频会议，WebRTC才是最佳选择；如果是监控回看或直播点播，HLS和HTTP-FLV就足够应对了。

4.3 HLS播放黑屏问题的排查

测试HLS时最容易遇到的问题是播放画面黑屏，但m3u8索引文件能正常拉取。

我遇到过一种典型情况：TS切片文件和m3u8文件生成正常，但TS文件内容全部是花屏或黑屏。这个问题的根源在推流端，FFmpeg推流时如果视频编码参数设置不合理，比如用了不适合直播的profile、分辨率与切片大小不匹配，就会导致播放端解码异常。

解决方法是推流时在FFmpeg命令里明确指定编码参数：

ffmpeg -re -i input.mp4 -c:v libx264 -profile:v baseline -level 3.0 \ -pix_fmt yuv420p -c:a aac -f flv rtmp://服务器IP:1935/live/test

-profile:v baseline和-pix_fmt yuv420p是H5播放器兼容性的关键。baseline profile是H5视频播放的最小公因子，绝大多数浏览器和播放器都能解码；yuv420p色度采样格式可以避免部分播放器对高规格色度采样的兼容问题。

还有一种黑屏情况是SRS开启了HLS加密（hls_enc）但播放器不支持解密。如果不需要防盗录，建议不开hls_enc，或者只对公网生产环境开启。

4.4 实际生产中的HLS配置经验

在实际生产项目中，我通常不会让HLS切片直接暴露在公网。更稳妥的做法是让SRS只负责切片写入本地目录，然后用Nginx做静态文件服务，再配合CDN分发。SRS的HTTP文件服务适合内网测试，但公网场景下无论是性能还是安全性都差一些。

另外，HLS切片写入磁盘时，要留意磁盘空间。hls_window虽然设置了10秒窗口，但SRS默认不会立即删除过期TS文件，只有等到切片索引更新时才会异步清理。在长时间直播场景下，磁盘可能被无用的TS文件占满。解决办法是定期用crontab清理超过N小时未修改的TS文件：

find /path/to/hls -name "*.ts" -mmin +60 -delete

这个命令是安全的，因为长期未被更新的TS文件一定不在m3u8索引列表中。

5. WebRTC低延迟直播实测与配置

5.1 为什么要上WebRTC

做互动直播时，HTTP-FLV和HLS的延迟就力不从心了。在线答题、连麦教学、远程手术示教这类场景，哪怕1秒延迟都导致体验断层。WebRTC基于UDP传输，天生具备低延迟、弱网对抗能力强的特点。

SRS 5.0的WebRTC实现走的是标准协议栈，支持推流（WHIP）和拉流（WHEP）。这意味着你不需要在客户端集成SDK，只要有一个支持WebRTC的浏览器（Chrome、Firefox、Edge），就能直接播放WebRTC流。

5.2 WebRTC配置开启

在srs.conf中，WebRTC的配置如下：

rtc_server { enabled on; listen 8000; candidate $CANDIDATE; } rtc_api { enabled on; listen 1989; }

这里的配置需要特别解释一下：

listen 8000是WebRTC的媒体端口，使用UDP协议。candidate是SRS向客户端通告的ICE候选地址，在公网环境下，必须设置为服务器的公网IP或域名。如果不设置，SRS默认检测到的内网IP会让客户端无法建立连接。

rtc_api是WebRTC的信令API服务，监听1989端口。SRS实现的是WHIP/WHEP协议，客户端通过HTTP请求这个API来完成推拉流的信令协商。

如果服务器部署在云上，需要放行UDP 8000端口和TCP 1989端口。很多人只放TCP端口忘了UDP端口，导致WebRTC一直处于connecting状态。

启动SRS后，可以用官方提供的WHIP推流工具测试：

ffmpeg -re -f lavfi -i testsrc=size=640x480:rate=30 \ -vcodec libx264 -f mpegts -c:v libx264 \ -c:v libx264 -preset ultrafast -tune zerolatency \ -f mpegts - | ffmpeg -f mpegts -i - \ -c:v copy -f mpegts - | ./objs/ffmpeg/ffmpeg -f mpegts -i - \ -c:v copy -f mpegts - | ./objs/ffmpeg/ffmpeg -f mpegts -i - \ -c:v copy -f mpegts -

这条命令比较复杂。实测更直接的方式是使用SRS官方自带的WebRTC推流测试页，打开HTTP服务后访问http://服务器IP:8080/players/rtc_player.html，在页面上填入推流地址即可。

5.3 端到端拉流验证

用Chrome打开SRS提供的rtc_player.html页面，选择WebRTC播放模式，输入流地址后点击播放。如果一切正常，播放延迟实测在300到500毫秒之间。

这里有一个WebRTC的坑：SRS默认开启的ICE候选是自动检测的，如果你有多块网卡（比如云服务器有内网IP和公网IP），SRS可能会通告内网IP给公网客户端，导致连接失败。正确的做法是在配置文件中手动指定候选IP：

candidate 你的公网IP:8000

注意这里不是简单的IP地址，需要带上端口号。如果你用的是域名，也支持域名形式：

candidate 你的域名:8000

还有一种常见问题是WebRTC的UDP端口不通。验证方式是在本地执行：

nc -vuz 你的服务器IP 8000

如果UDP端口不通，先检查云安全组是否放行了UDP协议，再检查服务器上是否有程序拦截了UDP包。

6. 常见问题排查清单与避坑指南

我把这次搭建过程中遇到的典型问题整理成了一张速查表。这些问题在SRS的使用中非常普遍，提前了解可以有效节省排查时间：

6.1 推流失败的几种典型场景

推流失败最直接的表现为FFmpeg终端输出连接被拒绝（Connection refused）。这种情况90%是端口没通，而不是SRS进程没启动。先用ss -lntp确认SRS监听了1935端口，再用telnet从本机连一次：

telnet 127.0.0.1 1935

如果本机通、公网不通，那就是防火墙或安全组的配置问题。

另一种常见情况是推流过程中断。表现为FFmpeg推流一会儿后报错退出。这类问题一般出在编码参数上。比如推流时-re参数缺失，FFmpeg以最快的速度推送编码数据，SRS接收端处理不过来就会断流；又比如推流码率设置过高，超出了网络带宽或SRS的max_connections限制。

6.2 播放卡顿的排查思路

播放卡顿的诱因有几个：一是推流端带宽不足，导致发送端丢包；二是服务器带宽不足，导致客户端拉流速率被限制；三是播放器的缓冲设置不合理。

排查时先看SRS的日志输出。SRS的日志里会记录每个连接的平均速率、丢包率、客户端IP等信息。如果日志显示某个客户端连接的平均码率远低于推流码率，基本可以判断是下行带宽瓶颈。

还有一种隐蔽的问题：播放器的缓冲设置。VLC播放RTMP流时默认的缓存时间是300毫秒，如果网络抖动较大，可以提高缓存时间到1000毫秒：

vlc --network-caching=1000 rtmp://服务器IP:1935/live/test

6.3 SRS日志分析与调优技巧

日志是排查问题的第一手段。SRS的默认日志在控制台或./objs/srs.log中。日志级别通过srs_log_level控制，生产环境通常设为warn，排查问题时设为trace可以看到更详细的信息。

在排查WebRTC问题时，一个比较实用的日志关键字是ICE和SDP。当SRS生成SDP信息时，会打印candidate列表，检查这个列表里是否有正确的公网IP，基本能定位大部分WebRTC连接问题。

调优方面，max_connections参数限制的是最大并发连接数。默认值是1000，如果你的服务器内存足够，可以提高到5000甚至10000。但要注意，高并发下SRS的日志输出会非常密集，建议同时开启daemon后台运行模式，并把日志输出到文件，避免控制台IO成为性能瓶颈。

7. 集群化扩展与生产部署建议

7.1 单机到集群的演进路径

SRS单机部署的极限取决于业务场景。纯HTTP-FLV拉流场景，一台8核16G的服务器可以支撑约2000路并发观看；如果同时开启WebRTC，因为UDP和TCP的处理复杂度不同，并发上限会下降一些。

当你需要支撑更大的业务量时，最平滑的演进路径是：先用SRS的origin模式部署源站，再用多个SRS实例做edge边缘节点。边缘节点负责对接用户播放请求，源站负责对接推流端，流数据通过源站转边缘，边缘节点可以横向扩容。

在配置层面，边缘节点和源站的配置差异主要在于vhost下的mode字段：

# 源站配置 vhost __defaultVhost__ { mode origin; } # 边缘配置 vhost __defaultVhost__ { mode edge; origin 源站IP; }

7.2 转发与回源策略

边缘节点模式下的回源策略有几个参数需要关心：reuse参数控制是否复用源站连接，prefetch参数控制是否在客户端请求前提前拉取流。开启prefetch可以显著降低播放首屏时间，因为它让边缘节点在源站有流时第一时间缓存了流数据。

生产环境我还有一个经验：不要把边缘节点和源站部署在同一个机房里。边缘节点应该更靠近用户侧，源站则放在中心机房，这样能有效利用边缘节点的带宽，同时降低源站的访问压力。

7.3 配置管理与统一更新

集群化部署的核心问题是配置同步。SRS没有内建配置中心，所以我在生产环境里用的方案是Git仓库维护配置模板 + 自动化脚本分发。每次修改配置后，先在一台测试机验证，再批量推送到所有边缘节点。

需要注意的是，SRS的配置文件修改后需要重启进程才能生效。如果边缘节点数量较多，重启会中断正在播放的流，所以建议在低峰期操作，或者采用灰度发布方式，逐台重启。

7.4 安全加固建议

流媒体服务器的安全容易被忽视。SRS默认没有任何鉴权机制，任何人都可以向服务器推流或拉流，这在公网环境下是有风险的。

最基础的安全手段是开启SRS的HTTP回调鉴权。在vhost下配置：

http_hooks { enabled on; on_publish http://鉴权服务地址/api/auth_publish; on_play http://鉴权服务地址/api/auth_play; }

每次有客户端推流或拉流时，SRS会向你的鉴权服务发送一个HTTP请求，鉴权服务返回0表示允许，返回非0表示拒绝。这种方案的好处是和控制台、用户体系打通，实现真正的业务级安全控制。

如果没有自建鉴权服务，也可以用SRS内置的token防盗链机制。在vhost下开启play_token后，播放请求的URL里必须带上正确的token才能播放。

8. 个人实践心得与后续动作

SRS这套流媒体服务器的搭建测试，前后耗时大约两天。头一天在编译和配置上花的时间比较多，第二天基本就在做协议验证和延迟对比。整体下来，SRS的文档质量在开源项目里是相当高的，尤其是5.0版本，每个配置项都有详细说明和示例。

我在实际使用中比较想强调的一点是：不要把所有协议一次性全部开启。日常测试可以全开，但生产环境最好按需开启，每少一个协议，就少一分暴露面，也多一分性能余量。比如你做的是教育录播平台，HLS就足够了，因为实时性要求不高，还可以利用CDN缓存；如果你做的是远程大屏监控，HTTP-FLV会更合适，延迟低、浏览器兼容好；如果是视频会议，那就主推WebRTC。

最后分享一个在排查问题时很有用的习惯：用SRS的HTTP API实时观察流状态。生产环境遇到推流异常、观众黑屏的投诉时，先打开http://服务器IP:1985/api/v1/streams/，确认流是否存在、来源IP是否异常、视频编码参数是否合规，很多问题一眼就能定位。这个动作比翻日志高效得多，建议各位上手动手搭一套SRS，把推流、播放、延迟对比完整走一遍，踩过坑之后你会对这套系统的行为方式有很清楚的认知。