简述

随着互联网的发展，音视频行业越来越火，自然而然的流媒体服务器也是百花齐放。市面上也有很多种类的流媒体服务器，让人眼花缭乱。特别是对技术了解不深的朋友，更不知道怎么选择。
其实作为服务器，主要考察的无外乎几个核心指标，只要符合，基本上都是属于比较优秀的流媒体服务器。我简略说一说这些核心特性：

稳定性，性能，资源占用，并发能力，成本，可维护性

其实这些特性又不是独立存在的，相互影响彼此。比如：可维护性。可维护性分为两类，一个开发的可维护性，一个是运营的可维护性。开发的可维护性包括，软件整体架构清晰，模块耦合性低，层次清晰，
这样对于新业务的扩展比较容易，有问题也非常容易排查；这样的架构也为高效，稳定提供了基石；运营的可维护性，对于新业务的展开逻辑比较清晰，错误排查比较方便容易定位，运维人员维护性差的可能需要 3 个人，而维护性好的可以 1 个人搞定，大大节省了人员成本。同时，对硬件资源可以减少使用的台数，大大的节省运维费用。其实每一点都可以长篇累牍的去讲述它的优缺点，但偏离了本文的用意，这里就不一一列举了。

这里主要介绍几款个人感觉不错的流媒体服务器。 smart_rtmpd, nginx rtmp, srs, zlm 。明白人一眼就看出来，这些主要是 C, C++ 语言实现的服务器，没错。就像有的借助小汽车的底盘，有的借助摩托车地盘，
从起点很多别的语言的流媒体服务器就输了。 C, C++ 基本上属于性能最好的语言，性能上 C > C++，不要和我抬杠说汇编。：）

名字	开发语言
nginx rtmp	C
smart_rtmpd	C++
srs	C++
zlm	C++

基本情况介绍

smart_rtmpd 服务器

github 地址: https://github.com/superconvert/smart_rtmpd
gitee 地址: https://gitee.com/superconvert/smart_rtmpd

免费软件，支持 rtmp, rtsp, srt 推流，rtmp, rtsp, srt, hls, dash, http-flv, ws-flv, webrtc 拉流；支持 webrtc sfu 功能，支持 VOD 功能，支持直播和录像；特点，稳定，高效，简洁，跨平台，解压及运行，支持的操作系统 Windows, Ubuntun, CentOS, Debian, FreeBSD, ARM 64，无第三方依赖，基本上内核 + glibc 就能运行，软件体积非常小，配置相对简单，由于出道比下面三个晚，名气相对没有下面三个大。

nginx rtmp 服务器

github 地址：https://github.com/arut/nginx-rtmp-module
开源软件，由于 nginx rtmp 依托 nginx 底层，所以性能也是相对比较好的，但功能相对于其余三个，相对比较少一点，也是支持跨平台，需要准备第三方库及编译环境，针对不同的操作系统需要不同的环境配置进行编译适配，过多的功能和说明，请参考它们的 README.md

srs 服务器

github 地址：https://github.com/ossrs/srs
开源软件：srs 基于协程技术，对于单进程的能力挖掘相当强悍，单对于多核应用同时对于 webrtc 的功能支持也是比较全面。也是支持跨平台，需要配置对应的编译环境，过多的功能和说明，请参考它们的 README.md

zlm 服务器

github 地址：https://github.com/ZLMediaKit/ZLMediaKit
开源软件：目前是一个庞大的开发框架，不仅提供服务器的一些功能，还提供一些基础组件，对于国产化的相关规范支持的比较全。过多的功能和说明，请参考它们的 README.md

测试环境

测试一般分为三端，推流端，服务器，拉流端，为了保证公平公正合理的情况下，测试过程中，推流端不做任何更改，推流码率固定；拉流端不做任何更改；服务器端依次运行各个流媒体服务器软件，其它软硬件环境均保持不变。同样的硬件，既同样的 CPU, 内存，硬盘，网络。

软件条件说明:

服务器操作系统 Ubuntu 24.04.1 LTS ( 虚拟机 ) , CPU: 2 , Memory: 8G

