从webrtc到janus简介

1.基础知识

1.1 信令的基础知识

在 WebRTC（Web Real-Time Communication）中，信令（Signaling）是实现浏览器之间实时通信的关键机制，负责在通信双方（或多方）之间传递控制信息，协调媒体流的建立、管理和释放。

由于 WebRTC 基于浏览器端直接通信（P2P），但浏览器无法直接发现和连接对方，因此需要通过信令服务器（或自定义信令通道）中转信息，完成以下核心任务：

WebRTC 信令的核心功能

交换元数据（协商媒体参数）
- 通信双方需先协商支持的媒体类型 （如音频、视频、数据）、编码格式 （如 H.264、VP8）、传输协议（如 SRTP 加密）等参数。
- 通过 SDP（Session Description Protocol，会话描述协议） 格式传递这些信息，例如：
  sdp 复制代码
```
v=0
o=- 12345 1 IN IP4 192.168.1.1
s=WebRTC Session
c=IN IP4 0.0.0.0
t=0 0
m=video 9999 RTP/SAVPF 100 101
```
获取和交换网络连接信息（NAT 穿越）
- 浏览器通常位于防火墙或 NAT 设备后，需通过 ICE（Interactive Connectivity Establishment，交互式连接建立） 协议获取本地和候选中继地址（如 STUN/TURN 服务器分配的地址），并通过信令交换这些地址，尝试建立 P2P 连接。
控制通信流程
- 管理会话的生命周期，例如：
  - 发起呼叫（Offer）、响应呼叫（Answer）；
  - 中途添加/移除媒体流（如视频会议中动态加入新参与者）；
  - 断开连接或处理异常中断。

WebRTC 信令的关键流程

以双方通信为例，信令交互的典型步骤如下：

1. 发起方（A）生成 Offer

A 通过 RTCPeerConnection 创建会话描述（SDP Offer），包含自身支持的媒体参数和 ICE 候选地址。
A 将 Offer 通过信令服务器发送给接收方（B）。

2. 接收方（B）生成 Answer

B 解析 Offer，匹配自身支持的媒体参数，生成 SDP Answer（可能包含本地 ICE 候选地址），并通过信令返回给 A。

3. 交换 ICE 候选地址

A 和 B 各自收集本地 ICE 候选地址（如私有 IP、STUN 分配的公网 IP），通过信令逐次交换。
双方尝试通过这些地址建立 P2P 连接（称为 ICE 候选检查），最终选择最优路径。

4. 建立连接

当双方成功协商媒体参数并打通网络连接后，RTCPeerConnection 状态变为 connected，开始传输媒体流。

信令协议与实现方式

WebRTC 本身不强制规定信令协议，开发者需自行实现信令通道，常见方案包括：

1. 自定义协议（如基于 HTTP/WS）

使用 WebSocket（WS） 或 HTTP Long Polling 搭建信令服务器，直接传输 JSON 格式的信令消息，例如：

json 复制代码

{
  "type": "offer",
  "sdp": "v=0 o=- 1234...", // SDP 内容
  "candidate": "candidate:1234 1 udp 1697395967 192.168.1.1 5000 typ host" // ICE 候选地址（可选）
}

2. 标准协议（如 SIP、XMPP）

集成传统通信协议（如 SIP）实现信令交互，适用于与现有电信网络对接的场景，但复杂度较高。

3. 开源信令服务器

使用开源方案快速搭建信令服务，例如：
- SimpleWebRTC：封装信令逻辑，简化开发；
- Kurento 、Janus：支持媒体中继和信令管理，适用于多人会议场景。

信令服务器的作用

中转信令消息：浏览器无法直接通信，需通过服务器转发 Offer/Answer 和 ICE 候选地址。
辅助 NAT 穿越：配合 STUN/TURN 服务器提供公网地址，帮助建立 P2P 连接（TURN 服务器还可作为中继转发媒体流）。
管理会话状态：记录参与者列表、会话 ID 等，支持多人通信（如视频会议）的信令协调。

总结

