SRS WebRTC Signaling 信令服务实战Docker 部署、源码构建与 HTTPS/WSS 反向代理指南【免费下载链接】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/srsSRSSimple Realtime Server采用「信令面与媒体面分离」的架构媒体面由 SRS 的 RTC 模块负责WHIP/WHEP、SRTP/SRTCP、ICE/DTLS而信令面需要一个轻量级服务来协调浏览器之间的房间加入、发布状态与呼叫控制。trunk/3rdparty/signaling正是 SRS 官方随仓库发布的demo WebRTC signaling——一个基于 Go WebSocket 的极简信令服务。本文将以 signaling/README.md 为骨架完整讲解如何用 Docker 一键跑通 SRS signaling 的 WebRTC 通话演示、如何从源码构建运行并结合 main.go 与前端 SDK 源码剖析其信令协议与房间模型最后给出通过 httpx-static 将演示服务升级为 HTTPS/WSS 的完整方案。读完本文你可以独立搭建一套可演示、可学习、可二次开发的一对一/多人 WebRTC 信令系统。一、signaling 是什么SRS WebRTC 架构中的信令面在 SRS 的 WebRTC 解决方案中浏览器之间的媒体流通过 SRS 的 SFUSelective Forwarding Unit进行转发这一过程使用标准化的 WHIPWebRTC-HTTP Ingestion Protocol推流与 WHEPWebRTC-HTTP Egress Protocol拉流完成 SDP 交换而「谁在哪个房间、谁开始发布、谁要离开、互相发送控制消息」这类协调工作则需要信令服务来完成。signaling 正是承担这一角色的官方 demo 实现。该组件位于仓库trunk/3rdparty/signaling/目录核心构成如下文件/目录作用README.md使用与构建文档本文主体main.goGo 实现的服务端提供 WebSocket 信令与静态页面服务Makefile构建脚本产出objs/signaling二进制Dockerfile基于 Ubuntu 的两阶段镜像构建go.modGo 模块定义依赖go-oryx-lib与golang.org/x/netauto/pub.sh打 tag 发布脚本www/demos/一对一会话、多人房间等 H5 演示页面与前端 SDK从 go.mod 可以看到服务端基于 Go 1.16仅依赖两个模块github.com/ossrs/go-oryx-lib日志、错误处理等基础库与golang.org/x/net其中提供websocket包。整个服务端核心逻辑集中在单个 main.go约 350 行中非常适合作为学习与二次开发的起点。二、快速体验Docker 一键跑通 SRS signaling2.1 启动 SRSRTC 配置首先在 Docker 中启动 SRS使用 RTC 专用配置 trunk/conf/rtc.conf并通过环境变量CANDIDATE指定本机公网/局域网 IP用于 ICE candidate 协商docker run --rm --env CANDIDATE$(ifconfig en0 inet| grep inet |awk {print $2}) \ -p 1935:1935 -p 8080:8080 -p 1985:1985 -p 8000:8000/udp \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:4 \ objs/srs -c conf/rtc.conf说明CANDIDATE应替换为实际可达的 IP如ifconfig输出中的 en0 地址或云主机公网 IP。更多镜像与版本可参考镜像仓库页面。各端口在 SRS 中的作用端口协议用途1935TCPRTMP 推拉流8080TCPSRS HTTP 服务HLS、HTTP-FLV 等1985TCPSRS HTTP APIHTTP API、WHIP/WHEP SDP 交换8000UDPWebRTC 媒体流SRTP/SRTCP2.2 启动 signaling 服务在另一个终端启动 signaling监听 1989 端口docker run --rm -p 1989:1989 registry.cn-hangzhou.aliyuncs.com/ossrs/signaling:1说明signaling 镜像会同时托管静态演示页面www目录因此 1989 端口既是 WebSocket 信令端口也是 H5 演示页面的 HTTP 端口。2.3 打开 H5 演示浏览器访问即可进入一对一通话演示带autostarttrue自动开始WebRTC: One to One over SFU(SRS)这是 README 给出的最小验证路径两个浏览器分别打开上述地址加入同一房间后即可互通音视频。整套环境仅需两个容器无需任何代码。三、从源码构建与运行如果希望调试、修改或深入学习可以从源码构建。3.1 构建并运行 SRS在已就绪的 SRS 仓库中进入trunk目录执行配置与编译rtc.conf位于 trunk/conf/rtc.confcd ~/git/srs/trunk ./configure make ./objs/srs -c conf/rtc.conf3.2 构建并运行 signaling在 signaling 目录执行make产物为objs/signalingcd ~/git/srs/trunk/3rdparty/signaling make ./objs/signaling从 Makefile 可以看到构建细节make会先执行gofmt -w .统一格式生成.format.txt标记然后以go build -modvendor -o objs/signaling .进行编译。目标文件仅一个二进制 www静态目录非常轻量。运行后浏览器打开演示列表http://localhost:1989/demos3.3 服务端启动参数从 main.go 可以看到signaling 支持两个命令行参数参数默认值说明-listen1989TCP 监听端口信令 WebSocket 静态页面共用-root./www静态页面根目录若为相对路径且可执行文件路径为绝对路径则自动拼接到可执行文件所在目录启动日志会输出Signaling ok, root..., home page is ...其中 home page 即演示首页地址。四、信令协议与核心源码剖析4.1 两个 HTTP 端点signaling 在同一个端口上提供了三个路由见 main.go/—— 静态文件服务http.FileServer托管www演示页面/sig/v1/versions—— 返回字符串1.0用于版本探活/sig/v1/rtc—— WebSocket 信令端点核心逻辑所在。4.2 WebSocket 消息帧格式客户端通过ws://host:1989/sig/v1/rtc?room房间名display昵称建立连接见 srs.sig.js。消息为 JSON 文本帧外层带事务 IDtid{ tid: a1b2c3d, msg: { action: join, room: live, display: alice } }服务端响应同样携带tid回包而服务端主动广播的通知notify则不带tid通过event字段区分事件类型。4.3 三种 Actionjoin / publish / control从 main.go 可以完整还原服务端对三类消息的处理join加入房间解析msg.room与msg.display通过sync.Map的LoadOrStore获取/创建房间创建Participant并调用Room.Add加入。Add会做同名检查main.go若房间内已存在相同display则返回错误。成功后向本人返回{action, room, self, participants}房间当前成员列表并向其他成员广播event: join。publish宣布发布找到房间内对应display的参与者将其Publishing置为true随后向其他成员广播event: publish。收到该事件的成员即可知道「有人开始推流了」从而发起 WHEP 拉流。control控制消息携带call与data两个透传字段如call: refresh、call: alert 任意data服务端将其原样广播给房间内其他成员实现演示中的「刷新对方页面」「给对方弹窗」等自定义控制。4.4 服务端数据模型Room 与 Participant服务端的数据模型非常清晰main.goParticipantDisplay昵称、Publishing是否推流中、Out该连接的消息发送通道chan []byteRoomName房间名、Participants成员切片并以sync.RWMutex保护并发读写全局rooms sync.Map以房间名为 key 持有所有房间。连接的读写模型采用双 goroutine 通道读取 goroutine 循环Read消息并送入inMessages处理 goroutine 逐个处理并回包写入 goroutine 循环从outMessages取数据Write回客户端。连接断开时main.go服务端会先向房间内其他成员广播event: leave再将自身从房间移除——这正是「有人离开」通知的来源前端收到leave事件后会隐藏播放器见 one2one.html。4.5 广播通知的完整结构Room.Notifymain.go在加锁快照成员列表后向除发送者外的每个成员投递以下结构{ action: notify, event: join | publish | leave | control, param: , data: , room: 房间名, self: { display: 接收者, publishing: false }, peer: { display: 发送者, publishing: false }, participants: [ 房间内全部成员 ] }其中control事件的param对应call字段、data对应data字段。该结构同时覆盖了self自己、peer对方与participants全量成员足以支撑一对一与多人的房间状态同步。4.6 前端 SDKsrs.sig.js演示页面的信令客户端封装在 srs.sig.js 中提供三个核心 APIconnect(schema, host, room, display)建立ws(s)://host/sig/v1/rtc?room..display..连接返回 Promisesend(message)为消息生成 7 位十六进制tid将{resolve, reject}存入_internals.msgs后发送收到同tid响应即 resolvesrs.sig.jsonmessage(msg)回调用于接收服务端主动广播的 notify 事件。此外SrsRtcSignalingParsesrs.sig.js负责从 URL 解析wss、wsh、wsp、host、room、display、autostart等参数并把与信令无关的查询参数原样透传给媒体层如 WHIP/WHEP 的 token。五、H5 演示与 WHIP/WHEP 媒体流打通5.1 演示页面www/demos/下提供两个核心演示入口见 index.htmlone2one.html一对一视频通话room.html多人视频房间Video Room。两个页面都支持autostarttrue自动启动便于直接粘贴 URL 分享。5.2 一对一流程拆解以 one2one.html 为例完整流程为sig.connect(...)建立信令连接sig.send({action:join, room, display})加入房间返回成员列表startPublish将webrtc://地址转换为 WHIP URLhttp(s)://host:1985|443/rtc/v1/whip/?approomstreamdisplay并调用SrsRtcWhipWhepAsync.publish()推流见 srs.sdk.jssig.send({action:publish, room, display})广播「我在推流」对房间内已存在的publishing成员调用startPlay使用 WHEP URL/rtc/v1/whep/?approomstreamdisplay拉流播放srs.sdk.js之后新成员加入或推流时通过 notify 事件publish、join、leave触发对应的开始/停止播放。媒体 URL 的端口规则one2one.html 中convertToWhipUrl/convertToWhepUrlHTTP 场景走 1985HTTPS 场景走 443。而信令端口默认 1989当演示页面通过 SRS 的 8080 HTTP 服务打开时index.html会自动追加wsp1989让信令连接到 1989 端口见 index.html。5.3 演示 URL 参数一览参数含义默认值hostSRS 媒体服务器地址当前页面 hostnameroom加入的房间名随机生成display用户昵称随机生成wssWebSocket 协议ws/wss依页面协议推断wshWebSocket 服务器地址当前页面 hostnamewspWebSocket 端口当前页面端口autostart页面加载后自动开始关闭5.4 双人以上时的 FFmpeg 合流提示当participants.length 2时one2one 页面会展开「FFmpeg 合流转直播」面板见 one2one.html给出将两路 RTMP 流用-filter_complex overlay合成为一路并推流到rtmp://host/room/merge的完整命令并支持一键将输出对接视频号推流地址填写推流地址与密钥后点击「应用」。这一功能演示了 WebRTC 通话与 RTMP 直播体系的互转能力。六、HTTPS/WSS 生产化httpx-static 反向代理WebRTC 的getUserMedia在非 localhost 环境强制要求 HTTPS浏览器安全策略见 srs.sdk.js 中HttpsRequiredError的抛出逻辑因此将信令升级为 WSS 是实际部署的必经之路。SRS 仓库提供了 httpx-static 组件一个 Go 实现的「HTTP/HTTPS 静态服务器 API 反向代理」可一站完成证书终止与多后端代理。6.1 构建并运行 httpx-staticcd ~/git/srs/trunk/3rdparty/httpx-static make ./objs/httpx-static -http 80 -https 443 -ssk server.key -ssc server.crt \ -proxy http://127.0.0.1:1989/sig -proxy http://127.0.0.1:1985/rtc \ -proxy http://127.0.0.1:8080/其中server.key/server.crt为自签或正式证书若需要生成自签证书httpx-static 的用法说明中给出了openssl genrsaopenssl req -x509的标准命令。6.2 参数说明从 httpx-static/main.go 可确认各参数语义参数短/长说明-t/-httpHTTP 监听端口0表示禁用-s/-httpsHTTPS 监听端口如443-r/-root静态文件根目录默认./html相对可执行文件路径-k/-ssk自签或文件型证书的私钥文件-c/-ssc自签或文件型证书的证书文件-p/-proxy反向代理规则可重复指定多个按路径前缀匹配转发到后端-d/-domainsHTTPS 允许的域名配合 Lets Encrypt 时用于校验留空允许所有-l/-lets是否使用 Lets Encrypt CA否则使用自签证书代理规则的匹配是按路径前缀进行的因此上面三条规则分别把/sigsignaling 信令、/rtcSRS 的 WHIP/WHEP API、/SRS 的 HTTP 服务与静态资源分发到对应后端。README 中的另一条典型规则-proxy http://127.0.0.1:8888/api/webrtc也印证了这一「路径前缀 → 后端」的模型。此外-proxy还支持?trimPrefix/x、?addPrefix/y、?keepUpsreamServertrue、?modifyRequestHostfalse等高级修饰参数见 main.go。6.3 通过 HTTPS/IP 访问演示部署完成后以下地址均可访问演示http://localhost/demos/https://localhost/demos/https://192.168.3.6/demos/此时浏览器页面为 HTTPSwss自动推断为wss媒体 API 走 443443 上/rtc被代理到 SRS 1985信令走wss://.../sig被代理到 signaling 1989三者通过同一域名 端口即可统一访问规避了混合内容与getUserMedia安全限制。七、从 demo 走向自研源码结构给出的启示需要明确的是signaling 官方定位为demoREADME 第一句即声明 A demo WebRTC signaling从源码结构可以推断其面向演示与教学的设计取舍单进程内存态房间数据存于进程内sync.Map无持久化、无水平扩展能力多实例部署时需要自行引入共享状态如 Redis与一致性方案无鉴权与配额join/control不校验身份与权限任何人可加入任意房间生产环境需在信令层或上层网关补充 Token 校验媒体面完全交由 SRSsignaling 本身不处理 SDP/ICE仅做事件转发媒体质量、NAT 穿透STUN/TURN能力取决于 SRS 的 RTC 配置协议简洁可扩展join/publish/controlnotify的四事件模型足够通用新增动作如踢人、举手、录制开关只需在 main.go 的消息分发处仿照现有分支扩展并在 srs.sig.js 的send/onmessage上对接即可。如果需要更完整的多方音视频能力SRS 仓库的trunk/research与srs-bench等目录也提供了压力测试与协议验证的参考实现可作为扩展阅读。总结本文完整走通了 SRS WebRTC signaling 的三种使用形态Docker 一键体验两个容器 一个 URL 即可看到一对一通话、源码构建make产出单二进制-listen/-root两个参数即可运行、HTTPS/WSS 生产化httpx-static 按路径前缀反代/sig、/rtc、/三路后端。同时结合 main.go 与 srs.sig.js 剖析了信令协议/sig/v1/rtcWebSocket 端点、tid事务帧、join/publish/control三种动作、Room/Participant内存模型与join/publish/leave/control四类广播事件。无论你是要快速验证 SRS 的 WebRTC 能力还是要在此 demo 基础上构建自己的房间信令服务本文提供的部署命令、协议字段与源码定位都可以直接作为起点。进一步阅读信令服务完整源码trunk/3rdparty/signaling/main.go前端信令 SDKtrunk/3rdparty/signaling/www/demos/js/srs.sig.jsWHIP/WHEP 媒体 SDKtrunk/3rdparty/signaling/www/demos/js/srs.sdk.js演示页面源码trunk/3rdparty/signaling/www/demos/one2one.htmlHTTPS/WSS 反代组件trunk/3rdparty/httpx-static/main.goSRS RTC 配置示例trunk/conf/rtc.conf【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SRS WebRTC Signaling 信令服务实战：Docker 部署、源码构建与 HTTPS/WSS 反向代理指南
SRS WebRTC Signaling 信令服务实战Docker 部署、源码构建与 HTTPS/WSS 反向代理指南【免费下载链接】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/srsSRSSimple Realtime Server采用「信令面与媒体面分离」的架构媒体面由 SRS 的 RTC 模块负责WHIP/WHEP、SRTP/SRTCP、ICE/DTLS而信令面需要一个轻量级服务来协调浏览器之间的房间加入、发布状态与呼叫控制。trunk/3rdparty/signaling正是 SRS 官方随仓库发布的demo WebRTC signaling——一个基于 Go WebSocket 的极简信令服务。本文将以 signaling/README.md 为骨架完整讲解如何用 Docker 一键跑通 SRS signaling 的 WebRTC 通话演示、如何从源码构建运行并结合 main.go 与前端 SDK 源码剖析其信令协议与房间模型最后给出通过 httpx-static 将演示服务升级为 HTTPS/WSS 的完整方案。读完本文你可以独立搭建一套可演示、可学习、可二次开发的一对一/多人 WebRTC 信令系统。一、signaling 是什么SRS WebRTC 架构中的信令面在 SRS 的 WebRTC 解决方案中浏览器之间的媒体流通过 SRS 的 SFUSelective Forwarding Unit进行转发这一过程使用标准化的 WHIPWebRTC-HTTP Ingestion Protocol推流与 WHEPWebRTC-HTTP Egress Protocol拉流完成 SDP 交换而「谁在哪个房间、谁开始发布、谁要离开、互相发送控制消息」这类协调工作则需要信令服务来完成。signaling 正是承担这一角色的官方 demo 实现。该组件位于仓库trunk/3rdparty/signaling/目录核心构成如下文件/目录作用README.md使用与构建文档本文主体main.goGo 实现的服务端提供 WebSocket 信令与静态页面服务Makefile构建脚本产出objs/signaling二进制Dockerfile基于 Ubuntu 的两阶段镜像构建go.modGo 模块定义依赖go-oryx-lib与golang.org/x/netauto/pub.sh打 tag 发布脚本www/demos/一对一会话、多人房间等 H5 演示页面与前端 SDK从 go.mod 可以看到服务端基于 Go 1.16仅依赖两个模块github.com/ossrs/go-oryx-lib日志、错误处理等基础库与golang.org/x/net其中提供websocket包。整个服务端核心逻辑集中在单个 main.go约 350 行中非常适合作为学习与二次开发的起点。二、快速体验Docker 一键跑通 SRS signaling2.1 启动 SRSRTC 配置首先在 Docker 中启动 SRS使用 RTC 专用配置 trunk/conf/rtc.conf并通过环境变量CANDIDATE指定本机公网/局域网 IP用于 ICE candidate 协商docker run --rm --env CANDIDATE$(ifconfig en0 inet| grep inet |awk {print $2}) \ -p 1935:1935 -p 8080:8080 -p 1985:1985 -p 8000:8000/udp \ registry.cn-hangzhou.aliyuncs.com/ossrs/srs:4 \ objs/srs -c conf/rtc.conf说明CANDIDATE应替换为实际可达的 IP如ifconfig输出中的 en0 地址或云主机公网 IP。更多镜像与版本可参考镜像仓库页面。各端口在 SRS 中的作用端口协议用途1935TCPRTMP 推拉流8080TCPSRS HTTP 服务HLS、HTTP-FLV 等1985TCPSRS HTTP APIHTTP API、WHIP/WHEP SDP 交换8000UDPWebRTC 媒体流SRTP/SRTCP2.2 启动 signaling 服务在另一个终端启动 signaling监听 1989 端口docker run --rm -p 1989:1989 registry.cn-hangzhou.aliyuncs.com/ossrs/signaling:1说明signaling 镜像会同时托管静态演示页面www目录因此 1989 端口既是 WebSocket 信令端口也是 H5 演示页面的 HTTP 端口。2.3 打开 H5 演示浏览器访问即可进入一对一通话演示带autostarttrue自动开始WebRTC: One to One over SFU(SRS)这是 README 给出的最小验证路径两个浏览器分别打开上述地址加入同一房间后即可互通音视频。整套环境仅需两个容器无需任何代码。三、从源码构建与运行如果希望调试、修改或深入学习可以从源码构建。3.1 构建并运行 SRS在已就绪的 SRS 仓库中进入trunk目录执行配置与编译rtc.conf位于 trunk/conf/rtc.confcd ~/git/srs/trunk ./configure make ./objs/srs -c conf/rtc.conf3.2 构建并运行 signaling在 signaling 目录执行make产物为objs/signalingcd ~/git/srs/trunk/3rdparty/signaling make ./objs/signaling从 Makefile 可以看到构建细节make会先执行gofmt -w .统一格式生成.format.txt标记然后以go build -modvendor -o objs/signaling .进行编译。目标文件仅一个二进制 www静态目录非常轻量。运行后浏览器打开演示列表http://localhost:1989/demos3.3 服务端启动参数从 main.go 可以看到signaling 支持两个命令行参数参数默认值说明-listen1989TCP 监听端口信令 WebSocket 静态页面共用-root./www静态页面根目录若为相对路径且可执行文件路径为绝对路径则自动拼接到可执行文件所在目录启动日志会输出Signaling ok, root..., home page is ...其中 home page 即演示首页地址。四、信令协议与核心源码剖析4.1 两个 HTTP 端点signaling 在同一个端口上提供了三个路由见 main.go/—— 静态文件服务http.FileServer托管www演示页面/sig/v1/versions—— 返回字符串1.0用于版本探活/sig/v1/rtc—— WebSocket 信令端点核心逻辑所在。4.2 WebSocket 消息帧格式客户端通过ws://host:1989/sig/v1/rtc?room房间名display昵称建立连接见 srs.sig.js。消息为 JSON 文本帧外层带事务 IDtid{ tid: a1b2c3d, msg: { action: join, room: live, display: alice } }服务端响应同样携带tid回包而服务端主动广播的通知notify则不带tid通过event字段区分事件类型。4.3 三种 Actionjoin / publish / control从 main.go 可以完整还原服务端对三类消息的处理join加入房间解析msg.room与msg.display通过sync.Map的LoadOrStore获取/创建房间创建Participant并调用Room.Add加入。Add会做同名检查main.go若房间内已存在相同display则返回错误。成功后向本人返回{action, room, self, participants}房间当前成员列表并向其他成员广播event: join。publish宣布发布找到房间内对应display的参与者将其Publishing置为true随后向其他成员广播event: publish。收到该事件的成员即可知道「有人开始推流了」从而发起 WHEP 拉流。control控制消息携带call与data两个透传字段如call: refresh、call: alert 任意data服务端将其原样广播给房间内其他成员实现演示中的「刷新对方页面」「给对方弹窗」等自定义控制。4.4 服务端数据模型Room 与 Participant服务端的数据模型非常清晰main.goParticipantDisplay昵称、Publishing是否推流中、Out该连接的消息发送通道chan []byteRoomName房间名、Participants成员切片并以sync.RWMutex保护并发读写全局rooms sync.Map以房间名为 key 持有所有房间。连接的读写模型采用双 goroutine 通道读取 goroutine 循环Read消息并送入inMessages处理 goroutine 逐个处理并回包写入 goroutine 循环从outMessages取数据Write回客户端。连接断开时main.go服务端会先向房间内其他成员广播event: leave再将自身从房间移除——这正是「有人离开」通知的来源前端收到leave事件后会隐藏播放器见 one2one.html。4.5 广播通知的完整结构Room.Notifymain.go在加锁快照成员列表后向除发送者外的每个成员投递以下结构{ action: notify, event: join | publish | leave | control, param: , data: , room: 房间名, self: { display: 接收者, publishing: false }, peer: { display: 发送者, publishing: false }, participants: [ 房间内全部成员 ] }其中control事件的param对应call字段、data对应data字段。该结构同时覆盖了self自己、peer对方与participants全量成员足以支撑一对一与多人的房间状态同步。4.6 前端 SDKsrs.sig.js演示页面的信令客户端封装在 srs.sig.js 中提供三个核心 APIconnect(schema, host, room, display)建立ws(s)://host/sig/v1/rtc?room..display..连接返回 Promisesend(message)为消息生成 7 位十六进制tid将{resolve, reject}存入_internals.msgs后发送收到同tid响应即 resolvesrs.sig.jsonmessage(msg)回调用于接收服务端主动广播的 notify 事件。此外SrsRtcSignalingParsesrs.sig.js负责从 URL 解析wss、wsh、wsp、host、room、display、autostart等参数并把与信令无关的查询参数原样透传给媒体层如 WHIP/WHEP 的 token。五、H5 演示与 WHIP/WHEP 媒体流打通5.1 演示页面www/demos/下提供两个核心演示入口见 index.htmlone2one.html一对一视频通话room.html多人视频房间Video Room。两个页面都支持autostarttrue自动启动便于直接粘贴 URL 分享。5.2 一对一流程拆解以 one2one.html 为例完整流程为sig.connect(...)建立信令连接sig.send({action:join, room, display})加入房间返回成员列表startPublish将webrtc://地址转换为 WHIP URLhttp(s)://host:1985|443/rtc/v1/whip/?approomstreamdisplay并调用SrsRtcWhipWhepAsync.publish()推流见 srs.sdk.jssig.send({action:publish, room, display})广播「我在推流」对房间内已存在的publishing成员调用startPlay使用 WHEP URL/rtc/v1/whep/?approomstreamdisplay拉流播放srs.sdk.js之后新成员加入或推流时通过 notify 事件publish、join、leave触发对应的开始/停止播放。媒体 URL 的端口规则one2one.html 中convertToWhipUrl/convertToWhepUrlHTTP 场景走 1985HTTPS 场景走 443。而信令端口默认 1989当演示页面通过 SRS 的 8080 HTTP 服务打开时index.html会自动追加wsp1989让信令连接到 1989 端口见 index.html。5.3 演示 URL 参数一览参数含义默认值hostSRS 媒体服务器地址当前页面 hostnameroom加入的房间名随机生成display用户昵称随机生成wssWebSocket 协议ws/wss依页面协议推断wshWebSocket 服务器地址当前页面 hostnamewspWebSocket 端口当前页面端口autostart页面加载后自动开始关闭5.4 双人以上时的 FFmpeg 合流提示当participants.length 2时one2one 页面会展开「FFmpeg 合流转直播」面板见 one2one.html给出将两路 RTMP 流用-filter_complex overlay合成为一路并推流到rtmp://host/room/merge的完整命令并支持一键将输出对接视频号推流地址填写推流地址与密钥后点击「应用」。这一功能演示了 WebRTC 通话与 RTMP 直播体系的互转能力。六、HTTPS/WSS 生产化httpx-static 反向代理WebRTC 的getUserMedia在非 localhost 环境强制要求 HTTPS浏览器安全策略见 srs.sdk.js 中HttpsRequiredError的抛出逻辑因此将信令升级为 WSS 是实际部署的必经之路。SRS 仓库提供了 httpx-static 组件一个 Go 实现的「HTTP/HTTPS 静态服务器 API 反向代理」可一站完成证书终止与多后端代理。6.1 构建并运行 httpx-staticcd ~/git/srs/trunk/3rdparty/httpx-static make ./objs/httpx-static -http 80 -https 443 -ssk server.key -ssc server.crt \ -proxy http://127.0.0.1:1989/sig -proxy http://127.0.0.1:1985/rtc \ -proxy http://127.0.0.1:8080/其中server.key/server.crt为自签或正式证书若需要生成自签证书httpx-static 的用法说明中给出了openssl genrsaopenssl req -x509的标准命令。6.2 参数说明从 httpx-static/main.go 可确认各参数语义参数短/长说明-t/-httpHTTP 监听端口0表示禁用-s/-httpsHTTPS 监听端口如443-r/-root静态文件根目录默认./html相对可执行文件路径-k/-ssk自签或文件型证书的私钥文件-c/-ssc自签或文件型证书的证书文件-p/-proxy反向代理规则可重复指定多个按路径前缀匹配转发到后端-d/-domainsHTTPS 允许的域名配合 Lets Encrypt 时用于校验留空允许所有-l/-lets是否使用 Lets Encrypt CA否则使用自签证书代理规则的匹配是按路径前缀进行的因此上面三条规则分别把/sigsignaling 信令、/rtcSRS 的 WHIP/WHEP API、/SRS 的 HTTP 服务与静态资源分发到对应后端。README 中的另一条典型规则-proxy http://127.0.0.1:8888/api/webrtc也印证了这一「路径前缀 → 后端」的模型。此外-proxy还支持?trimPrefix/x、?addPrefix/y、?keepUpsreamServertrue、?modifyRequestHostfalse等高级修饰参数见 main.go。6.3 通过 HTTPS/IP 访问演示部署完成后以下地址均可访问演示http://localhost/demos/https://localhost/demos/https://192.168.3.6/demos/此时浏览器页面为 HTTPSwss自动推断为wss媒体 API 走 443443 上/rtc被代理到 SRS 1985信令走wss://.../sig被代理到 signaling 1989三者通过同一域名 端口即可统一访问规避了混合内容与getUserMedia安全限制。七、从 demo 走向自研源码结构给出的启示需要明确的是signaling 官方定位为demoREADME 第一句即声明 A demo WebRTC signaling从源码结构可以推断其面向演示与教学的设计取舍单进程内存态房间数据存于进程内sync.Map无持久化、无水平扩展能力多实例部署时需要自行引入共享状态如 Redis与一致性方案无鉴权与配额join/control不校验身份与权限任何人可加入任意房间生产环境需在信令层或上层网关补充 Token 校验媒体面完全交由 SRSsignaling 本身不处理 SDP/ICE仅做事件转发媒体质量、NAT 穿透STUN/TURN能力取决于 SRS 的 RTC 配置协议简洁可扩展join/publish/controlnotify的四事件模型足够通用新增动作如踢人、举手、录制开关只需在 main.go 的消息分发处仿照现有分支扩展并在 srs.sig.js 的send/onmessage上对接即可。如果需要更完整的多方音视频能力SRS 仓库的trunk/research与srs-bench等目录也提供了压力测试与协议验证的参考实现可作为扩展阅读。总结本文完整走通了 SRS WebRTC signaling 的三种使用形态Docker 一键体验两个容器 一个 URL 即可看到一对一通话、源码构建make产出单二进制-listen/-root两个参数即可运行、HTTPS/WSS 生产化httpx-static 按路径前缀反代/sig、/rtc、/三路后端。同时结合 main.go 与 srs.sig.js 剖析了信令协议/sig/v1/rtcWebSocket 端点、tid事务帧、join/publish/control三种动作、Room/Participant内存模型与join/publish/leave/control四类广播事件。无论你是要快速验证 SRS 的 WebRTC 能力还是要在此 demo 基础上构建自己的房间信令服务本文提供的部署命令、协议字段与源码定位都可以直接作为起点。进一步阅读信令服务完整源码trunk/3rdparty/signaling/main.go前端信令 SDKtrunk/3rdparty/signaling/www/demos/js/srs.sig.jsWHIP/WHEP 媒体 SDKtrunk/3rdparty/signaling/www/demos/js/srs.sdk.js演示页面源码trunk/3rdparty/signaling/www/demos/one2one.htmlHTTPS/WSS 反代组件trunk/3rdparty/httpx-static/main.goSRS RTC 配置示例trunk/conf/rtc.conf【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考