关于在线会议中音视频传输架构WebRTC+Netty

吾辈岂是蓬蒿人691

954人浏览 · 2025-10-18 16:17:43

吾辈岂是蓬蒿人691 · 2025-10-18 16:17:43 发布

在线会议项目架构（Netty 做信令服务器 + WebRTC 实现点对点音视频流传输）是行业主流方案，核心是 “Netty 解决信令协同问题，WebRTC 解决音视频流实时传输问题”，两者配合实现低延迟、高可靠的实时通信。下面拆解这个架构的核心逻辑和关键角色：

一、先明确核心概念：信令 vs 音视频流

在线会议中，数据传输分两类，二者职责完全不同：

信令：非媒体数据，负责 “协商”—— 比如 “谁要和谁连”“用什么编码格式”“网络地址是什么”，是 WebRTC 建立连接的 “前置条件”。
音视频流：媒体数据，是会议的核心内容（声音、画面），通过 WebRTC 建立的点对点（P2P）连接直接传输，不经过信令服务器（减少延迟）。

Netty 的作用是 “信令服务器”，管 “协商”；WebRTC 管 “传流”，二者分工明确。

二、Netty：信令服务器的核心职责

WebRTC 本身不处理 “信令交换”，需要一个中间服务（信令服务器）帮两端传递协商信息，而 Netty 因为高性能的 TCP/UDP 通信能力（支持高并发长连接），成为信令服务器的优选。它主要做 3 件事：

1. 维护客户端连接与身份映射

在线会议中，每个客户端（参会者）打开页面后，会先通过 WebSocket（基于 TCP，Netty 支持 WebSocket 协议）与 Netty 信令服务器建立长连接。
Netty 会给每个客户端分配唯一标识（如userId），并维护 “userId→WebSocket连接” 的映射表 —— 后续要 “找某人连麦” 时，能通过userId找到对应的客户端连接，传递信令。

2. 转发 WebRTC 的 3 类核心信令

WebRTC 建立 P2P 连接需要 3 轮关键协商，这些信令都通过 Netty 转发（客户端 A→Netty→客户端 B）：

信令类型	作用
Offer	发起连接方（如 A）生成的 “连接提议”，包含 A 支持的音视频编码、网络地址等信息
Answer	接收连接方（如 B）回应的 “同意提议”，包含 B 的编码、网络地址等信息
ICE Candidate	两端各自收集的 “网络候选地址”（如本地 IP、路由器公网 IP），用于穿透 NAT，找到可直连的路径

举个连麦场景：A 想和 B 连麦 → A 生成 Offer 信令→通过 WebSocket 发给 Netty→Netty 根据 B 的userId找到 B 的连接→转发 Offer 给 B→B 生成 Answer 和 ICE Candidate→通过 Netty 转发回 A→两端基于这些信令建立 P2P 连接。

3. 处理会议控制信令（非 WebRTC 核心，但业务必需）

除了 WebRTC 的连接信令，Netty 还会转发会议相关的业务信令，比如：

参会者加入 / 离开会议（通知其他参会者 “谁进来了 / 走了”）
静音 / 解除静音、关闭摄像头（通知对方 “某人静音了”）
会议主持人踢人、切换主讲人等

三、WebRTC：客户端点对点音视频流传输的核心

当 Netty 完成 “信令协商” 后，客户端之间会通过 WebRTC 直接建立 P2P 连接，开始传输音视频流。核心逻辑分 3 步：

1. 本地音视频采集与编码

客户端通过浏览器的getUserMedia API（WebRTC 标准 API）访问摄像头 / 麦克风，采集原始音视频数据。
对原始数据进行编码（如音频用 OPUS、视频用 H.264/VP9）—— 编码的目的是压缩数据量（原始视频 1 秒几 MB，编码后可降到几百 KB，适合实时传输）。

2. P2P 连接建立（基于 ICE 穿透 NAT）

互联网中，客户端大多在路由器（NAT 设备）后面，没有公网 IP，直接 P2P 连不通。WebRTC 通过ICE 协议解决这个问题：
- 客户端会收集 “ICE Candidate”（候选地址）：包括本地局域网 IP（如192.168.1.100）、路由器分配的公网 IP（通过 NAT 映射）、甚至通过 TURN 服务器（备用方案，若 P2P 穿透失败，音视频流走 TURN 服务器转发）。
- 这些 Candidate 通过 Netty 转发给对方后，两端会尝试用不同 Candidate 建立连接（如先试局域网 IP，再试公网 IP），直到找到能成功通信的路径 —— 这一步完成后，P2P 连接就建立了。