WebRTC 信令是浏览器实时通信的"桥梁"，核心使命是协商媒体能力 和打通网络连接。开发者需根据场景选择信令协议（如自定义 WS 或 SIP），并搭建信令服务器完成消息中转。理解信令流程（尤其是 SDP 和 ICE 的交互）是开发 WebRTC 应用（如视频会议、实时聊天）的关键。

1.2 三种架构

核心概念解析

带宽的定义

带宽本质上是网络传输数据的 "管道粗细"，上行带宽即 "上传管道的最大流量"。

例如：若上行带宽为 1 Mbps，理论上每秒最多可上传约 128 KB 的数据（1 Mbps = 1024 kbps，8 bit = 1 Byte，故 1024 ÷ 8 = 128 KB/s）。

上行带宽：用户向外部网络发送数据的速率（如上传文件、直播推流、发送消息）。
下行带宽：用户从外部网络接收数据的速率（如下载文件、看视频、浏览网页）。
常见场景对比：
普通用户：下行带宽需求通常远大于上行（如看视频需高下行）。
直播 / 视频会议：上行带宽至关重要（需稳定上传音视频流）

1.2.1 MESH

Mesh（网格）通信模型 是一种点对点（P2P）的网络架构，其中所有终端（节点）直接互联，形成一个 "网状" 拓扑结构。在多人通信场景中，每个终端都与其他所有终端直接建立连接，无需通过中央服务器中转媒体数据，仅依赖服务器完成信令交互（如会话建立、NAT 穿越等）。

Mesh 方案的核心原理

以 N 个终端为例：

每个终端需要与其他 N-1 个终端建立独立的 P2P 连接（如 WebRTC 的 RTCPeerConnection）。
媒体流传输：每个终端将自己的音视频流直接发送给其他所有终端，同时接收来自其他终端的流。
服务器角色：仅负责信令交互（如 SDP 协商、ICE 候选地址交换）和 STUN/TURN 服务（辅助 NAT 穿越），不参与媒体数据中转。（只需要stun和turn中继）
优势
无需媒体服务器
直接利用 WebRTC 原生 P2P 能力，省去开发或维护媒体服务器的成本（如 Janus、Mediasoup 等）。
适合轻量级场景：如小规模会议（≤4 人）、简单互动应用。
节省服务器资源
服务器仅处理信令，无需承担媒体转发的带宽和计算压力，大幅降低服务器成本（尤其是专线带宽费用）。
去中心化特性
无单点故障：即使部分节点断开，其他节点仍可保持连接（需额外实现重连机制）。
缺点与局限性
客户端资源消耗随人数剧增
- 带宽占用：每个终端的上行带宽需承载 N-1 路流（如 4 人会议需发送 3 路流，8 人则需 7 路），导致带宽需求呈线性增长。
- 硬件负载：CPU 和内存需处理多路编解码、网络传输，可能导致卡顿、发热甚至崩溃（尤其在移动设备上）。
- 实践限制：通常认为 Mesh 方案仅适用于 4 人以下场景，超过后体验显著下降。
NAT 穿越复杂度高
若部分终端无法通过 STUN/TURN 实现 P2P 直连（如严格防火墙限制），需依赖 TURN 服务器中转数据，但此时每路流都需独立中转，导致服务器带宽压力反增，且延迟升高。
信令复杂度与扩展性差
每个终端需维护多个 RTCPeerConnection 对象，信令逻辑（如添加 / 删除参与者）随人数指数级复杂。
难以支持大规模场景（如百人会议），需切换至其他架构（如 SFU、MCU）。

省服务器带宽：✅ （核心优势）

省终端带宽：❌ （通常更消耗终端上行）

1.2.2MCU ⽅案

一、MCU 核心原理与架构

MCU（Multipoint Control Unit，多点控制单元）是一种集中式音视频处理方案，通过解码 - 混流 - 编码流程实现多人通信。其架构为星形拓扑：所有终端（B1、B2 等）将媒体流发送至 MCU 服务器，服务器处理后再分发给所有参与者。

关键处理逻辑：

接收流：服务器接收每个终端的音视频流（如 B1、B2 的流）。

解码：将各路流从原始编码格式（如 H.264、VP8）解码为原始音视频数据（如 YUV 图像、PCM 音频）。

