Janus 1.4.3 介绍与选型指南

Janus（janus-gateway）v1.4.3 WebRTC SFU 流媒体服务器介绍：架构分层、内置插件、适用场景与限制，以及与 mediasoup、Jitsi Videobridge、GStreamer webrtcbin 的量化选型对比（含同名异物 JanusGraph 辨析）。

JanusJanusWebRTC流媒体2026/10/26

Janus 1.4.3 介绍与选型指南

目标：面向自建实时音视频（RTC）与流媒体场景的读者，讲清 Janus（全称 janus-gateway，官方自称 "Janus WebRTC Server"）是什么、架构如何、能做什么、与同类 WebRTC 服务器怎么选。本文为认知篇，全部数据来自官方仓库与官方文档的联网溯源（查询日期 2026-10-26，各处均已标注来源），未做本地实测；实测安装、部署与验证见本专栏后续部署与运维篇。

一、环境信息

本篇是纯溯源的认知篇，先交代信息基准，方便读者复核时效与口径。

  • 查询日期：2026-10-26。
  • 信息获取方式：纯官方渠道联网溯源，未做本地实测。来源包括 GitHub 仓库 meetecho/janus-gateway（README 与 Releases）、官方站点与文档站 janus.conf.meetecho.com、shields.io 星数徽章。
  • 软件版本：v1.4.3（主线 multistream 分支当前最新稳定版，2026-10-26 自 GitHub Releases 源实查）；旧线 0.x（官方称 legacy）并行维护，最新为 v0.16.3。
  • 适用平台：Linux 为主（官方 README 明确 "tailored for Linux systems"）；macOS 可编译安装；Windows 官方不支持（可通过 WSL 使用，官方明确提醒勿信任第三方 .exe 构建）。
  • 开发方：Meetecho（意大利的一家专注于实时通信的公司，同时是 W3C/IETF WebRTC 相关标准化工作的长期参与者）。
  • 重要防混淆说明：本专栏的 Janus 指 WebRTC 服务器 janus-gateway，与图数据库 JanusGraph 是完全无关的同名异物，详见下文 2.3 节。

二、软件概述

2.1 Janus 是什么

Janus（全称 janus-gateway）是一个开源的、通用目的的 WebRTC 服务器，由 Meetecho 设计开发，采用 C 语言编写，以 GPLv3 许可证发布。它实现的是 SFU（Selective Forwarding Unit，选择性转发单元） 模型：服务器本身不做混流、不做转码，只负责在参与者之间按需转发 RTP/SRTP 媒体流，因此单机即可承载大量并发流，延迟低、资源占用小。

官方 README 对它的自我定位是一句话："Janus is an open source, general purpose, WebRTC server designed and developed by Meetecho"（来源：GitHub 仓库 meetecho/janus-gateway README，v1.4.3 版，2026-10-26 实查）。

💡 技术拓展：多人实时音视频的架构模型不止 SFU 一种，主流方案有三类——

模型原理优点缺点代表实现
Mesh（网状）每个参与者与其他所有人两两直连无需服务器媒体面，部署最简上行带宽随人数平方膨胀，浏览器端几乎撑不过 4~6 人纯 P2P 应用、早期 demo
MCU（多点控制单元）服务器把所有人的流混流/转码成一路再下发下行只有一路流，终端压力最小服务器 CPU 开销巨大，有转码延迟，难做大规模传统硬件视频会议、Kurento 混流模式
SFU（选择性转发）服务器不混流转码，只按订阅关系选择性转发 RTP 包服务器 CPU 只做转发，单机并发高，端到端延迟低各端需同时收发多路流，对终端与网络有要求Janus、mediasoup、Jitsi Videobridge

当前主流自建方案几乎都落在 SFU 模型上——用 TURN/STUN 打通连接后由 SFU 居中转发，既保留了低延迟，又把计算压力集中到了服务端。Janus 采用的正是 SFU；本文第七章的选型对比也围绕同类 SFU 展开对比。

2.2 版本线与发布节奏

Janus 从 v1.0 起切换到 "multistream" 主线（单会话内可同时挂多路音视频流，面向更现代的使用方式），同时保留 0.x legacy 线做维护。2026-10-26 自 GitHub Releases 源实查到的发布节奏如下（releases.atom 源，前几条按时间倒序）：

