WebRTC 服务器之Janus架构分析

C9程序猿

已于 2025-05-04 16:43:54 修改

阅读量1k

点赞数 12

文章标签： webrtc 服务器架构 janus

于 2025-05-03 18:24:00 首次发布

本文链接：https://blog.csdn.net/weixin_50873490/article/details/147685129

版权

1. Webrtc三种类型通信架构

1.1 1 对 1 通信

1 对 1 通信模型设计的主要⽬标是尽量让两个终端进⾏直联，这样即可以节省服务器的资源，⼜可以提⾼⾳视频的服务质量。WebRTC ⾸先尝试两个终端之间是否可以通过 P2P 直接进⾏通信，如果⽆法直接通信的话，则会通过 STUN/TURN 服务器进⾏中转，如下图：

1.2 多对多通信

Mesh 架构：适合刚学习 WebRTC 的场景，简单易实现，但实际应用中因上行带宽占用大、线性资源占用等问题，超过 4 人时问题明显，几乎无人在真实场景中使用。

MCU 架构：硬件 MCU 曾在视频会议广泛应用，技术成熟，但价格昂贵，且随着互联网发展逐步被淘汰；软 MCU 如 FreeSWITCH 虽存在，但因 CPU 消耗大，真正使用者不多。

SFU 架构：近年来流行，是 WebRTC 多方通信媒体服务器的主流架构，具有高灵活性和高性能，配合 Simulcast 或 SVC 模式可更好地适应不同网络和终端，被多数公司采用。

Janus的多方视频通话使用VideoRoom插件，采用SFU架构。

维度	mesh(P2P)	SFU	MCU
延迟	最低（直连）	中等（服务器中转）	最高（处理流程复杂）
带宽消耗	上行压力大（N²增长）	下行压力大（服务器承担）	整体最低（单一流）
扩展性	差（适合1:1）	优（适合中小型会议）	一般（适合大型会议）
服务器成本	低（仅需穿透辅助）	中（高带宽需求）	高（计算+带宽双重压力）
终端要求	需处理多流解码	需多流解码能力	仅需解码单一流
灵活性	高（端到端控制）	高（自由订阅流）	低（布局固定）
典型应用	微信语音、Skype 1:1	Zoom、腾讯会议	传统硬件视频会议系统
特点	多对多，Mesh 结构	发布订阅	混流集合

1.2.1 架构优点

架构方案	优势
Mesh 架构	- 无需中转服务器，直接利用 WebRTC 通信模型，无需额外开发媒体服务器，降低了开发成本和复杂度。 - 充分利用客户端的带宽资源，将服务器端的带宽压力分散到各客户端，节省了服务器成本。 - 原有通信模型的简洁性，这种架构充分利用了现有的 WebRTC 通信模型，结构相对简单，易于实现和维护。
MCU 架构	- 技术成熟，在硬件视频会议领域应用广泛，技术相对成熟可靠，能够提供稳定的通信服务。 - 兼容性强，作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备之间的差异化，满足更多客户的集成需求，提升用户体验和产品竞争力。 - 统一画面输出，将多路视频混合成一路，所有参与者看到的是相同的画面，有助于提供一致的客户体验。
SFU 架构	- 低资源消耗，数据包直接转发，不需要进行编解码操作，对 CPU 资源消耗很小，降低了服务器的硬件成本和运营成本。 - 低延迟，数据包直接转发极大地降低了延迟，提高了通信的实时性，适合对实时性要求较高的应用场景。 - 灵活性高，可以根据终端下行网络状况进行流控，如根据带宽、网络延时情况选择性地丢弃一些媒体数据，以保证通信的连续性，更好地适应不同的网络状况和终端设备。 - 支持多种模式，许多 SFU 实现支持 SVC 模式和 Simulcast 模式，能够更好地适配 WiFi、4G 等不同网络状况，以及 Phone、Pad、PC 等不同终端设备，提高了系统的兼容性和可用性。

架构

方案

优势

Mesh 架构

- 无需中转服务器，直接利用 WebRTC 通信模型，无需额外开发媒体服务器，降低了开发成本和复杂度。

- 充分利用客户端的带宽资源，将服务器端的带宽压力分散到各客户端，节省了服务器成本。

- 原有通信模型的简洁性，这种架构充分利用了现有的 WebRTC 通信模型，结构相对简单，易于实现和维护。

MCU 架构

- 技术成熟，在硬件视频会议领域应用广泛，技术相对成熟可靠，能够提供稳定的通信服务。

