7、Mesh架构实战：多Peer连接管理、信令优化、带宽控制、实战踩坑
Mesh 架构，说白了就是“全连接”。每个客户端都跟其他所有人建立一条独立的 PeerConnection。你想想看，4 个人开会，每个人要维护 3 条连接；10 个人开会，每个人要维护 9 条。这玩意儿简单粗暴，但坑也多。今天我就把我在实战中踩过的坑、优化过的方案，一次性倒出来。
7.1 多Peer连接管理：别让连接变成一团乱麻
我刚开始做 Mesh 的时候，觉得不就是 new RTCPeerConnection 嘛，循环一下就行了。结果一跑起来，浏览器直接卡死。为什么？因为连接对象太多了，内存暴涨，事件监听满天飞。
核心思路：用一个 Map 统一管理所有 PeerConnection。
// 我个人习惯用 userId 作为 key
const peerConnections = new Map();
function createPeerConnection(userId) {
if (peerConnections.has(userId)) {
console.warn(`⚠️ 已经存在与 ${userId} 的连接，复用`);
return peerConnections.get(userId);
}
const pc = new RTCPeerConnection({
iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
// 统一的事件绑定
pc.onicecandidate = (e) => {
if (e.candidate) {
signalingSend({ type: 'candidate', candidate: e.candidate, target: userId });
}
};
pc.ontrack = (e) => {
// 挂载远程流到 video 元素
const video = document.getElementById(`video-${userId}`);
if (video) video.srcObject = e.streams[0];
};
peerConnections.set(userId, pc);
return pc;
}
function closePeerConnection(userId) {
const pc = peerConnections.get(userId);
if (pc) {
pc.close();
peerConnections.delete(userId);
console.log(`已关闭与 ${userId} 的连接`);
}
}
7.2 信令优化：别让信令成为瓶颈
Mesh 架构下，信令的压力是 O(n²) 的。每个人都要跟其他人交换 SDP 和 ICE 候选。如果信令服务器是简单的 WebSocket 广播，那流量会爆炸。
我踩过的坑：一开始我用 JSON 全量广播，结果 6 个人开会，信令消息每秒几百条，浏览器 UI 线程直接卡住。
优化方案：
- 只转发必要消息：信令服务器收到 A 发给 B 的消息，只推送给 B，不要广播给所有人。
- 批量处理 ICE 候选：不要每收到一个 candidate 就发一条信令。攒 5~10 个，打包成一个数组再发。
- 使用二进制协议：如果信令量实在大，可以考虑用 Protobuf 或 MessagePack 代替 JSON。
// 信令消息结构（精简版）
{
type: 'offer' | 'answer' | 'candidate' | 'join' | 'leave',
from: 'userA',
to: 'userB', // 明确指定接收方
payload: { /* SDP 或 ICE */ }
}
7.3 带宽控制：别让上行带宽先崩
Mesh 架构最大的痛点是上行带宽。每个人都要上传一路视频流给所有人。假设你上行带宽是 5Mbps，4 个人开会，每人分到 1.25Mbps；10 个人开会，每人只有 500Kbps。画质必然下降。
我建议的做法：
- 动态调整分辨率：根据当前连接数，自动降低摄像头分辨率。比如 4 人以下用 720p，4~8 人用 480p，8 人以上用 360p。
- 限制发送码率：通过 RTCRtpSender 的参数，限制每路视频的最大码率。
- 选择性发送：只发送给“活跃”的参会者。谁在说话，就给他高清流；其他人给低清流甚至只发音频。
// 限制每路视频的码率
function setVideoBitrate(pc, bitrateBps = 500000) {
const sender = pc.getSenders().find(s => s.track?.kind === 'video');
if (sender) {
const params = sender.getParameters();
if (!params.encodings) params.encodings = [{}];
params.encodings[0].maxBitrate = bitrateBps;
sender.setParameters(params).catch(e => console.warn('设置码率失败', e));
}
}
// 根据人数调整
const userCount = peerConnections.size;
let targetBitrate = 1000000; // 默认 1Mbps
if (userCount > 6) targetBitrate = 400000;
else if (userCount > 4) targetBitrate = 600000;
peerConnections.forEach((pc) => setVideoBitrate(pc, targetBitrate));
7.4 实战踩坑：我流过的血，你直接避开
这部分是我最想说的。有些坑，文档里根本不会写，只有跑过生产环境才知道。
- 坑1：ICE 重启导致连接中断
我曾经遇到网络切换时，ICE 自动重启，结果 peerConnection 的 oniceconnectionstatechange 触发了 'disconnected'，我直接 close 了连接。后来才发现，应该等几秒，看它能不能恢复。 - 坑2：SDP 协商顺序问题
如果两个人同时给对方发 offer，会导致“ glare ”冲突。我的解决方案：用随机延迟 + 重试机制，或者让信令服务器决定谁先发。 - 坑3：内存泄漏
每次创建 PeerConnection 都会占用几十 MB 内存。如果用户频繁进出房间，内存不会自动释放。我加了一个定时器，每 5 分钟检查一次，关闭那些状态为 'failed' 或 'closed' 的连接。 - 坑4：音频回声
Mesh 架构下，每个人都会收到多路音频。如果某人的扬声器声音被麦克风采集，再传给其他人，就会形成回声链。一定要启用浏览器的回声消除（echoCancellation: true），并且建议在客户端做音频混音时，不要把自己本地的音频再混进去。
7.5 知识体系总览
下面这张图，是我自己总结的 Mesh 架构核心逻辑。你看一眼，就能明白整个流程。
你看，每个客户端之间都有实线连接（PeerConnection），同时所有客户端都跟信令服务器保持虚线连接。信令只负责交换 SDP 和 ICE，不负责媒体流。这就是 Mesh 的本质。
7.6 总结
Mesh 架构，说白了就是“简单但费资源”。适合小规模、低延迟的场景。如果你要做的产品是 4~6 人视频会议，Mesh 完全够用。但记住：连接管理要严谨，信令要优化，带宽要控制。嗯，这些坑我都替你踩过了，照着做，能省不少时间。