WebRTC 服务器之Janus架构分析
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 等不同终端设备，提高了系统的兼容性和可用性。 |
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 数据流架构
下图说明了在典型的 WebRTC 交互期间通过 Janus 架构的完整数据流。此流程展示了 Janus 的不同层如何协同工作以处理 WebRTC 信令、媒体交换和特定于应用程序的逻辑。各个组件之间的干净分离实现了灵活性和可扩展性。
英文版：
学习资料分享
0voice · GitHub