发布线最新版本说明
1.x（multistream 主线）v1.4.3新特性与主要维护都落在此线，新项目应选它
0.x（legacy 线）v0.16.3老版本维护线，仅收关键修复，存量项目逐步迁移

两条线版本号成对出现（1.4.3/0.16.3、1.4.2/0.16.2……），说明官方以"主线推进 + 旧线补丁"的节奏在维护。本专栏所有文档均以 v1.4.3 为基准。

2.3 同名异物：与 JanusGraph 无关

搜索 "Janus" 时极易命中图数据库 JanusGraph，两者是毫无关系的同名异物，选型前务必分清：

对比项Janus（本专栏）JanusGraph
实体WebRTC SFU 流媒体服务器（janus-gateway）分布式图数据库
开发方Meetecho2017 年起为 Linux 基金会项目
解决的问题浏览器间实时音视频/数据的连接与转发海量图数据的存储与 Gremlin 查询
典型场景视频会议、低延迟直播、SIP 互通知识图谱、关系网络分析

两者唯一的共同点是都借用了罗马双面神 "Janus" 的名字。如果你要找的是图数据库，请直接阅读站内既有专栏 《JanusGraph 1.1 介绍与选型指南》，本专栏其余文档均不涉及图数据库内容。

三、核心架构

Janus 的核心设计思想是"网关"而不是"应用"：内核只处理 WebRTC 连接、SRTP 加解密与 RTP 转发这些通用媒体面工作，具体业务逻辑（会议室、直播、SIP 互通……）全部交给可插拔的插件动态承载。这个设计让 Janus 既能开箱即用，又能被二次开发成任意形态的 RTC 业务系统。

3.1 架构分层

一个 Janus 实例的分层结构如下（依据官方文档站 architecture 章节，2026-10-26 溯源）：

客户端（浏览器 / App / 服务端程序）
   │  Janus API（JSON 信令）
   ▼
┌────────────────────────────────────────────┐
│  Transport 层（可多开）                     │
│  HTTP/HTTPS │ WebSocket │ RabbitMQ │ MQTT  │
├────────────────────────────────────────────┤
│  Janus 核心（C）                            │
│  会话/句柄管理 │ SDP/ICE/DTLS/SRTP │ 转发    │
├────────────────────────────────────────────┤
│  Plugin 层（动态库，可热加载）               │
│  VideoRoom │ Streaming │ AudioBridge │ SIP  │
│  EchoTest │ VideoCall │ TextRoom │ Lua/JS…  │
├────────────────────────────────────────────┤
│  Event Handler / Admin API（可观测面）       │
└────────────────────────────────────────────┘

三层抽象各司其职：

  • Janus API：客户端到服务器的信令协议。客户端先创建 session（会话），再在 session 上 attach 一个插件得到 handle（句柄），随后向 handle 发送 JSON 消息、接收事件与建立媒体通道。同一套 API 不论走 HTTP 还是 WebSocket 语义一致。
  • Transport 层：信令的承载方式，编译期可选、运行时可多开。HTTP/HTTPS 由 libmicrohttpd 提供，WebSocket 由 libwebsockets 提供，另支持 RabbitMQ、MQTT、Nanomsg 等消息队列形态，方便把 Janus 嵌入已有的后端消息体系。
  • Plugin API：核心与插件之间的接口。每个插件是一个 .so 动态库，在 janus.plugin.<名称>.cfg 中配置，可独立启停；官方还提供 Lua 与 Duktape（JavaScript）两种脚本插件运行时，写个脚本就能扩展业务而不必碰 C。

3.2 媒体面能力

作为 SFU，Janus 核心处理的媒体能力包括（来源：官方文档站与 README，2026-10-26 溯源）：

  • RTP/SRTP 转发：SRTP/DTLS 全部在核心内终结与重建，插件收发的是已解密 RTP。
  • Simulcast（多码率同发）：发送端同发多档清晰度，转发端按订阅者带宽择优下发；对 VP9/AV1 这类可分级编码亦支持 SVC 分层转发。
  • Full-trickle ICE：候选地址边收集边发送，加快建连；支持 STUN/TURN、ICE restart。
  • Data Channels：基于 SCTP/DTLS 的数据通道（usrsctp），TextRoom 聊天室即构建于其上。
  • 录制与回放：核心自带录音/录像落盘（.mjr 格式）及后处理工具 janus-pp-rec。

