企业官网建设流程全解析

简介：CS_WebRTC_Conference_Server_Peer.v4.1.1 是一套面向实时音视频通信开发者的 WebRTC 会议服务端 PeerServer 发布包，适合需要搭建端对端会议、研究信令与连接管理的中高级开发者。资源围绕 RTCPeerConnection、RTCDataChannel、ICE 穿透及 SRTP/DTLS 加密等核心机制，提供可部署的服务端实现，并带有 Intel 平台相关的性能适配倾向。压缩包为 tgz 格式，共 8 个文件，约 16KB，包含 2 个 js 主逻辑脚本、2 个 pem 证书文件、2 个 json 配置与依赖描述、1 个 sh 安装脚本及 1 个许可说明文本，结构精简，便于快速理解服务端启动、证书配置与依赖管理流程。目前已有 287 人浏览学习。通过该资源，读者可获取一套可直接运行的会议服务端骨架，掌握信令协调、连接建立与安全传输的落地思路，并借助配置与脚本快速完成本地部署验证，为后续扩展负载均衡与 QoS 策略打下基础。

1. 从 CS_WebRTC_Conference_Server_Peer.v4.1.1 说起：一套自托管多人会议服务端到底长什么样

多人实时音视频这件事，最容易被低估的不是编解码，而是信令和拓扑。CS_WebRTC_Conference_Server_Peer.v4.1.1 这个标题里，CS 通常指 Conference Server，Peer 指对等连接，v4.1.1 是版本号。合起来看，它描述的是一套自托管的 WebRTC 会议服务端，核心职责是帮多个浏览器客户端完成信令交换、建立 P2P 媒体通道，并在必要时做转发兜底。它解决的是「不想把会议数据交给第三方、又想快速跑起多人通话」这个诉求，适合有内网部署需求、想自己掌控信令和媒体路径的开发者。很多人第一次搭 WebRTC 会议，卡在信令服务器和 NAT 穿透上，这套东西的价值就在于把这两块打包成可部署的服务端。

2. 信令、ICE 与媒体拓扑：先搞懂这套服务端在替你做什么

2.1 信令服务器不是可选项，而是会议的地基

WebRTC 本身只规定了浏览器之间怎么传媒体，没规定双方怎么找到对方。这个「找到对方」的过程就是信令。CS 这类服务端的第一个职责，就是提供一个 WebSocket 或 HTTP 通道，让每个加入房间的客户端把 SDP offer/answer 和 ICE candidate 发给服务端，再由服务端转发给同房间的其他 peer。

常见做法是：客户端连上信令服务后先发一个 join 消息，带上房间号和自己的 peerId；服务端维护一个roomId -> [peerId]的映射表，新 peer 进来时通知房间内已有 peer，由已有 peer 主动发起 offer。这个「谁先发 offer」的规则必须定死，否则双方同时发 offer 会出现 glare 冲突，表现为连接一直卡在 connecting。

我一般会把信令消息设计成三类：join/leave 控制消息、offer/answer 会话描述、candidate 网络候选。服务端只做转发和房间成员管理，不解析 SDP 内容，这样服务端逻辑足够薄，出问题时容易定位是信令没到还是媒体没通。

2.2 ICE 与 STUN/TURN：P2P 能不能成，全看这一步

信令通了只是知道对方存在，真正建立媒体通道要靠 ICE 框架去收集本机的候选地址。候选分三类：host（本机网卡地址）、srflx（经 STUN 反射出的公网地址）、relay（经 TURN 转发的地址）。同一局域网内 host 候选就能直连；跨公网时往往需要 srflx；对称型 NAT 下只能靠 relay。

服务端配置里通常要填 STUN/TURN 地址。STUN 只做地址发现，成本低；TURN 要转发媒体流，带宽成本高。我的经验是：内网会议只配 STUN 就够，跨公网会议必须配 TURN，否则一定有一部分用户连不上。TURN 的 credential 建议用临时凭证机制，不要写死在客户端里。

