737 积分	0 好友	101 主题

基于RTCPilot与WHIP协议构建可扩展的低延时直播集群方案

发表于 6 小时前 | 查看: 1| 回复: 0

今天我们来聊聊如何利用 WebRTC 推流协议 WHIP（WebRTC-HTTP Ingestion Protocol）来搭建一个完整的低延时直播解决方案。你是否也遇到过传统方案在扩展性上的瓶颈？让我们一起来探索一个更优的路径。

采用 WebRTC 实现低延时直播，首要挑战便是单实例 SFU（Selective Forwarding Unit）的扩展能力局限。

想象一下这个场景：你有一台配置为 16 核 32G 的服务器（Server A）。但问题是，许多主流的 SFU，如 SRS、mediasoup 等，其核心媒体处理逻辑通常是单线程运行的。

单线程SFU架构下的容量局限示意图

如图所示，SFU 1 接收来自 OBS 的 WHIP 推流后，所有 RTC 流的转发分发都被限制在这一个 SFU 实例内。这意味着，即使单个 SFU 实例能勉强支撑 1000 路拉流，整个解决方案的容量天花板也就被钉死在了 1000 路观众。

当然，也有像 Janus 这样支持多线程运行的 SFU，能够充分利用服务器的多核 CPU 资源。

然而，Janus 本身并不原生支持集群部署。这导致低延时直播的规模上限，从单实例上限变成了单台物理设备的上限。如果单核能处理 1000 路，理论上 16 核能达到 16000 路，但实际上由于分布式系统内部开销和资源争用，往往难以达到这个理想值。

多线程SFU仍受限于单台设备的容量

如上图所示，Server A 的多核资源或许能被利用，但旁边 Server B 的计算和网络资源却完全闲置，无法参与到同一场直播的流量分发中，造成了资源浪费。

那么，有没有办法突破单机限制，实现真正的水平扩展呢？今天要介绍的 RTCPilot 开源项目，正是为了应对上述挑战而生的低延时直播解决方案。

RTCPilot 是一个跨平台的 WebRTC SFU，支持 Windows、Linux 和 macOS。更重要的是，它是开源领域中少数提供完整集群方案的 WebRTC SFU 之一。

项目地址如下：

服务端：https://github.com/runner365/RTCPilot
客户端：https://github.com/runner365/webrtc_js_client

国内镜像：

服务端：https://gitee.com/xiaoq_bj/rtcpilot.git
客户端：https://gitee.com/xiaoq_bj/webrtc_js_client

RTCPilot 同时支持 WHIP 推流（即 WebRTC 推流）和集群功能。WHIP 负责高质量、低延迟的流注入，集群则负责无限扩展分发能力，两者结合构成了服务端完整的解决方案。

其支持 WebRTC 级联的集群架构主要由以下几部分组成：

RTCPilot集群架构示意图

Pilot Center：作为控制中心，它接收来自各个 RTCPilot SFU 实例的 WebSocket 注册，并负责在所有 SFU 间同步房间、用户信息以及 RTC 流的状态信息。
RTCPilot SFU：这是核心的媒体转发节点。它既接收 OBS 的 WHIP 推流，也接受最终客户端的拉流连接。每个 SFU 都会将本节点的房间、用户和流信息上报给 Pilot Center。最关键的是，不同的 SFU 之间可以通过 RTP 协议直接转发音视频流，实现跨节点的流量疏导。
客户端（Web前端）：通过 WebSocket 与某个 SFU 建立信令连接，通过 WebRTC 协议接入媒体。客户端可以订阅和播放房间内的任何 WebRTC 流，无论这个流最初被推到了哪个 SFU 节点。

通过这种架构，我们可以根据实际并发观众量的需求，动态地扩展 SFU 节点的数量，从而弹性地满足大规模低延时直播的容量需求，彻底打破单机性能瓶颈。

总结来说，WHIP 协议确保了推流端的低延迟与高画质，而 RTCPilot 的 SFU 集群架构则提供了几乎无限的水平扩展能力。两者的结合，最终成就了一套能够大规模部署、稳定可靠的低延时直播系统。如果你正在为直播系统的扩展性发愁，不妨到云栈社区的相关板块深入探讨一下这类架构的更多实践细节。