企业官网建设流程全解析

SRS 实时流媒体服务器全景导读：直播与 WebRTC 协议矩阵、可观测性与协程内核

【免费下载链接】srsSRS is a simple, high-performance, AI-driven real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711.项目地址: https://gitcode.com/GitHub_Trending/sr/srs

SRS（Simple Realtime Server）是一个开源的实时视频服务器，以"简单、高效"为核心设计目标，支持 RTMP、WebRTC、HLS、HTTP-FLV、SRT、MPEG-DASH 与 GB28181 等主流协议，并内置 HTTP API、HTTP 回调与 Prometheus Exporter 等运维与业务集成能力。本文以 SRS 官方 Introduction 文档为主线，结合当前仓库中的 完整配置示例、协程实现源码 与 版本记录，系统梳理 SRS 的定位、协议能力、应用场景、可观测性、技术实现与社区治理，帮助你快速判断 SRS 是否适合你的业务，并找到后续深入学习的入口。

SRS 是什么：一个推拉流模型下的实时媒体服务器

SRS 是一款遵循 MIT 许可证的开源实时视频服务器，仓库根目录的 LICENSE 明确了其开源授权。官方文档对其定位是"simple, high-efficiency, real-time video server"，即简单、高效、实时的视频服务器。它的核心工作模式是典型的**发布（推流）与订阅（拉流）**模型：推流端把一路流送入 SRS，播放端从 SRS 拉取同一路流。

SRS 自身不生产内容，而是与成熟的开源客户端生态协作：

• 推流端：FFmpeg、OBS 等编码器/推流工具；
• 播放端：VLC、FFplay、浏览器（WebRTC/HTTP-FLV/HLS）等。

官方 Docker 快速开始 给出了最直观的"一条命令跑起来"的演示：启动容器后，用 FFmpeg 推送一路流，再用 RTMP/HTTP-FLV/HLS/WebRTC 任选其一播放：

docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 ossrs/srs:5 ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream

其中1935是 RTMP 监听端口，1985是 HTTP API 端口，8080是 HTTP 流媒体（HTTP-FLV/HLS）端口。推流后即可通过rtmp://localhost/live/livestream（VLC）、http://localhost:8080/live/livestream.flv（HTTP-FLV）、http://localhost:8080/live/livestream.m3u8（HLS）等地址播放。

SRS 的路由设计非常简单：同一 vhost 下的任意 app/stream 组合即一路流，无需为每个流单独配置。官方文档中的 "Multiple Streams" 一节指出，只需改变推拉流 URL 即可扩展任意多路流，例如：

• rtmp://ip/live/livestream、rtmp://ip/liveN/livestreamN
• srt://ip:10080?streamid=#!::r=anyM/streamN,m=publish
• http://ip:1985/rtc/v1/whip/?app=anyM&stream=streamN
• http://ip:8080/anyM/streamN.flv、http://ip:8080/anyM/streamN.m3u8

支持协议矩阵与客户端生态

SRS 的协议支持覆盖了当前互联网音视频传输的主要形态：

配套的客户端生态包括：

• FFmpeg：最常用的推流/转码工具，SRS 文档中几乎所有推流示例都使用 FFmpeg；
• OBS：桌面直播推流软件，支持 RTMP 与 SRT 推流；
• VLC：跨平台播放器，用于播放 RTMP/SRT 流（注意 VLC 不支持 SRT 的 streamid 参数，详见下文）；
• WebRTC：浏览器原生实时通信标准，SRS 以 SFU 形态接入。

两大核心应用领域：直播与 WebRTC

SRS 的主战场是Live streaming（直播）与WebRTC（实时通信）两个领域。

直播领域：RTMP、HLS、SRT、MPEG-DASH、HTTP-FLV

直播是 SRS 最成熟的能力域。以 RTMP 为接入基础，SRS 可以同时输出 HLS、HTTP-FLV、HTTP-TS、MPEG-DASH 等协议。

SRT是 SRS 的核心协议之一，用于弱网、长距离、户外直播场景。SRT 基于 UDP，时延通常在 300-500ms，远低于 RTMP 的 1-3 秒。SRS 自 2020 年起支持 SRT，并在回调与 API 层面对 SRT 与 RTMP 做了高度一致化处理。SRT 使用 MPEG-TS 封装，因此天然支持 HEVC 等新编码。仓库中提供了 SRT 的专项配置 conf/srt.conf，并通过环境变量覆盖参数（如SRS_SRT_SERVER_ENABLED、SRS_SRT_SERVER_LISTEN、SRS_SRT_SERVER_MAXBW等）。