- 兼容性强，作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备之间的差异化，满足更多客户的集成需求，提升用户体验和产品竞争力。

- 统一画面输出，将多路视频混合成一路，所有参与者看到的是相同的画面，有助于提供一致的客户体验。

SFU 架构

- 低资源消耗，数据包直接转发，不需要进行编解码操作，对 CPU 资源消耗很小，降低了服务器的硬件成本和运营成本。

- 低延迟，数据包直接转发极大地降低了延迟，提高了通信的实时性，适合对实时性要求较高的应用场景。

- 灵活性高，可以根据终端下行网络状况进行流控，如根据带宽、网络延时情况选择性地丢弃一些媒体数据，以保证通信的连续性，更好地适应不同的网络状况和终端设备。

- 支持多种模式，许多 SFU 实现支持 SVC 模式和 Simulcast 模式，能够更好地适配 WiFi、4G 等不同网络状况，以及 Phone、Pad、PC 等不同终端设备，提高了系统的兼容性和可用性。

Simulcast 模式就是指视频的共享者可以同时向 SFU 发送多路不同分辨率的视频流（⼀般为三路，如 1080P、720P、360P）。⽽ SFU 可以将接收到的三路流根据各终端的情况⽽选择其中某⼀路发送出去。例如，由于 PC 端⽹络特别好，给 PC 端发送 1080P 分辨率的视频；⽽移动⽹络较差，就给 Phone 发送 360P 分辨率的视频。 Simulcast 模式对移动端的终端类型⾮常有⽤，它可以灵活⽽⼜智能地适应不同的⽹络环境。

SVC（ Scalable Video Coding）是可伸缩的视频编码模式。与 Simulcast 模式的 SVC 模式是同时传多路流不同，在视频编码时做“ ⼿脚” 。它在视频编码时将视频分成多层—— 核⼼层、中间层和扩展层。上层依赖于底层，⽽且越上层越清晰，越底层越模糊。在带宽不好的情况下，可以只传输核⼼层，在带宽充⾜的情况下，可以将三层全部传输过去。

2. Janus 系统架构

Janus 被设计为通用的 WebRTC 服务器，专注于模块化和可扩展性。它提供必要的 WebRTC 基础设施，同时将特定的应用程序逻辑委托给插件。这种分离使 Janus 变得轻量级和灵活，无需更改内核即可支持广泛的用例。

架构的关键原则：

模块化设计：核心组件通过定义明确的接口清晰分离
基于插件的可扩展性：所有特定于应用程序的逻辑都在插件中实现
多传输支持：用于客户端交互的多种通信协议
媒体和信令分离：WebRTC 媒体处理和信令逻辑之间的明确分离

全局架构图如下：

2.1 核心组件

Janus 核心处理 WebRTC 和会话管理基础知识，提供插件和传输构建的基础基础设施。

2.1.1 会话和句柄模型

Janus 中最重要的架构概念之一是 session/handle 模型：

会话：表示用户与 Janus 的连接
Handle：表示用户与特定插件之间的连接
PeerConnection：与句柄关联的 WebRTC 连接
transaction：表示当前消息信息的唯一句柄

这种关系在用户、插件和媒体连接之间建立了明确的分离。客户端与 Janus 创建会话。在此会话中，客户端可以附加到多个插件（创建句柄）。每个句柄都有自己的 WebRTC PeerConnection，用于管理媒体交换。

2.1.2 会话管理

会话是客户端连接到 Janus 的核心抽象。会话管理系统处理：

会话创建和销毁
会话超时（可配置，默认 60 秒）
会话声明（在传输断开连接后恢复会话）

每个会话都包含句柄，这些句柄是会话和插件实例之间的桥梁。会话层维护客户端与其插件附件之间的关系。

2.1.3 Media Handl管理

Janus 的媒体处理层负责 WebRTC 连接和媒体处理。ICE （Interactive Connectivity Establishment）组件处理：

候选人聚集和交流
NAT 遍历
连接建立
用于安全连接的 DTLS 协商
用于加密媒体的 SRTP

媒体路径处理：

RTP/RTCP 数据包从 routing 到plugins
SDP offer/answer 处理
媒体统计和监控
数据包重传的 NACK 处理
TWCC（全交通拥堵控制）

2.2 插件系统

Janus 提供了一个插件架构，允许开发人员在不修改核心代码库的情况下实现各种 WebRTC 应用程序。插件向 Janus 核心注册，并为消息处理和媒体处理等事件实施回调。内核仅负责 WebRTC 连接和数据包路由，而插件则决定媒体会发生什么并实现应用程序逻辑。