混流：将多路音视频数据混合成一路（如将 B1 和 B2 的画面拼接成画中画，音频混音成单声道）。

重新编码：将混流后的音视频数据编码为统一格式（如 H.264），便于分发。

分发流：将混流后的单路流发送给所有参与者（包括发送端自身，需排除自身流以避免回声）。

MCU 的优势

技术成熟，兼容性强
硬件 MCU 在传统视频会议（如 Cisco、Polycom）中应用数十年，软件 MCU 可复用成熟逻辑，降低开发门槛。
通过解码 - 重编码流程，可适配不同终端的编解码差异（如兼容 H.264 和 VP9 设备互通），提升系统兼容性。
统一画面，用户体验一致
所有参与者收到的是单一混流画面（如 "多宫格" 或 "主讲人 + 辅流" 布局），画面布局可控，适合需要强管控的场景（如远程教学、企业培训）。
避免 Mesh 方案中 "每个终端画面独立" 导致的混乱，用户无需手动切换多窗口。
集中式管控能力
服务器可灵活控制混流逻辑（如切换主讲人、调整画面布局），支持权限管理（如静音、禁言某参与者）。

MCU 的局限性

高 CPU 消耗，容量受限
每路流的解码、混流、重编码均需大量计算资源。例如，10 路 1080P 流的混流可能需要数十核 CPU，普通服务器难以支撑。
实际容量上限：通常单机软件 MCU 支持 10-20 路 720P 流，超过后需集群部署，成本激增。
延迟高，实时性差
解码 - 混流 - 编码流程引入额外延迟（通常增加 200-500 ms），不适用于对实时性要求高的场景（如游戏语音、互动直播）。
带宽优势不明显，灵活性低
服务器带宽：需转发单路混流给所有参与者，带宽消耗为混流码率 × 参与人数（与 SFU 方案相同）。
终端带宽：发送端仅需上传 1 路流（优于 Mesh），但接收端需下载 1 路混流（与 Mesh/SFU 一致）。
画面固定：混流布局一旦生成，终端无法自定义视图（如单独查看某路流），灵活性低于 SFU 方案。

1.2.3 SFU

谁来编码：由浏览器 / 终端设备（如手机、电脑）的 WebRTC 栈编码。

SFU 核心原理与架构

SFU（Selective Forwarding Unit，选择性转发单元）是一种介于 Mesh 和 MCU 之间的 WebRTC 架构，其核心思想是：服务器仅转发媒体流，不进行解码和混流。

关键处理逻辑：

接收流：服务器接收每个终端（B1、B2 等）发送的音视频流。
选择性转发：服务器将每路流直接转发给其他终端（不做解码或修改），但可根据终端网络状况调整转发策略（如降码率、丢包）。
终端自行渲染：每个终端接收多路原始流，并在本地渲染（如显示为多宫格画面）。

SFU 的核心优势

低延迟，高实时性
无需解码和重编码，服务器仅作为 "数据包转发器"，延迟显著低于 MCU（通常仅增加 50-100 ms）。
适合实时互动场景：如视频会议、直播连麦、在线游戏。
资源消耗少，可扩展性强
服务器 CPU 负载极低（仅转发），单机可支持数百至上千路流（取决于网络带宽）。
对比 MCU：同样配置的服务器，SFU 支持的并发数是 MCU 的 10 倍以上。

SFU 的局限性

终端渲染压力大
每个终端需同时接收并渲染多路流（如 4 人会议需处理 3 路流），对设备性能要求较高。
移动设备可能卡顿：低端手机或弱网环境下，同时解码多路流易导致性能下降。
画面一致性差
各终端独立渲染，可能因网络波动导致画面不同步（如 A 看到 B 的画面有延迟，而 C 看到 B 的画面正常）。
录制和回放复杂：需单独处理每路流，无法直接生成统一的 "多宫格视频"（需后期混流）。
带宽利用率较低
服务器需为每个接收端单独转发一路流，总带宽消耗 = 单路流码率 × 参与人数 ×（参与人数 - 1）。
对比 MCU：MCU 的总带宽 = 混流码率 × 参与人数（通常混流码率低于多路原始流之和）。

1.2.4 总结