3. 实时音视频流传输与解码

连接建立后，客户端会通过SRTP 协议（安全实时传输协议，加密音视频数据，防止被窃听）将编码后的音视频流通过 P2P 连接发给对方。
接收方收到流后，用对应的解码器（如 OPUS 解码器解音频、H.264 解码器解视频）还原成原始数据，再通过浏览器的<video>标签渲染画面、<audio>标签播放声音 —— 实现 “实时看到 / 听到对方”。

四、关键问题：为什么需要这样的架构？（Netty+WebRTC 的必要性）

为什么用 Netty 做信令服务器？
- 信令需要 “长连接”（实时转发，不能断），Netty 支持高性能长连接（单台服务器可支撑上万客户端连接），且能轻松集成 WebSocket 协议（浏览器端常用的长连接方案）。
- 若用普通 HTTP 接口做信令（短连接），会有 “轮询延迟”（客户端要频繁发请求问 “有没有新信令”），无法满足实时连麦需求。
为什么 WebRTC 要 P2P 传流，不经过服务器？
- 减少延迟：P2P 是 “客户端直连”，数据不用绕服务器，延迟可低至几十毫秒（适合实时会议）；若所有流走服务器转发（如直播的 “推流 - 拉流” 模式），服务器压力大且延迟高（可能几百毫秒）。
- 降低服务器带宽成本：音视频流数据量大（10 人会议，每人上传 1Mbps，服务器转发需 10Mbps×10=100Mbps 带宽），P2P 可让服务器只传信令（信令数据量极小，几乎可忽略）。

五、实际项目中的注意点（避坑指南）

NAT 穿透失败的备用方案：TURN 服务器
- 部分严格的 NAT 环境（如企业内网）下，ICE 无法穿透 P2P，此时需要部署 TURN 服务器（如 Coturn）——WebRTC 会自动切换到 “通过 TURN 服务器转发流”，确保会议不中断。Netty 信令服务器需要配置 TURN 服务器地址，让客户端在收集 ICE Candidate 时包含 TURN 地址。
Netty 的高可用设计
- 若会议人数多（如百人会议），单台 Netty 服务器可能扛不住，需要做集群：通过 Redis 维护 “userId→集群节点IP” 的全局映射，实现信令跨节点转发（比如 A 连节点 1，B 连节点 2，节点 1 通过 Redis 找到 B 的节点 2，再转发信令）。
音视频质量适配：带宽自适应
- 网络波动时（如客户端带宽突然变低），WebRTC 可通过RTCPeerConnection的addTransceiver配置 “带宽限制”，动态降低视频分辨率 / 帧率（如从 1080P 降到 720P），避免卡顿 —— 客户端需要监听网络状态，通过 Netty 信令通知对方调整编码参数。

总结

这个架构的核心逻辑是 “Netty 搭好‘沟通桥梁’（信令），WebRTC 打通‘数据高速路’（音视频流） ”：

Netty 负责 “找人” 和 “协商规则”，解决 “怎么连” 的问题；
WebRTC 负责 “传流” 和 “画面渲染”，解决 “怎么实时看到 / 听到” 的问题。两者结合，是目前中小规模在线会议（几十人内）性价比最高的方案（延迟低、服务器成本低）。

在线会议核心架构图

plaintext