💡 技术拓展：Simulcast 与 SVC 是 SFU 应对异构接收端的两种主流多码率方案——

方案原理取舍
Simulcast发送端独立编码 2~3 路不同分辨率的流，SFU 按需选一路转发兼容性好，实现简单；上行带宽要多花 2~3 倍
SVC（可分级编码）发送端只编一路流，但流内部分层（时间/空间/质量层），SFU 丢包即降级上行省带宽；依赖 VP9/AV1 等可分级编码器，CPU 开销更高

Janus 两者都支持：常规场景用 Simulcast（浏览器 addTransceiver 原生支持），VP9/AV1 场景可启用 SVC 转发。

3.3 单机架构与集群边界

Janus 官方内核是单进程单机架构：没有内置的多节点会议同步、跨节点数据迁移或控制器。生产里做"集群"的通行做法是在 Janus 之上加一层调度（负载均衡把房间的所有用户导到同一台节点），或采用官方生态中的外置方案。这一点与"开箱即集群"的产品是本质差异，选型时要把自建调度的工作量算进去（详见 7.3 节选型建议）。

四、功能特性

4.1 官方内置插件清单

以下插件均随源码发布（来源：仓库 plugins/ 目录与官方文档，2026-10-26 溯源），配置文件前缀均为 janus.plugin.<名称>：

插件配置文件用途
Streamingjanus.plugin.streaming.jcfg广播型流分发：把服务器上的本地文件、RTP 流或 RTSP 源以 WebRTC 形式播给多个观看者（低延迟直播）
VideoRoomjanus.plugin.videoroom.jcfg多人视频房间（SFU 会议），1.x 多流版本支持单房间内多路音视频，WebRTC 会议的主力插件
AudioBridgejanus.plugin.audiobridge.jcfg多人语音混音房间（音频层混流，输出单路混音），适合语音房/电话会
SIPjanus.plugin.sip.jcfgWebRTC 与 SIP 服务器/PBX 互通，浏览器注册为 SIP 分机
SIPrejanus.plugin.sipre.jcfgSIP 插件的重写版（基于 repub 状态机），面向更复杂的 SIP 场景
VideoCalljanus.plugin.videocall.jcfg1 对 1 视频通话（类似 WebRTC 版"拨打/接听"）
EchoTestjanus.plugin.echotest.jcfg回声测试：发什么回什么，建连与自检的最小闭环，部署验证首选
TextRoomjanus.plugin.textroom.jcfg基于 Data Channels 的聊天室
Record&Playjanus.plugin.recordplay.jcfg录制并回放用户媒体
NoSIPjanus.plugin.nosip.jcfg裸 SDP 桥接：把 WebRTC Offer/Answer 桥给任意外部信令（自研信令网关场景）
Lua / Duktapejanus.plugin.lua.jcfg / janus.plugin.duktape.jcfg用 Lua / JavaScript 脚本写自定义业务插件
Sample Event Handlerjanus.plugin.sampleevh.jcfg事件处理器样例：把 Janus 内部事件转发到外部（HTTP/MQTT 等）

💡 说明：1.x multistream 线中 VideoRoom 重写了多流支持（同一发布者可同时发多路音视频、订阅端可按流选择），与 0.x 的行为有差异；迁移老项目时先读官方迁移说明再动配置。

4.2 多传输信令与管理面

  • 信令传输：HTTP/HTTPS（短轮询 + long poll 事件）、WebSocket（双向事件，低延迟场景首选）、RabbitMQ、MQTT、Nanomsg，同一实例可多开并存（README 依赖清单与官方文档，2026-10-26 溯源）。
  • Admin API：独立管理端口，可查询 session/handle 数量、按句柄结束会话、取内部指标，配合 janus.cfg 的 admin_secret 鉴权，是运维巡检与监控对接的入口。
  • Event Handler 机制：核心产生的会话/媒体事件可推给 event handler 插件，再由插件转发到外部系统（如 MQ 或 HTTP 收集端），便于接入自有可观测体系。

