跳到主要内容

本篇是 WebRTC 101 系列 第 6 篇（收尾），从"一对一 Demo"走向"多人/生产"：Mesh / SFU / MCU 三种架构怎么选，TURN、信令、监控怎么做。原理为主，带选型速查。

架构与生产选型：Mesh / SFU、TURN、信令与监控

前五篇让你能"两个人打通一条实时通道"。但真实产品不是一对一 Demo：有 N 个人、有房间、有弱网、有监控、还有国内的网络现实。这一篇把这些"上生产才遇到的问题"收敛成决策表。

1. 三种会议拓扑，先算清"带宽账"​

Mesh（P2P 全网状）SFU（选择性转发）MCU（混合/转码）
服务器做什么什么都不做（纯 P2P）转发媒体流，不转码混合/转码成合成流
每人上行传给其他 N-1 人 = N-1 份只上 1 份自己的流1 份
每人下行N-1 份N-1 份（可每层不同）1 份合成流
服务器 CPU/带宽无带宽大、CPU 小CPU 极高、成本高
适合人数≤ 4~6（受上传带宽限制）几十~几百（配合级联）曾经的大广播/兼容老端
特性（Simulcast/录制）无中心，难天然支持支持但贵

一句话结论（也是行业共识）：

小会自己玩用 Mesh 起步；任何要做多人/规模/录制/弱网适配的产品，直接上 SFU。

为什么 SFU 是事实标准：它不转码（所以省钱省延迟），配合第 4 篇的 Simulcast/SVC，让接收端/服务器按带宽挑"哪一层"转发——会议产品要的自适应、录制、字幕注入都天然发生在 SFU 这个"中心点"上。商业/开源大厂（Google Meet、Zoom、Teams、LiveKit、Jitsi、声网等）全是 SFU 思路。

2. 如果你要自建：开源 SFU 速查​

项目语言定位 / 特点
mediasoupNode/C++底层 SFU 库，灵活、需自己写业务逻辑，社区成熟
LiveKitGo全家桶（SFU + 信令 + 录制 + SDK），上手快，云/自建都行
Jitsi VideobridgeJava老牌 SFU，配 Jitsi Meet 全栈
JanusC通用网关，插件化，不止视频会议

选型倾向（个人观察，供参考）：要最小自研、快上线选 LiveKit；要深度掌控、跟业务深度耦合选 mediasoup（市面上很多"二次封装成服务"的也是这个思路）；国内对延迟/合规敏感时把 SFU + TURN 都部署在就近机房。

3. 别省的那台服务器：TURN 自建（coturn）​

第 3 篇的结论延续到这里：凡是"必须能通"的场景都要有 TURN；而国内用公共 STUN/TURN 十有八九不稳。自建 TURN 用 coturn 一台云主机起步即可：

# 概念示意（具体以官方文档为准）
turnserver -n --realm=example.com \
  --use-auth-secret --static-auth-secret=你的长期密钥 \
  --listening-port=3478 --no-tls --no-dtls \
  --min-port=49152 --max-port=65535

要点：

  • 必须开的端口：UDP 3478（TURN 主端口）、TCP 3478、再开 TCP/UDP 443 兜底（很多网络只放行 443）；
  • 凭证用短期票据：use-auth-secret + 用户名带过期时间戳，由你的服务端按需签发（几分钟过期），别写死长密钥到前端；
  • 带宽预算：TURN 转发每路约等于通话码率的上行+下行，按并发峰值×码率×2 估服务器出口带宽；
  • 上线前用工具验证：看 chrome://webrtc-internals 里 candidate 是否出现 relay，以及 relay 的 RTT 是否可接受。

4. 信令服务：媒体不过它，但它是"神经中枢"​

重申第 2 篇：信令自建。生产级信令服务要管的比 Demo 多得多：

  • 房间/会话管理：房间号、加入/离开、成员列表、主持人概念；
  • 描述中继：转发 offer/answer/candidate（WebSocket 即可），鉴权要前置；
  • 扩展性：无状态化后用 pub/sub 横向扩展（消息只在中控流动，媒体不走它）；
  • 与 SFU 的分工：SFU 场景下，客户端通过信令向 SFU 申请"发布/订阅某路流"，方向控制也走信令。

架构分层记忆法：信令管"要不要、谁跟谁"；ICE/DTLS 管"能不能、安不安全"；SFU/TURN 管"怎么分发、通不通"——三个问题分别由信令服务、浏览器栈、媒体基础设施回答。

5. 上线前必须接的监控与体检​

  • 每个客户端上报 getStats() 聚合：关注四组指标——网络（RTT、packetsLost、抖动）、码率（收/发 bitrate）、质量降级（分辨率/帧率是否被自适应压了）、路径类型（candidate-pair.state、是否 relay）；
  • 出问题先看 chrome://webrtc-internals：排查"卡/断/黑"的第一现场（第 4 篇讲过内容密文，全看统计）；
  • 告警阈值建议：disconnected/failed 会话比例、高丢包、长期低上行码率，都是"该扩容 TURN / 该看弱网策略"的信号；
  • 弱网策略：预留 Simulcast 让低带宽端降层、必要时 iceTransportPolicy: relay 保证可通（牺牲延迟保连通）。

6. 安全与隐私清单（收个尾）​

  1. 内容加密是强制的（DTLS/SRTP），指纹经信令绑定，防中间人——别自己发明"明文增强"；
  2. TURN 凭证走短期票据 + HTTPS 签发；TURN 服务器本身建议加访问控制；
  3. 想极端隐私用 iceTransportPolicy: "relay"，别把用户真实 IP 打到日志/分析里（第 3、0 篇反复提醒）；
  4. 信令通道做鉴权与限流（防刷房间、防盗用你的 TURN 带宽）；
  5. 审查依赖：浏览器实现已内建安全，但你自建的 SFU/信令/TURN 是新增攻击面——保持组件更新、最小暴露端口。

7. 整个 101 系列收束​

问题答案在哪篇
画面怎么来的1 媒体采集
怎么"约好"格式2 信令与 SDP
怎么"打通"3 NAT 与 ICE
媒体怎么传4 媒体平面传输
数据怎么传5 DataChannel
怎么做产品本篇

回到第 0 篇那张三层图：本系列自底向上把"连接层"（2、3）和"媒体/数据层"（4、5）讲完，采集（1）与生产（6）封口。接下来真正缺的是动手——路线图里预留的「7+ 实操坑位」，等把本地 Demo（同页双 PeerConnection → 双浏览器 → 接信令 + coturn）跑一轮，把踩过的坑一条条补进去，那篇才是这个系列从"能讲"到"能跑"的临门一脚。

参考与来源​