推流与播放 SRT 的典型命令（参见 SRT 文档）：

# 推流 ffmpeg -re -i ./doc/source.flv -c copy -pes_payload_size 0 -f mpegts \ 'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish' # 播放 ffplay 'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=request'

SRT URL 采用 YAML 风格的streamid表达语义：#!::为起始标记，r对应 RTMP 地址中的app/stream，m取publish（推流）或request（拉流）；支持用h指定 vhost。仓库还内置了面向不同客户端习惯的预置配置：conf/srt.shortstreamid.publish.conf（短 streamid 默认按推流处理）、conf/srt.shortstreamid.play.conf（默认按拉流处理）与conf/srt.vlc.conf（为不支持 streamid 的 VLC 设置默认 streamid）。低延迟场景下，文档建议按RTT * 3设置peerlatency/recvlatency/latency，并开启tlpktdrop on与tsbpdmode on。

WebRTC 领域：WHIP 与 WHEP

WebRTC 是 Google 开源的浏览器实时通信标准，本质是浏览器与浏览器之间的点对点音视频通信，由信令（SDP 协商）与媒体（SRTP 加密、低延迟传输）两部分组成，并内置 NACK/FEC/GCC 拥塞控制、3A 音频处理等能力。

在真实网络中，两点直连几乎不可行，需要服务器介入。SRS 在 WebRTC 体系中扮演SFU（Selective Forwarding Unit，选择性转发单元）角色——浏览器只上传一份数据，SFU 按需复制转发给其他订阅者，相比 TURN 的中转与 MCU 的混流，在并发能力与带宽成本之间取得平衡。与其他 SFU（如 Janus）不同的是，SRS 以"流"为粒度组织媒体：多人房间本质上仍是一路路独立的推/拉流，因此可以把不同参与者分散到多个 SFU 上，支撑更大规模的会议。

SRS 通过 WHIP（推流）与 WHEP（拉流） 两种标准信令协议接入 WebRTC：

• WHIP 推流：POST http://localhost:1985/rtc/v1/whip/?app=live&stream=livestream
• WHEP 拉流：POST http://localhost:1985/rtc/v1/whep/?app=live&stream=livestream

仓库源码 srs_app_rtc_api.cpp 中实现了这两组 API：推流路径会触发http_hooks_on_publish（srs_app_rtc_api.cpp），拉流路径会触发http_hooks_on_play（srs_app_rtc_api.cpp），这也印证了介绍文档中"HTTP Callback 同时适用于 WebRTC"的说明——WHIP 推流走on_publish，WHEP 拉流走on_play。

WebRTC 的配置分为全局rtc_server与 vhost 级rtc两部分，完整示例见 conf/full.conf。以下为核心参数：