4.3 部署与运维特性

  • 单进程 C 服务：编译后就是一个 janus 可执行文件加一组动态库，内存占用通常在几十 MB 量级，无 JVM、无解释器依赖，适合边缘/低配服务器。
  • 配置全文件化：核心 janus.cfg + 各 transport/plugin 各自的 .jcfg/.cfg，改配置即改文件，重启生效（配置详解见本专栏 C1 篇）。
  • 前端 Demo 页：源码自带 html/ 目录的一组浏览器 demo（echotest、streaming、videoroom 等），部署后可直接用浏览器连上验证，是排障时区分"服务端问题还是客户端问题"的利器。

五、快速开始（最小可用示例）

⚠️ 本节为官方 README 摘录的通用路径，仅作认知参考，未在本文档实测；带实测回显的完整安装流程见本专栏《Debian 12 安装 Janus 1.4.3 指南》。

最快的三条体验路径：

  1. 在线 Demo（零安装）：打开官方站 https://janus.conf.meetecho.com/ 的 demos 页面，官方部署的公共 Janus 实例上可直接体验 echotest、videoroom、streaming 等插件效果，用于快速建立感性认识。
  2. 源码编译（官方推荐路径）：官方 README 给出的 Debian/Ubuntu 依赖安装与编译主线如下（摘自 README v1.4.3，2026-10-26 实查）：
  3. 容器化体验：社区维护有打包好的 Janus 镜像，可跳过编译直接拉起实例做连通性体验；生产化部署与镜像选型见本专栏 Docker Compose 部署指南。

README 中的依赖安装与编译主线摘录（Debian/Ubuntu）：

apt install libmicrohttpd-dev libjansson-dev \
    libssl-dev libsofia-sip-ua-dev libglib2.0-dev \
    libopus-dev libogg-dev libcurl4-openssl-dev liblua5.3-dev \
    libconfig-dev pkg-config libtool automake

随后获取源码并编译（官方 README 的通用步骤）：

git clone https://github.com/meetecho/janus-gateway.git
cd janus-gateway
sh autoreconf -i        # 生成 configure 脚本
./configure --prefix=/opt/janus
make
make install            # 安装到 /opt/janus

安装完成后的标准验证方式是启动 janus 并观察日志中各 transport/plugin 的加载情况，再用浏览器打开 demo 页连接 echotest 插件——这一闭环的逐步实测（含 curl 调 API 的真实回显）在本专栏安装指南中完整呈现。

六、适用场景与限制

6.1 典型适用场景

  • 自建视频会议：VideoRoom + simulcast 承载几十人级会议室，前端用官方 janus.js 或社区 SDK。
  • 低延迟直播/连麦：Streaming 插件做广播型分发（延迟 ~500ms 级，远低于 HLS 的秒级延迟），配合 AudioBridge 做连麦语音。
  • WebRTC 与传统语音网互通：SIP 插件把浏览器接入 FreeSWITCH/Asterisk/Kamailio 等既有 SIP 体系，做网页呼叫中心。
  • 自研信令的媒体网关：NoSIP 插件或直接用 Janus API，把 Janus 当作"WebRTC 媒体面"嵌到自研业务后端。
  • 流媒体桥接与录制：WebRTC 收流后转推（RTSP/RTP），或用录制能力落盘再由 janus-pp-rec 转封装。

6.2 主要限制

  • GPLv3 许可证：对"修改后闭源分发"不友好；商用闭源产品把 Janus 作为独立进程调用一般无碍，但直接改内核代码再分发需评估 GPL 义务。
  • 无内置集群：跨节点的房间同步、故障切换均需自建或引入外部方案，规模上来后调度层是主要工程量（见 3.3 节）。
  • 不做转码/混流（SFU 本性）：需要服务端混流（如把会议合成一路推 RTMP）得外挂 GStreamer/FFmpeg 流水线。
  • 平台面：Windows 原生不支持；macOS 仅编译可用，生产以 Linux 为准。
  • 前端配套需自建：官方提供 janus.js 与 demo 页，但生产级 UI、房间管理、鉴权体系都要自己做——Janus 定位是网关，不是开箱即用的会议产品（后者请看 Jitsi Meet 全家桶）。

七、同类选型对比

7.1 候选对象与量化对比

同类的自建 WebRTC SFU 方案中，最常被与 Janus 放在一起比较的是 mediasoup、Jitsi Videobridge 与 GStreamer 的 webrtcbin。下表数据来源：各项目 GitHub 仓库与 LICENSE 文件（星数经 shields.io 徽章实查，许可证经 LICENSE 文件实查，查询日期均为 2026-10-26）：