// 客户端构造 RTCPeerConnection 时的典型配置 const pc = new RTCPeerConnection({ iceServers: [ { urls: "stun:stun.example.internal:3478" }, { urls: "turn:turn.example.internal:3478", username: "临时用户名", credential: "临时密码" } ], iceTransportPolicy: "all" // 设为 relay 可强制走 TURN，用于排查 });

这段配置里iceTransportPolicy是关键排查开关：正常用all，如果怀疑是 NAT 穿透失败，临时改成relay强制走 TURN，能通就说明是候选收集或 NAT 类型问题，不能通就是 TURN 本身没配好。urls支持数组，可以同时填多个 STUN 提高发现成功率。

2.3 Mesh、SFU、MCU：Peer 模式到底适合几个人

标题里的 Peer 暗示了这套服务端偏向 P2P 直连模式，也就是 Mesh 拓扑：每个客户端和其他每个客户端都建一条 RTCPeerConnection。3 人会议每人维护 2 条连接，5 人每人 4 条，连接数按 n×(n-1)/2 增长。

Mesh 的优点是服务端几乎不耗带宽，部署简单；缺点是上行带宽随人数线性增长，4 人以上普通家用上行就扛不住。所以这套 Peer 模式的服务端，定位就是小规模会议。如果你要开 10 人以上的会，得换 SFU 方案，这是选型阶段就要想清楚的，别等上线了才发现卡成幻灯片。

3. 从零把服务端跑起来：环境、配置与最小验证

3.1 环境准备与依赖安装

这类 Node.js 系的服务端，常见依赖是 express 做 HTTP 服务、ws 做 WebSocket、以及一个静态文件服务托管前端页面。先确认 Node 版本，建议 18 LTS 以上，低版本对 WebSocket 和 TLS 的支持会有坑。

# 确认运行时版本 node -v npm -v # 初始化并安装常见依赖 npm init -y npm install express ws

安装完先别急着写业务，跑一个最小 WebSocket 回声服务验证环境，能回声说明端口和运行时都没问题。这一步花两分钟，能省掉后面半小时的「到底是代码错还是环境错」的纠结。

3.2 信令服务端最小实现

下面是一个能支撑房间加入和消息转发的信令服务骨架，逻辑刻意保持薄，方便你在此基础上加鉴权、录制等能力。

const express = require("express"); const http = require("http"); const { WebSocketServer } = require("ws"); const app = express(); app.use(express.static("public")); // 托管前端页面 const server = http.createServer(app); const wss = new WebSocketServer({ server }); // roomId -> Map(peerId -> ws) const rooms = new Map(); wss.on("connection", (ws) => { ws.peerId = null; ws.roomId = null; ws.on("message", (raw) => { let msg; try { msg = JSON.parse(raw); } catch (e) { return ws.send(JSON.stringify({ type: "error", reason: "bad json" })); } if (msg.type === "join") { ws.peerId = msg.peerId; ws.roomId = msg.roomId; if (!rooms.has(msg.roomId)) rooms.set(msg.roomId, new Map()); const room = rooms.get(msg.roomId); // 通知已有成员：有新 peer 进来了 for (const [pid, peer] of room) { peer.send(JSON.stringify({ type: "peer-joined", peerId: msg.peerId })); } room.set(msg.peerId, ws); // 回给新成员当前房间成员列表 ws.send(JSON.stringify({ type: "joined", peers: [...room.keys()].filter((id) => id !== msg.peerId) })); return; } // offer / answer / candidate 一律定向转发 if (["offer", "answer", "candidate"].includes(msg.type)) { const room = rooms.get(ws.roomId); if (!room) return; const target = room.get(msg.target); if (target && target.readyState === 1) { target.send(JSON.stringify({ ...msg, from: ws.peerId })); } } }); ws.on("close", () => { const room = rooms.get(ws.roomId); if (!room) return; room.delete(ws.peerId); for (const peer of room.values()) { peer.send(JSON.stringify({ type: "peer-left", peerId: ws.peerId })); } if (room.size === 0) rooms.delete(ws.roomId); }); }); server.listen(8080, () => console.log("signaling on :8080"));