软件	编译器	版本或源码分支	说明
smart_rtmpd	gcc 5.4.0	2024.09.16 乌班图多线程版本	老的编译器进行编译，新编译器应该性能会更好
nginx rtmp	gcc 13.2.0	源码分支：2fb11dffaedc5af66b1442b0315c54a4b9da585d	大家如果想验证测试结果可以自行选择最优分支进行验证
srs	gcc 13.2.0	源码分支：747831154742e6e4dee9b16f3a29fc6e01904e8c	大家如果想验证测试结果可以自行选择最优分支进行验证
zlm	gcc 13.2.0	源码分支：da704ab2f1184c3c87be64fe18c9f413de101d0f	大家如果想验证测试结果可以自行选择最优分支进行验证

推流软件

软件	版本
OBS	29.0.2
ffmpeg.exe	version 4.3.2-2021-02-02-full_build-www.gyan.dev Copyright (c) 2000-2021 the FFmpeg developers

拉流软件

软件	版本
rtmpstress.exe	无
ffplay.exe	version 4.3.2-2021-02-02-full_build-www.gyan.dev Copyright (c) 2003-2021 the FFmpeg developers

测试场景及数据

测试分为三个场景，时延测试，拉流测试，推流测试

时延测试

推流 OBS + 浏览器网页截屏 ( 1920x1080, 8192 kb/s )
浏览器：在线秒表网页
测试协议：rtmp 推拉流

拉流 ffplay -fflags nobuffer rtmp://192.168.23.141:1935/live/stream
测试场景：一路推流一路拉流，主要测试延时

说明	smart rtmpd	srs	zlm	nginx rtmp
	1.117	1.506	1.635	1.334
	1.337	1.635	2.451	1.333
	1.247	1.507	2.194	1.334
	1.246	1.504	1.721	1.291
	1.335	1.644	3.441	1.773
	1.287	1.505	1.677	1.290
	1.258	1.460	1.635	1.291
	1.247	1.590	1.634	1.290
	1.374	1.548	1.677	1.204
单位秒	1.376	1.635	1.592	1.376

拉流测试

推流 OBS ( 4096 kb/s )
测试协议：rtmp 推拉流
测试时长：10 分钟
拉流 rtmpstress.exe 一路推 800 路拉，主要系统指标

说明	smart rtmpd	srs	zlm	nginx rtmp
	86%	88%	189%	95.40%
	123%	98%	200%	97.40%
	82%	99%	143%	84.30%
	23%	53%	OBS 断开，拉流 187	94.80%
	98%	42%		35.00%
	89%	6%		95.50%
	97%	4%		40.00%
	102%	OBS 断开，拉流全部断开		94.80%
	81%			26.20%
	38%			95.00%
CPU 随机抽取 10 次
内存	0.50%	3.30%	0.90%	0.30%

结论平均 CPU 占用率 smart_rtmpd 与 nginx rtmp 旗鼓相当，CPU 占用率相对较低，对于内存的占用也是相对较低，推拉流过程相对平稳，无异常，但 nginx rtmp 业务相对于其它三个服务器业务是最简单的，缓存或 IO 都是简化处理的，其次它是纯 C 实现的，语言上对性能的优化占有天然的优势。
压测过程中 srs 和 zlm 推流一段时间，推流端会产生断开现象，拉流端会出现全部断开的现象。
smart_rtmpd 的拉流链接由 800 路降低到 724 路，而 nginx rtmp 的拉流链接数由 800 路降低到 664 路。
srs 协程模型只能用一个 CPU ，所以理论上 CPU 不会超过 100%

推流测试

说明	smart rtmpd	srs	zlm	nginx rtmp
CPU	13.7% ~ 200%	23.9% ~100%	97.4% ~ 200%	52.5% ~93.8%
内存	13.60%	6.00%	11.90%	0.40%
说明 top 查看网卡中断和服务器进程交替霸榜，CPU 大部分时间占用和 nginx 相差不多，但 CPU 最大值大于 nginx 。推流长时间有部分链接断开	"协程（单进程，CPU 最大 100%, 推流长时间推流链接大量断开 )"	推流长时间有部分链接断开	top 查看网卡和服务器进程交替霸榜，表现相当不错，推流长时间链接没有断开

结论： CPU 表现相对优秀的是 nginx rtmp, smart_rtmpd
内存占用 smart_rtmpd 最多，不过缓冲队列是可配置的，没有降低配置降低内存占用，nginx rtmp 的内存占用比较优秀不过 smart_rtmpd, srs, zlm 的业务功能都比 nginx 复杂很多，内存占用过多是理所当然的，nginx 几乎就是做了一个简单解流封流转流的功能，所以系统的占用需求是最小的"