rtc_server { # 是否启用 WebRTC 服务（环境变量 SRS_RTC_SERVER_ENABLED，默认 off） enabled on; # UDP 监听端口，复用给所有连接（默认 8000） listen 8000; tcp { # WebRTC over TCP（非 TURN），用于 UDP 受限网络 enabled off; listen 8000; } # candidate 生成策略：udp/tcp/all protocol udp; # 暴露给客户端的 candidate IP，可用 * / $CANDIDATE / 指定 IP candidate *; }

其中candidate是最容易踩坑的配置：它必须是客户端能够访问到的服务器 IP。SRS 会自动检测网卡 IP，也可通过环境变量$CANDIDATE传入，或通过 URL 参数?eip=ip[:port]临时指定（这在负载均衡/NAT 场景下尤其有用）。

vhost 级rtc配置（full.conf 起）还包括：

• stun_timeout：会话超时（默认 30s），客户端通过 STUN binding 请求作为心跳；
• nack on/off：是否启用丢包重传（ARQ）；
• twcc on/off：是否启用传输层拥塞反馈；
• rtmp_to_rtc：开启 RTMP 到 WebRTC 的转封装（AAC 转 Opus）；
• rtc_to_rtmp：开启 WebRTC 到 RTMP 的转封装；
• dtls_role、dtls_version：DTLS 角色与版本。

在 WebRTC 编码支持上，SRS 自 v4.0.91 起支持 AV1（仅 SFU 转发），自 v7.0.123 起支持 VP9，自 v7.0.124 起支持 G.711（PCMU/PCMA），可通过 URL 参数codec=av1、codec=vp9、acodec=pcmu/pcma指定。

协议转换：直播与 WebRTC 的桥梁

介绍文档特别强调 SRS 广泛支持互联网音视频协议间的转换，例如：

• RTMP/SRT → HLS / HTTP-FLV / WebRTC：这是最常见的"推流接入、多协议分发"模式；
• RTC → RTMP / HLS：把 WebRTC 推流转换为传统直播协议，供 RTMP/HTTP-FLV/HLS 播放，或接入 FFmpeg 做混流后再分发。

对应仓库中的现成配置：conf/rtmp2rtc.conf（RTMP 转 WebRTC）、conf/rtc2rtmp.conf（WebRTC 转 RTMP）、conf/srt2rtc.conf（SRT 转 WebRTC）、conf/srt2ts.conf（SRT 转 HTTP-TS）等。以 RTMP 转 WebRTC 为例，只需设置CANDIDATE后用-c conf/rtmp2rtc.conf启动 SRS，即可用 FFmpeg 推 RTMP、用浏览器 WHEP 低延迟播放。

可观测性与业务集成：HTTP API、HTTP Callback 与 Prometheus Exporter

SRS 为运维与业务定制提供了三层开放能力。

HTTP API：查询与管理 SRS

SRS 提供一套自描述的 JSON HTTP API，供外部系统查询系统与流状态。工作流为：浏览器/业务应用 → HTTP API → SRS。仓库中 HTTP API 的路由实现位于 srs_app_http_api.cpp，配置示例在 full.conf：

http_api { enabled on; listen 1985; # 默认 1985（full.conf 示例中为 8080） crossdomain on; # 支持浏览器跨域调用 auth { enabled on; type basic; # basic 或 bearer username admin; password admin; } https { enabled off; listen 1990; key ./conf/server.key; cert ./conf/server.crt; } }

常用 API 一览（详见 HTTP API 文档）：

错误以两种形式返回：HTTP 非 200 状态码，或 HTTP 200 但 body 中code非 0。SRS 5.0.152+ / 6.0.40+ 起支持 Basic 与 Bearer 两种鉴权方式（配置段http_api.auth），仓库提供了现成示例 conf/http.api.auth.basic.conf 与 conf/http.api.auth.bearer.conf。

HTTP Callback：主动通知业务系统

HTTP Callback 是 SRS 与业务系统集成、实现流鉴权与业务定制（如动态 DVR）的关键机制。当 FFmpeg/OBS 推流或播放时，SRS 会 POST 事件到你的业务服务器：

+--------+ +--------+ +-----------------------+ | FFmpeg |-->--+ SRS |--HTTP-Callback-->--+ Your Business Server | +--------+ +--------+ +-----------------------+

支持的事件包括：on_publish（推流开始）、on_unpublish（推流结束）、on_play（播放开始）、on_stop（播放结束）、on_dvr（DVR 切片）、on_hls（HLS 切片）与on_hls_notify（CDN 刷新通知）。回调体为 JSON，例如on_publish会携带action、client_id、ip、vhost、app、stream、param、server_id、stream_url、stream_id等字段；若业务服务器返回非 0 的 code 或非 200 的 HTTP 状态，SRS 会拒绝该客户端——这正是基于回调做推流鉴权（如校验 URL 中的?token=xxx）的原理。示例配置见 conf/http.hooks.callback.conf，文档还提供了 Go、Nodejs/Koa、PHP 三种语言的回调服务器示例。

Prometheus Exporter：云原生监控接入

SRS 提供官方 Prometheus Exporter，用于对接云原生监控体系（Metrics + Grafana 可视化）。整体架构为：

+-----+ +-----------+ +---------+ | SRS +--Exporter-->--+ Prometheus +-->--+ Grafana + +-----+ (HTTP) +-----------+ +---------+

配置段exporter（默认监听 9972）：

exporter { # 环境变量 SRS_EXPORTER_ENABLED，默认 off enabled off; listen 9972; # 集群标识，便于按机房/角色分类 label cn-beijing; tag cn-edge; }

启用方式（SRS 5.0.86+）：

./configure && make env SRS_ENV_ONLY=on SRS_EXPORTER_ENABLED=on SRS_LISTEN=1935 ./objs/srs -e

Prometheus 抓取http://localhost:9972/metrics后，即可用 PromQL 查询码率等指标，例如rate(srs_receive_bytes_total[10s])*8表示输入码率。详细步骤（含 Prometheus 与 Grafana 的 docker 启动、数据源与 Dashboard 导入）参见 Exporter 文档。

此外，介绍文档还提到 SRS 支持会话级可追踪日志（session-level traceable logs），用于大幅降低系统维护成本——每个客户端连接/会话拥有独立的上下文标识，排查问题时可以沿着一条会话链路完整追踪其生命周期。

技术实现：ANSI C++ 98 与 ST 协程内核

SRS 使用 ANSI C++（98）编写，只采用基础的 C++ 能力，可在 Linux、Windows、macOS 上运行，官方建议使用 Ubuntu 20+ 进行开发调试（官方 Docker 镜像也基于 Ubuntu 20/focal 构建）。

面对流媒体处理中"长连接 + 复杂状态机"的难题，SRS 采用ST（State Threads）协程技术——一种类似 Go Goroutine 的 C 协程库——将阻塞式 IO 的编程范式与高并发结合起来。SRS 持续增强并维护 ST，使其支持 Linux、Windows、macOS 及 X86_64、ARMv7、AARCH64、M1、RISCV、LOONGARCH、MIPS 等多种 CPU 架构。

从源码看，SRS 在 srs_app_st.cpp 中封装了协程抽象SrsFastCoroutine：其构造函数注释明确"0 use default, default is 64K"（协程栈默认 64KB，见 srs_app_st.cpp），启动时调用_pfn_st_thread_create(pfn, this, 1, stack_size_)创建 ST 协程（srs_app_st.cpp）。这套协程封装在协议层（srs_protocol_st.cpp）和应用层被广泛复用，是 SRS 高并发低开销的根基之一。

版本策略与里程碑

SRS 约每两年发布一个大版本：一年开发、一年稳定性打磨。官方给出如下版本分支建议：

• develop：SRS 6.0 开发分支，不稳定，但新特性最多；
• 5.0release：SRS 5.0，当前稳定版本（视分支状态而定）；
• 4.0release：SRS 4.0，长期稳定分支。

版本号体系对应三种标签：-r为正式发布版（如v4.0-r0）、-b为相对稳定的公测版（如v4.0-b0）、普通版本号为不稳定开发版（如v4.0.198）；此外还有比 beta 更不稳定的 alpha 版（如v5.0-a0，对应版本号v5.0.98）。对 SRS 而言，到达 beta 版本即可用于线上。仓库的 trunk/doc/CHANGELOG.md 分别记录了 SRS 6.0、SRS 5.0 与 SRS 4.0 的变更历史。另外注意，个别功能会被标记为 Deprecated/Removed，官方会在特性列表中说明移除原因。

生态布局与社区治理

SRS 的策略是不做客户端，而是与 FFmpeg、OBS、VLC、WebRTC 等成熟社区协作，把精力放在服务端与工具链上。围绕 SRS 的生态项目包括：

• Oryx（SRS Stack）：开箱即用的单机视频云方案，整合 FFmpeg 与 SRS，面向不熟悉命令行的用户，可通过云镜像或宝塔面板以鼠标操作搭建音视频应用；
• WordPress-Plugin-SrsPlayer：面向出版行业（个人博客、媒体网站）的播放器插件；
• srs-unity：面向游戏行业，集成 Unity 的 WebRTC SDK；
• srs-bench：支持 RTMP、FLV、WebRTC、GB28181 的音视频压测工具；
• state-threads：可视为 C 版的 Go 协程库，小而强大，持续演进；
• tea：探索用 eBPF 做弱网模拟与负载均衡。

在质量保障上，社区采用"长期架构讨论（如 HEVC 支持历经 7 年讨论）、每个 PR 至少两名 TOC 与开发者 review 并跑通全部 CI、超过 500 个单元测试与约 60% 代码覆盖率、黑白盒测试、发布全流程流水线自动化"等机制。SRS 是非商业开源社区，欢迎任何人通过提交 Issue、贡献 PR 参与开发。

进一步学习路径

介绍文档为不同人群给出了明确的阅读建议：

• 音频视频与流媒体新手：从 Getting Started（Docker 快速开始） 入手，实际推拉一路流建立直观感受；
• 想系统学习协议能力：按 RTMP、SRT、HLS、HTTP-FLV、WebRTC 的顺序阅读；
• 想做业务集成：精读 HTTP API 与 HTTP Callback；
• 想深入源码：从 srs_app_st.cpp（协程封装）、srs_app_rtc_api.cpp（WHIP/WHEP 实现）、srs_app_http_api.cpp（HTTP API 路由）以及 full.conf（全量配置注释）出发。

遇到问题时，官方建议先查 FAQ，再在社区搜索 Issue 与 Discussion——绝大多数问题都能在文档与历史讨论中找到答案。

【免费下载链接】srsSRS is a simple, high-performance, AI-driven real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711.项目地址: https://gitcode.com/GitHub_Trending/sr/srs