簡述
隨著網際網路的發展，音影片行業越來越火，自然而然的流媒體伺服器也是百花齊放。市面上也有很多種類的流媒體伺服器，讓人眼花繚亂。特別是對技術瞭解不深的朋友，更不知道怎麼選擇。
其實作為伺服器，主要考察的無外乎幾個核心指標，只要符合，基本上都是屬於比較優秀的流媒體伺服器。我簡略說一說這些核心特性：
穩定性，效能，資源佔用，併發能力，成本，可維護性
其實這些特性又不是獨立存在的，相互影響彼此。比如：可維護性。可維護性分為兩類，一個開發的可維護性，一個是運營的可維護性。開發的可維護性包括，軟體整體架構清晰，模組耦合性低，層次清晰，
這樣對於新業務的擴充套件比較容易，有問題也非常容易排查；這樣的架構也為高效，穩定提供了基石；運營的可維護性，對於新業務的展開邏輯比較清晰，錯誤排查比較方便容易定位，運維人員維護性差的可能需要 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 幾乎就是做了一個簡單解流封流轉流的功能，所以系統的佔用需求是最小的"
收尾
各位老鐵想不想也想測試一下對比一下各個流媒體的效能呢？包括軟體的便利性，相容性，部署成本，維護成本，可維護性做一個全面的對比。歡迎各位老鐵拿出您的資料與結論，選出您最喜歡的流媒體伺服器。