Janus 包含的常见插件：

VideoRoom：用于多方视频会议的选择性转发单元（SFU）
AudioBridge：具有混音功能的音频会议
流式处理：媒体流式处理（RTP、RTSP、HLS 源）
SIP：用于 WebRTC 到 SIP 互作性的 SIP 网关
EchoTest：用于测试 WebRTC 功能的简单 echo 测试插件
TextRoom：基于数据通道的文本聊天室
RecordPlay：WebRTC 会话的录制和播放

插件 API 公开了允许插件执行以下作的函数：

接收和发送媒体（RTP/RTCP）
与客户交换消息
管理 WebRTC 连接
处理 SDP offers/answers
通过 Data Channel 发送和接收数据

2.3 传输层

传输层提供客户端和 Janus 服务器之间的通信通道。可以同时使用多种传输机制，从而灵活地选择客户端连接到 Janus 的方式。

HTTP/REST：用于请求-响应交互的传统 REST API
WebSockets：实时双向通信
RabbitMQ：基于消息队列的通信
MQTT：轻量级发布-订阅消息传递
Unix 套接字：同一台机器上的进程间通信

所有传输都实现相同的 API，无论底层协议如何，都为核心提供一致的接口。这允许客户端选择最适合其需求的传输机制。

传输层负责：

身份验证请求（如果已配置）
解析和验证 JSON 消息
将请求路由到适当的会话/句柄
将事件和响应返回给客户端

2.4 事件处理程序

事件处理程序为外部应用程序提供了一种监视和响应 Janus 中发生的事件的方法。这些事件可以包括会话创建/销毁、媒体统计、特定于插件的事件等。事件处理程序（如传输和插件）在启动时动态加载，并在内核中注册。它们从核心接收事件，并将其转发到外部系统进行监控、记录或处理。

2.5 实用程序和工具

2.5.1 实用程序

Janus 提供了多种后处理工具，用于将录音转换为可以使用常见媒体播放器播放的标准格式。实用程序允许您将 Janus Media Recorder （）文件转换为标准媒体格式。

Supported Output Formats 支持的输出格式

输入编解码器	输出扩展名	描述
VP8/VP9	.webm, .mkv	WebM 容器格式用于 VP8/VP9 视频
H.264	.mp4, .mkv	MP4/Matroska 容器用于 H.264 视频
H.265	.mp4, .mkv	MP4/Matroska 容器用于 H.265 视频
AV1	.mp4, .mkv	MP4/Matroska 容器用于 AV1 视频
Opus	.opus, .ogg, .mka	Opus 音频的各种容器
G.711	.wav	WAV 容器用于 G.711 音频
G.722	.wav	WAV 容器用于 G.722 音频
L16	.wav	WAV 容器用于 L16（PCM）音频
文本数据	.srt	数据通道文本的 SRT 字幕格式

基本用法：

./janus-pp-rec /path/to/source.mjr /path/to/destination.[opus|ogg|mka|wav|webm|mkv|mp4|srt]
#分析录制信息而不进行处理：
./janus-pp-rec --json /path/to/source.mjr    # Print JSON header
./janus-pp-rec --header /path/to/source.mjr  # Parse header only
./janus-pp-rec --parse /path/to/source.mjr   # Parse without processing

Janus 还包括用于在 Janus 录音和数据包捕获格式之间进行转换的实用程序：

mjr2pcap：将 Janus 记录转换为 PCAP 格式，以便在 Wireshark 等工具中进行分析
pcap2mjr：将 PCAP 文件转换为 Janus 录制格式

2.5.2 测试工具

Janus 提供了测试工具来验证 WebRTC 网关的功能和性能。aiortc 测试套件！该目录包含使用 WebRTC 功能测试库的基于 Python 的测试工具。test/aiortc

测试套件的 Python 依赖项：

websockets==15.0
aiortc==1.10.1

可以使用提供的帮助程序脚本执行测试套件：

./test_aiortc.sh echo.py ws://localhost:8188/

3.1 数据流架构

下图说明了在典型的 WebRTC 交互期间通过 Janus 架构的完整数据流。此流程展示了 Janus 的不同层如何协同工作以处理 WebRTC 信令、媒体交换和特定于应用程序的逻辑。各个组件之间的干净分离实现了灵活性和可扩展性。

英文版：

学习资料分享

0voice · GitHub