SRS流媒体服务器安装完成后，你会得到一个默认监听1935端口（RTMP）、1985端口（HTTP API）和8080端口（HTTP服务）的轻量进程，通过浏览器打开控制台页面、用ffmpeg推一条测试流并成功播放，就能确认整套环境已经跑通。
SRS流媒体服务器安装后怎么验证安装成功了
刚装完SRS,最关心的就是它到底跑起来没有，验证方法其实就三步：看进程、看端口、推流测试，整个过程用不了五分钟，但能彻底排除环境层面的隐藏问题。
第一步：检查进程和端口是否正常监听
SRS安装完成后,默认的安装目录是/usr/local/srs（源码编译方式）或/opt/srs（部分脚本安装方式），进目录执行：
./objs/srs -c conf/srs.conf
启动后终端会停留在前台运行状态,日志里会打印类似listen on tcp://0.0.0.0:1935、tcp://0.0.0.0:1985、tcp://0.0.0.0:8080的监听信息，看到这三行，说明核心服务已经起来了。
再开一个新终端窗口验证：
ps -ef | grep srs netstat -tlnp | grep -E '1935|1985|8080'
如果三个端口都在LISTEN状态,进程也没挂，安装这一步就算真正完成了，很多新手在这一步发现只有1935能监听到，多半是配置文件被改动过，或者上次残留的进程占用了1985和8080，先杀掉旧进程再重启即可。
第二步：访问内置控制台和API接口
SRS自带一个极简的Web控制台,默认绑在8080端口，直接用浏览器打开：
http://你的服务器IP:8080/console/能看到版本号、运行时长、当前连接数这几个核心指标，如果页面打不开，先确认安全组和服务器防火墙有没有放行8080端口，云服务器用户尤其容易忽略安全组规则。
再测试一下HTTP API接口，SRS的API监听在1985端口，用curl请求版本信息：
curl http://127.0.0.1:1985/api/v1/versions
返回一段JSON格式的版本信息,就说明API层没问题，控制台和API都通，意味着SRS的管理能力已经在线，后续配置修改、状态监控都有地方可看了。
安装完成后SRS的目录结构和默认配置
SRS不装完就完事了,你得知道东西放哪、改哪个文件，它的目录结构非常规整，一共就几个关键目录。
核心目录各自干什么用
objs/：SRS编译完成后的二进制文件objs/srs就在这个目录，是启动SRS的唯一可执行文件conf/：所有配置文件的家，默认的conf/srs.conf就是启动时加载的主配置src/：源码目录，二次开发才需要动，普通使用不需要碰objs/nginx/：SRS自带了一个裁剪过的Nginx，用于切片和临时文件服务，不用额外装Web服务器
默认配置里藏着哪些关键参数
直接打开conf/srs.conf看，核心就几行：
listen 1935
max_connections 1000
srs_log_tank console
http_api {
enabled on;
listen 1985;
}
http_server {
enabled on;
listen 8080;
dir ./objs/nginx/html;
}这里解释一下：1935是RTMP入口，推流和拉流都走它；1985是HTTP API，用来查询状态、踢连接、做统计；8080是HTTP服务，提供控制台页面和HTTP-FLV、HLS的播放地址，这套默认配置已经能跑通完整的直播链路，不需要改任何东西就能直接推流。
SRS流媒体服务器和Nginx-RTMP模块对比，直播场景选哪个
很多人安装SRS之前都会纠结：Nginx加个RTMP模块不也能推流吗，为什么非要装个SRS？这个问题的答案，直接决定了你的直播系统能走多远。
两者在协议支持和维护成本上差别很大
| 对比维度 | SRS流媒体服务器 | Nginx-RTMP模块 |
|---|---|---|
| WebRTC支持 | 原生支持，音视频通话可直接落地 | 不支持，需要额外搭Janus或MediaSoup |
| HTTP-FLV | 内置支持，配置一行开启 | 需要自己写Nginx配置转发 |
| HLS切片 | 内置切片器，输出m3u8和ts | 需借助ffmpeg转码切片 |
| SRT协议 | 原生支持，弱网推流表现优秀 | 不支持 |
| 配置方式 | 独立配置语法，只服务流媒体业务 | 在Nginx配置里嵌套，业务流和静态资源混在一起 |
| 运维成本 | 单进程独立管理，日志清晰 | 依赖Nginx整体生命周期 |
内行看门道,最大的差距在WebRTC和SRT这两个协议上，如果只做传统的RTMP拉流到手机播放，Nginx-RTMP模块确实够用；但只要涉及低延迟直播、连麦互动、弱网推流，SRS几乎是不用犹豫的选择。
从实际场景看选型
一个标准的直播项目,通常要同时支持RTMP推流、HTTP-FLV播放、HLS回看，偶尔还要开WebRTC连麦，SRS一个进程全搞定，而Nginx方案得组合三四个组件才能拼出同样的能力。
再考虑并发承载,SRS的单进程IO模型在这类长连接场景下表现更稳，业内专家指出，在相同服务器配置下，SRS处理RTMP推流和HTTP-FLV拉流的并发连接数，比Nginx加RTMP模块的组合要高出不少，尤其在千级并发以上的规模下差距更明显。
SRS流媒体服务器云服务器配置要求高吗？按场景选型就行
说实话,SRS对服务器配置的胃口没有想象中大，它本身是C++写成的高效进程，不转码、不切片的情况下资源占用很低，真正吃配置的是转码和拉流带宽这两个环节。
按场景推荐配置
- 个人测试或者公司内部培训直播：2核4G的云服务器完全够用，带宽5M起步，能承载几十路低码率观看
- 中型企业对外直播,几百人同时观看：4核8G，带宽按观看人数估算，每路720p拉流占用大概1-1.5M带宽，自己乘一下就知道需要多少
- 大型活动直播,并发几千上万：8核16G以上，并且一定要走CDN分发，让SRS只接推流和源站，不要直接面对海量播放请求
服务器地域选择会影响实际体验
服务器的地域也很有讲究,直播推流和播放都是实时链路，地域选得太远，跨网延迟和丢包率都会明显上升，选择云服务器地域时，应该遵循一个原则：离你的推流端和大部分观看端最近的地方，比如主要用户都在华东，就选上海或杭州的可用区；如果业务同时覆盖华北和华南，宁可想办法做多地域分发，也别让华南用户跨越大半个中国来拉流。
价格方面,SRS本身是开源软件，不产生授权费，服务器成本就是云主机本身的费用，按目前主流云厂商的定价，一台2核4G的入门云服务器年付大概在几百元区间，测试环境用按量付费更划算。
安装完成后最容易踩的几个坑
环境装好了,配置也理解了，但推流测试时总会冒出各种幺蛾子，把几个高频问题提前讲清楚，能省下大量排查时间。
防火墙和安全组的联动检查
云服务器上SRS装了以后,本机测试一切正常，但手机和外部电脑连不上，绝大多数情况是安全组没放行，简米云、酷番云、华为云的控制台里都要单独配置安全组规则，放行TCP 1935、1985、8080这三个端口，本地防火墙也别忽略，CentOS执行firewall-cmd --permanent --add-port=1935/tcp并重载规则，Ubuntu则检查ufw状态。
推流地址总写错
SRS推流地址的格式是rtmp://服务器IP/live/流名称，其中live是默认的application名称，流名称可以随便起但不能包含中文字符和空格。
rtmp://112.10.22.33/live/room1用ffmpeg推流时写成：
ffmpeg -re -i test.flv -c copy -f flv rtmp://112.10.22.33/live/room1
拉流播放则用同样的地址,VLC和ffplay都能直接打开，如果要走HTTP-FLV，地址变成http://112.10.22.33:8080/live/room1.flv。
推流闪断和延迟忽高忽低
推流几秒后断开,先看日志里有没有connection closed之类的提示，大概率是服务器带宽打满，或者客户端的码率设置超过了max_connections阈值，延迟忽高忽低则要检查网络链路，推流端到服务器之间的RTT如果超过100ms，SRT协议可以缓解这个问题，其他协议下只能尽量压缩转发链路。
SRS流媒体服务器安装完成后的常见问题
SRS启动后没有任何日志输出，怎么回事？
检查启动命令是否加了-c参数指定配置文件，同时看当前用户对objs/目录有没有写权限，SRS运行时会生成日志和临时文件，如果目录不可写，进程会静默退出。
修改了配置文件需要重启才生效吗？
是的,SRS不会热加载配置文件，每次修改conf/srs.conf后都需要先杀掉旧进程再启动，或者用killall srs后重新执行启动命令。
SRS可以同时处理RTMP和WebRTC协议吗？
完全可以,SRS支持在同一进程内同时处理RTMP、WebRTC、SRT、HLS等协议，WebRTC的推拉流走UDP端口（默认8000），不同协议互不干扰，只需要在安全组里一并放行UDP端口。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/610339.html