以下是对 SFU、Mesh、MCU 三种多人通信架构的总结与对比，从核心原理、优缺点、适用场景等维度展开：

核心原理对比

方案	数据流向	服务器角色	媒体处理方式	终端负载
Mesh	终端 ↔ 终端	仅信令中转	无（直连）	极高（发送 N-1 路，接收 N-1 路）
SFU	终端 → 服务器 → 终端	选择性转发原始流	不解码、不混流	高（渲染多路流）
MCU	终端 → 服务器 → 终端	解码、混流、重编码	集中处理为单路流	低（仅接收单路混流）

关键指标对比

维度	Mesh	SFU	MCU
延迟	最低（直连）	低（转发延迟）	高（编解码延迟）
服务器带宽	无（终端直连）	中（单流 × 参与人数）	中（混流 × 参与人数）
终端上行带宽	极高（发送多路流）	低（仅发送 1 路）	低（仅发送 1 路）
服务器 CPU	无	低（转发）	极高（编解码）
画面一致性	差（独立渲染）	较差（独立渲染）	强（统一混流）
最大容量	≤6 人	数十至数千人	≤20 人
部署成本	最低（无需服务器）	中（需转发服务器）	高（需高性能服务器）

典型应用场景

Mesh：小规模轻量级场景（如 1v1 聊天、4 人以内会议）。
SFU：大规模实时互动（视频会议、直播连麦、在线课堂）。
MCU：强管控、低并发、需统一画面的场景（传统视频会议、远程教学）。

优势与不足

方案	主要优势	主要不足
Mesh	1. 无需媒体服务器 2. 去中心化，无单点故障	1. 终端带宽/性能要求极高 2. 规模受限（≤6 人） 3. NAT 穿透复杂
SFU	1. 低延迟、高可扩展性 2. 灵活适配异构网络 3. 服务器负载低	1. 终端渲染压力大 2. 画面一致性差 3. 录制和回放复杂
MCU	1. 统一画面，用户体验一致 2. 兼容性强（屏蔽编解码差异） 3. 集中管控能力	1. 高延迟（编解码开销） 2. 服务器成本高 3. 容量受限（≤20 人）

决策建议

小规模、低成本场景 （≤4 人）：优先选 Mesh。
大规模实时互动 （数十至数千人）：优先选 SFU（如 Mediasoup、Janus）。
需统一画面/强管控 （如远程教学、企业会议）：选 MCU（如传统硬件会议系统或软件 MCU）。
混合场景 ：结合 SFU+MCU（如小房间用 SFU，需混流时切 MCU）。

主流实现工具

Mesh：WebRTC 原生 API（无需额外服务器）。
SFU：Mediasoup、Janus、Kurento、SRS。
MCU：传统硬件厂商（Cisco、Polycom）、软件方案（FreeSWITCH）。

1.3 SVC 模式和 Simulcast 模式

一、Simulcast（多流传输）
核心原理：

发送端同时生成多路不同分辨率 / 码率的独立视频流（如 1080P、720P、360P），并将这些流同时上传至服务器（如 SFU）。服务器根据接收端的网络条件和设备能力，选择其中一路流转发给对应终端。

二、SVC（可伸缩视频编码）

核心原理：

发送端将视频编码为分层结构的单一数据流，通常分为：

核心层（Base Layer）：最低分辨率和码率，保证基本观看（如 360P）。
增强层（Enhancement Layers）：叠加在核心层之上，逐步提升画质（如 720P、1080P）。
接收端可根据网络状况选择接收全部层或部分层：
弱网环境：仅接收核心层，保证视频流畅。
强网环境：接收全部层，获取高清画质。

PC1 共享的是⼀路视频流，编码使⽤ SVC 分为三层发送给 SFU。SFU 根据接收端的情况，

发现 PC2 ⽹络状况不错，于是将 0、1、2 三层都发给 PC2；发现 Phone ⽹络不好，则只将 0 层发给Phone。这样就可以适应不同的⽹络环境和终端类型了。

1.4 websocket

WebSocket 从 HTTP 演化而来，是为解决 HTTP 在实时双向通信场景的不足，以下是具体演化过程：

一、HTTP 局限性催生变革需求