维度JanusmediasoupJitsi VideobridgeGStreamer webrtcbin
定位/形态完整的 WebRTC 服务器（网关 + 插件 + demo）SFU 库/框架（嵌入 Node.js 应用自建服务）完整 SFU 服务器，Jitsi Meet 全家桶的媒体核GStreamer 多媒体流水线中的一个元素
开发语言CC++（worker）+ Node.js/TypeScriptJavaC（GStreamer 框架）
许可证GPLv3ISCApache 2.0LGPL（GStreamer 主体）
GitHub 星数（2026-10-26）9.2k（meetecho/janus-gateway）7.4k（versatica/mediasoup）3.1k（jitsi/jitsi-videobridge）3.4k（GStreamer/gstreamer，全仓库含所有组件）
控制信令自带 Janus API（HTTP/WS/RabbitMQ/MQTT 多传输）+ Admin API库 API（Node.js/C++/Rust 绑定），信令完全自定XMPP（Jingle）为主，面向 Jitsi 生态GLib/GStreamer API，程序内嵌调用
扩展模型动态库插件 + Lua/Duktape 脚本插件应用层代码扩展（库无插件概念）XMPP MUC 协作，扩展偏 Jitsi 生态GStreamer 插件体系（pad/bin）
开箱能力内置 VideoRoom/Streaming/SIP 等十余插件 + 浏览器 demo，装完即能用无业务插件，房间/会议逻辑全部自己写配合 Jitsi Meet 前端开箱即成完整会议无任何业务层，纯媒体流水线
集群无内置，自建调度无内置，自建（社区有 sfu 管理实践）有分布式实践（jitsi-videobridge2 + 共享 MUC）不适用（单流水线）
典型使用者自建会议/直播/SIP 互通团队对控制面有强定制诉求的 RTC 团队想要"完整会议产品"的自托管用户已有 GStreamer 流水线、要收发 WebRTC 的场景

表头之外的三点解读：

  1. 形态差异是第一决策点：Janus/JVB 是"装完就有服务"的服务器，mediasoup/webrtcbin 是"写代码才有服务"的库/组件。要快速落地选前者，要控制面完全自主选后者。
  2. 星数不代表并发能力：四者星数（9.2k/7.4k/3.1k/3.4k）反映的是社区关注度与生态位差异，不直接对应性能排名；四者均被生产验证过，性能瓶颈更多取决于部署与调优。
  3. 许可证差异显著：GPLv3（Janus）最严，ISC/Apache（mediasoup/JVB）最宽松，LGPL（GStreamer）居中；闭源商用集成时先过许可证这一关。

7.2 社区活跃度与版本节奏

  • Janus：1.x 主线与 0.x legacy 线并行发布（2026-10-26 实查最新为 1.4.3/0.16.3），官方 Discourse 论坛 + GitHub Issues 双社区渠道，发布频率稳定；另有 Coverity Scan 与 OSS-Fuzz 持续安全扫描（README 徽章实查）。
  • mediasoup：迭代快、API 演进积极，Node.js 生态绑定深，文档以代码与 API 参考为主。
  • Jitsi Videobridge：随 Jitsi Meet 生态整体演进，社区规模大（jitsi-meet 主仓库），但 JVB 本体的独立讨论多在 Jitsi 社区渠道。
  • GStreamer webrtcbin：随 GStreamer 半年节奏发布，作为框架元素稳定性高，但 WebRTC 业务层资料相对最少。

7.3 选型建议（如果…则…）

  • 如果要快速自建会议/低延迟直播/SIP 互通，且接受自建调度层 → Janus（插件全、demo 全、多传输信令，本专栏即围绕它展开）。
  • 如果要开箱即用的完整视频会议产品（含前端 UI、聊天、白板）→ Jitsi Meet 全家桶（JVB 为其媒体核），而非裸 JVB。
  • 如果要完全自主的控制面与协议（自研房间逻辑、自定信令），团队有 Node.js 能力 → mediasoup。
  • 如果已在 GStreamer 流水线里（转码、混流、录制已有编排），只需补充 WebRTC 收发能力 → webrtcbin。
  • 如果需要服务端混流合成一路流（如推 RTMP/RTSP 给 CDN）→ 以上 SFU 均不直接满足，用 Janus/GStreamer 组合外挂转码流水线。

八、参考链接