逻辑说明：rooms用嵌套 Map 存房间和成员，查找是 O(1)。join 时先广播给老成员再把自己加进去，顺序不能反，否则新成员会收到自己的加入通知。offer/answer/candidate 只做定向转发，服务端不碰 SDP 内容，这是保持服务端稳定的关键。参数上server.listen的端口要和前端 WebSocket 连接地址一致，生产环境记得套 TLS，否则浏览器在 HTTPS 页面下会拒绝连 ws://。

3.3 客户端连接与最小通话验证

服务端跑起来后，用两个浏览器标签页分别加入同一房间，验证能否看到对方的视频。客户端核心是拿到成员列表后，对每个已有成员主动发 offer。

const ws = new WebSocket("ws://localhost:8080"); const pcs = new Map(); // peerId -> RTCPeerConnection ws.onopen = () => { ws.send(JSON.stringify({ type: "join", roomId: "room1", peerId: "peer-" + Date.now() })); }; ws.onmessage = async (evt) => { const msg = JSON.parse(evt.data); if (msg.type === "joined") { // 对已有成员逐个发起连接 for (const pid of msg.peers) await createOffer(pid); } else if (msg.type === "peer-joined") { // 新成员由对方发起，这里只等 offer } else if (msg.type === "offer") { const pc = getPC(msg.from); await pc.setRemoteDescription(msg.sdp); const answer = await pc.createAnswer(); await pc.setLocalDescription(answer); ws.send(JSON.stringify({ type: "answer", target: msg.from, sdp: answer })); } else if (msg.type === "answer") { await pcs.get(msg.from).setRemoteDescription(msg.sdp); } else if (msg.type === "candidate") { await pcs.get(msg.from).addIceCandidate(msg.candidate); } }; async function createOffer(pid) { const pc = getPC(pid); const offer = await pc.createOffer(); await pc.setLocalDescription(offer); ws.send(JSON.stringify({ type: "offer", target: pid, sdp: offer })); } function getPC(pid) { if (pcs.has(pid)) return pcs.get(pid); const pc = new RTCPeerConnection({ iceServers: [{ urls: "stun:stun.example.internal:3478" }] }); pc.onicecandidate = (e) => { if (e.candidate) ws.send(JSON.stringify({ type: "candidate", target: pid, candidate: e.candidate })); }; pc.ontrack = (e) => { const video = document.createElement("video"); video.srcObject = e.streams[0]; video.autoplay = true; document.body.appendChild(video); }; pcs.set(pid, pc); return pc; }

这里的关键约定是「已有成员发起 offer，新成员只应答」，避免双方同时发 offer。ontrack里把远端流挂到 video 元素上，注意要设 autoplay，否则浏览器不会自动播放。如果两个标签页在同一台机器上测试，摄像头可能被占用，可以用getUserMedia加{ video: true, audio: true }前先确认没有其他程序占用设备。

4. 避坑与排查：那些让会议连不上的真实原因

4.1 现象：双方都显示已加入，但视频一直黑屏

原因通常是 ICE 候选没交换成功，或者交换了但没被addIceCandidate消费。常见于 candidate 在 setRemoteDescription 之前就到达，此时addIceCandidate会抛错。解决办法是把早到的 candidate 先缓存进数组，等 remoteDescription 设置完再批量添加。这个坑我踩过不止一次，日志里只看到 candidate 消息发出去了，但连接状态一直停在 checking。

4.2 现象：内网正常，一跨公网就连不上