早期 HTTP（如 HTTP/1.0 ）设计为无状态、短连接，客户端发请求、服务器回响应后连接就关闭。这种模式在静态资源传输（如网页、文件下载）场景很合适，但面对实时交互需求（如在线聊天、实时协作），弊端尽显：

单向通信 ：只有客户端主动发请求，服务器无法主动给客户端推数据。想实现"服务器有新消息就通知客户端"，只能让客户端轮询/长轮询，效率低、冗余请求多。
连接频繁重建：每次请求都要重新建立 TCP 连接（三次握手），在高频交互场景（如实时游戏），耗时和资源消耗大。

为突破这些限制，WebSocket 等协议逐步演化出来，核心是让服务器和客户端能高效双向通信。

二、WebSocket 基于 HTTP 握手升级

WebSocket 并非完全抛弃 HTTP，而是复用 HTTP 握手流程完成协议升级，具体分两步：

客户端发起 HTTP 升级请求
客户端（如浏览器）想建立 WebSocket 连接时，先发送特殊的 HTTP 请求，关键头信息：

http 复制代码

GET /ws-endpoint HTTP/1.1
Host: example.com
Upgrade: websocket  // 核心！告诉服务器想升级到 WebSocket 协议
Connection: Upgrade  // 配合 Upgrade，表明要切换协议
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==  // 用于服务端校验，防止误连
Sec-WebSocket-Version: 13  // 指定 WebSocket 版本

这里的 Upgrade: websocket 和 Connection: Upgrade 是"协议升级"的关键标识，把原本 HTTP 短连接的意图，改成"想持久化双向通信"。

服务器响应协议升级
服务器识别到 Upgrade 请求后，验证 Sec-WebSocket-Key（按规则生成 Sec-WebSocket-Accept 响应），若同意升级，返回：

http 复制代码

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  // 服务端校验后的结果

当客户端收到 101 Switching Protocols 响应，就说明HTTP 连接已成功升级为 WebSocket 连接，后续通信不再用 HTTP 协议，转而使用 WebSocket 自身的帧格式（如二进制帧、文本帧），实现全双工（客户端和服务器可随时互发消息）、长连接。

三、演化后的本质差异与优势

升级为 WebSocket 后，和 HTTP 有了根本区别：

对比项	HTTP	WebSocket
连接特性	短连接（请求-响应后关闭）	长连接（一次握手，持久通信）
通信方向	单向（客户端主动请求）	全双工（双向实时交互）
协议依赖	基于 HTTP 协议本身	复用 HTTP 握手，后续自主协议
适用场景	静态资源、API 调用等	实时聊天、直播互动、游戏等

HTTP/1.1 的长连接是 "TCP 连接的复用"，核心为：

连接复用：一次 TCP 连接（三次握手）建立后，可在这条连接上发送多个 HTTP 请求 - 响应（比如浏览器加载网页时，同一域名的 CSS、JS、图片等资源，可复用一个 TCP 连接依次请求）。

仍为 "请求 - 响应" 模式：必须由客户端先发起请求，服务器再被动响应，服务器无法主动给客户端发数据。

连接会超时关闭：若长时间无新请求，服务器或客户端会主动关闭 TCP 连接（可通过 Keep-Alive 头设置超时，如 Keep-Alive: timeout=20 表示 20 秒无活动则关闭）。

2 janus 流媒体服务器

2.1 简介

Janus 是一款基于 WebRTC（Web 实时通信）的开源流媒体服务器，由意大利公司 Meetecho 开发，主要用于构建实时音视频通信、直播、录制等应用场景。它支持多种传输协议和编解码格式，具备高灵活性和可扩展性，被广泛应用于视频会议、在线教育、实时互动直播等领域。

核心功能与特性

多协议支持
支持 WebRTC 标准，兼容浏览器端和移动端的实时通信。
同时支持传统协议如 SIP（会话初始协议）、RTSP（实时流协议）等，可作为协议转换网关。
多种应用模式
- Peer-to-Peer（P2P）：直接在客户端间建立连接，减少服务器负载。
- Multipoint（多点通信）：支持多人会议，通过 SFU（Selective Forwarding Unit）模式转发媒体流，避免传统 MCU（Multipoint Control Unit）的高计算消耗。
- 直播与录制：支持将媒体流推送到 RTMP（如 YouTube、Twitch）或本地存储，实现直播分发和录制回放。