┌─────────────────┐      ┌──────────────────────────────────────┐      ┌─────────────────┐
│   客户端 A       │     │              服务端集群                │      │   客户端 B     │
│ （浏览器/WebRTC）│      │                                      │      │（浏览器/WebRTC）│
└────────┬────────┘      ├───────────────┬───────────────────────┤      └────────┬────────┘
         │               │               │                       │               │
         │  1. 建立WebSocket连接          │                       │               │
         ├────────────────►  Netty信令服务器  ◄───────────────────┤               │
         │               │  （维护长连接/用户映射）                │               │
         │               │               │                       │               │
         │  2. 发送加入会议信令（meetingId、userId）               │               │
         ├────────────────►              │                       │               │
         │               │               │  3. 广播参会者信息      │              │
         │               │               ├───────────────────────►│              │
         │               │               │                        │              │
         │  4. A发起连麦：发送Offer信令    │                        │              │
         ├────────────────►               │                       │              │
         │               │               │  5. 转发Offer给B       │               │
         │               │               ├───────────────────────►│              │
         │               │               │                        │              │
         │               │               │  6. B返回Answer信令     │              │
         │               │               │◄───────────────────────┤              │
         │  7. 转发Answer给A              │                        │              │
         │◄───────────────┤               │                       │              │
         │               │               │                        │              │
         │  8. A发送ICE Candidate        │                         │              │
         ├────────────────►               │                       │               │
         │               │               │  9. 转发ICE给B          │              │
         │               │               ├───────────────────────►│               │
         │               │               │                        │               │
         │               │               │  10. B发送ICE Candidate│               │
         │               │               │◄───────────────────────┤               │
         │  11.转发ICE给A                 │                        │               │
         │◄──────────────┤               │                        │               │
         │               │               │                        │               │
         │◄──────────────────────────────────────────────────────►│               │
         │            12. WebRTC P2P连接建立（直连）               │               │
         │               │               │                        │               │
         │  13. 音视频流通过P2P传输       │                        │               │
         ├───────────────────────────────────────────────────────►│               │
         │               │               │                       │                │
         │  （若P2P穿透失败）              │                       │               │
         │  14.  fallback到TURN服务器转发  │                       │               │
         ├───────────────►  TURN服务器  ◄──────────────────────────┤              │
         │               │ （中继音视频流）│                        │              │
         │  15. 流通过TURN转发给B          │                        │              │
         │◄───────────────►               │                        │              │
         │               │               │                         │              │
┌────────┴────────┐      └───────────────┴──────────────────────——─┘      ┌────────┴────────┐
│   客户端 A      │                                                     │   客户端 B      │
└─────────────────┘                                                     └─────────────────┘

核心交互流程说明

1. 初始化阶段：连接信令服务器

客户端（A/B）打开会议页面后，通过 WebSocket 与 Netty 信令服务器 建立长连接（步骤 1）。
客户端发送 JOIN_MEETING 信令（含 meetingId、userId），Netty 记录 “用户 - 连接” 映射，并广播给会议内其他用户（步骤 2-3），实现 “谁加入了会议” 的通知。

2. 连接协商阶段：WebRTC 信令交换（核心）

发起连麦（Offer）：客户端 A 想与 B 连麦，生成 SDP Offer（含 A 支持的音视频编码、网络信息），通过 Netty 转发给 B（步骤 4-5）。
回应连麦（Answer）：客户端 B 收到 Offer 后，生成 SDP Answer（含 B 的编码 / 网络信息），通过 Netty 回传给 A（步骤 6-7）。
网络穿透（ICE Candidate）：A 和 B 分别收集本地网络候选地址（如局域网 IP、公网 IP），通过 Netty 互相转发（步骤 8-11），双方尝试直连，最终确定可用的 P2P 路径。

3. 数据传输阶段：音视频流实时传输

理想情况（P2P 直连）：通过步骤 2 协商的路径，A 和 B 直接建立 WebRTC 的 RTCPeerConnection，音视频流通过 SRTP 协议 加密传输（步骤 12-13），延迟低（几十毫秒）。
降级情况（TURN 转发）：若 NAT 穿透失败（如企业内网限制），WebRTC 自动切换到 TURN 服务器 中继流（步骤 14-15），确保通信不中断（延迟略高，但可靠性高）。

4. 业务控制阶段：会议交互信令

客户端通过 Netty 转发业务信令（如 MUTE_AUDIO 静音、LEAVE_MEETING 离开），信令服务器广播给相关用户，同步会议状态。

关键组件职责

组件	核心职责
Netty 信令服务器	1. 维护客户端长连接（WebSocket）；2. 转发 WebRTC 协商信令（Offer/Answer/ICE）；3. 处理会议业务信令（加入 / 静音等）；4. 管理用户 - 会议映射关系。
WebRTC 客户端	1. 采集 / 编码音视频；2. 生成 SDP 和 ICE Candidate；3. 建立 P2P 连接；4. 解码并渲染音视频。
TURN 服务器	作为 P2P 穿透失败的备用方案，中继音视频流（解决 NAT 限制问题），常用开源方案：Coturn。