原因是没有配 TURN，或者 TURN 的 credential 过期。对称型 NAT 下 host 和 srflx 候选都无法建立连接，必须有 relay 候选。排查方法是在客户端把iceTransportPolicy临时设为relay，如果这样能通，就确认是 NAT 穿透问题，去检查 TURN 服务是否可达、凭证是否有效。注意 TURN 的 3478 是 UDP/TCP，5349 是 TLS，防火墙要放行对应端口。

4.3 现象：人一多就卡，上行带宽跑满

原因是 Mesh 拓扑下每个客户端要往 n-1 个方向发流。4 人会议，每人上行要发 3 路，普通宽带上行只有 10～20Mbps，一路 720p 就占 1.5Mbps 左右，3 路加上重传很容易打满。解决办法是限制人数在 4 人以内，或者降低分辨率和码率，用RTCRtpSender.setParameters把 maxBitrate 压到 500kbps 左右。要开大会议就得上 SFU，这是拓扑决定的，不是调参能救的。

4.4 现象：服务端跑几天后内存持续上涨

原因是房间成员断开时没有清理rooms里的映射，或者 close 事件里ws.roomId已被置空导致删不掉。检查 close 回调里是否用ws.roomId和ws.peerId正确删除了成员，并在房间为空时删除整个房间键。另外 WebSocket 的 ping/pong 心跳要开，否则半开连接会一直占着内存。我一般会加一个定时器，每 30 秒扫一遍readyState !== 1的连接强制清理。

4.5 现象：HTTPS 页面下 WebSocket 连接被浏览器拒绝

原因是混合内容策略，HTTPS 页面不允许连 ws://，必须用 wss://。解决办法是给信令服务套 TLS 证书，或者用反向代理统一入口。注意证书要覆盖你实际访问的域名，自签证书浏览器会拦截，测试阶段可以手动信任，生产环境必须用受信任证书。

5. 进阶：把 Peer 模式压榨到极限的几个技巧

5.1 用 Simulcast 让弱网用户也能看清

Mesh 模式下虽然不能像 SFU 那样灵活选层，但发送端可以开 Simulcast，同时发高低两档分辨率，接收端根据带宽选择订阅哪一档。配置方式是在addTransceiver时传sendEncodings。

const transceiver = pc.addTransceiver(track, { direction: "sendrecv", sendEncodings: [ { rid: "h", maxBitrate: 1500000, scaleResolutionDownBy: 1 }, { rid: "l", maxBitrate: 300000, scaleResolutionDownBy: 2 } ] });

rid是这档流的标识，scaleResolutionDownBy: 2表示分辨率减半。接收端通过setParameters里的encodings选择订阅哪一档。注意 Simulcast 在 Mesh 下收益有限，因为每条连接都要独立协商，人数多时协商开销反而上升，建议只在 3～4 人且网络差异大的场景用。

5.2 用 getStats 做质量监控而不是靠感觉

会议卡不卡不能靠用户喊，要主动采集。pc.getStats()返回的 RTCInboundRtpStreamStats 里有 packetsLost、jitter、framesPerSecond，这些是判断质量的硬指标。

我一般每 5 秒采一次，把增量丢包率和 jitter 打到日志里，出问题时能直接看出是网络抖动还是编码跟不上。注意 getStats 是异步的，别在 ontrack 里同步调，会拿不到数据。

5.3 一个我坚持了很久的习惯

每次改完信令逻辑，我一定先用两个标签页在本地跑一遍，再上真机跨网络测。本地能通不代表跨网能通，跨网能通不代表弱网能通。真正让我少加很多班的，是在客户端加一个「连接状态面板」，把 iceConnectionState、signalingState 和 getStats 的关键指标实时显示出来。出问题时不用猜，看一眼状态就知道卡在哪一层。这套 Peer 模式的服务端不复杂，复杂的是网络环境，把可观测性做足，比多写一百行业务代码都值。希望帮到你。

本文还有配套的精品资源，点击获取