2.2 架构

Janus 是基于 WebRTC 的开源流媒体服务器，框架围绕模块化、插件化设计，核心可拆为基础支撑层、核心功能层、业务插件层，以下展开解析：
一、基础支撑层（协议与连接基础）

负责底层网络连接、协议处理，保障音视频与信令能跨网络、跨终端互通，关键组件：

ICE/STUN/TURN：解决网络穿透，让处于 NAT 等复杂网络的终端（如手机、内网电脑），通过 "打洞" 或中继，建立 P2P 连接；Janus 依赖 libnice 实现 ICE 功能，可部署在 NAT 后，灵活适配网络环境。
DTLS/SRTP：保障数据安全。DTLS 基于 UDP 实现 TLS 加密，用于协商 SRTP 密钥；SRTP 对音视频流加密，防止传输中被窃听、篡改，让实时通信更安全。
RTP/RTCP：RTP 负责封装、传输音视频数据，定义数据包格式；RTCP 配合 RTP，传输质量反馈（如丢包率、网络延迟），Janus 依据 RTCP 数据动态调整传输策略（如码率适配）。
SDP/candidate：SDP 是 "会话描述协议"，终端间协商媒体能力（支持的编解码、分辨率、带宽等）；candidate 是网络候选地址，用于 ICE 打洞时确定通信路径，两者协同完成音视频连接的 "协商握手"。

二、核心功能层（Janus 核心逻辑）

是服务器的 "大脑"，处理会话、媒体转发与信令交互，决定系统运行逻辑：

会话管理：维护客户端连接、WebRTC 会话生命周期。当浏览器接入 Janus，核心会分配 Session（会话），管理 "加入房间、发布流、订阅流" 等操作，确保多终端通信有序。
媒体转发：作为 SFU（选择性转发单元），接收终端上传的音视频流，按需转发给其他终端。支持 Simulcast（多分辨率流适配）、SVC（可伸缩视频编码分层适配），根据接收端网络 / 设备能力，智能选流，平衡画质与流畅度。
信令处理：对接 "信令 Transport 层"，解析 HTTP、WebSocket、MQTT 等协议的信令（如 "加入房间""切换摄像头" 指令），协调媒体流转发、会话状态变更，是业务功能的 "调度中心"。

三、业务插件层（场景化功能扩展）

通过插件化架构适配不同业务，让 Janus 能灵活支持视频会议、直播、语音通话等场景，常用插件：

VideoRoom：多人视频会议核心插件，支持多终端进房间、音视频交互，可管理参会者权限、画面布局（如主讲人放大），适配在线教育、远程办公等场景。
VideoCall：专注 1v1 或小规模视频通话，简化信令流程，降低延迟，适合一对一咨询、客服沟通等场景。
AudioRoom：纯音频互动插件，节省视频带宽，用于语音聊天室、电台直播等纯音频场景。
Streaming：直播插件，支持 "一人推流、多人观看" 的单向直播，也可结合互动连麦，适配电商直播、赛事直播等。
自定义插件：开发者可基于需求，扩展功能（如集成 AI 美颜、实时翻译，或对接企业业务系统），让 Janus 适配垂直领域（如医疗远程会诊、工业设备监控）。

四、信令 Transport 层（信令传输通道）

负责传递 "控制指令"，连接客户端与 Janus 核心，常用协议：

WebSocket：全双工长连接，实时性强，是 Janus 主流信令通道。浏览器与服务器可双向即时收发指令（如 "申请连麦""切换画质" ），保障互动流畅。
HTTP：简单易用，适合初始化请求（如获取服务器配置、创建会话），但基于 "请求 - 响应" 模式，实时性弱于 WebSocket，多用于非高频信令场景。
MQTT：轻量级发布 - 订阅协议，适合物联网、低带宽环境。若 Janus 用于 "设备 + 音视频" 场景（如智能摄像头直播），可通过 MQTT 传输信令，减少资源占用。