WebRTC 如何扩展：信令、NAT 穿透与 Mesh/SFU/MCU 的权衡
内容提要
WebRTC是浏览器间直接传输音视频和数据的开放标准，但规范仅覆盖媒体路径，不含信令与NAT穿透。文章介绍RTCPeerConnection、MediaStream、RTCDataChannel三大API，指出信令需自行实现，ICE/STUN/TURN负责连通，并给出基于Node.js、Redis和Socket.IO的信令服务器实现与压测结果，最后比较P2P、SFU、MCU三种拓扑在带宽与连接数上的权衡。
延伸解读
信令与NAT穿透：WebRTC的规范外拼图
WebRTC规范只定义了媒体传输路径，信令和NAT穿透被有意留给开发者。信令需自行实现，通常基于WebSocket或HTTP长轮询交换SDP；NAT穿透依赖ICE框架，通过STUN获取公网地址，TURN在对称NAT等场景下中继流量。这种设计让WebRTC灵活但增加了集成复杂度，开发者必须自行搭建信令服务器并部署STUN/TURN基础设施。
信令服务器压测：轻量但连接数才是瓶颈
文章中的信令服务器基于Node.js、Socket.IO和Redis，在10个副本、每副本1核512MB的配置下，以每秒10万请求压测60秒，四种事件（加入房间、SDP offer/answer、trickle ICE）可用性均超过99.96%。这表明信令服务器处理的是小型JSON消息，CPU通常不是瓶颈，真正的限制在于并发连接数和每连接内存占用。
Mesh、SFU、MCU：拓扑选择决定带宽与成本
P2P全互联连接数呈平方增长，6人通话需15条连接，每端上下行各5Mbps；SFU将上行降至1条连接，总连接数线性增长，但服务器需转发流；MCU进一步将上下行都降至1条，但需实时转码，CPU消耗大且布局固定。对于多数群组通话，SFU在带宽节省和客户端布局控制间取得平衡，MCU更适合录制等特定场景。
生产环境还需关注：连通性、安全与可靠性
除了拓扑，实际部署中还需处理：STUN/TURN可能被网络屏蔽，需通过TLS和标准端口伪装成HTTPS；信令服务器无状态，可像普通Web服务一样水平扩展；旧浏览器需Adapter.js兼容；WebRTC默认DTLS/SRTP加密，但非端到端，需额外措施如强制HTTPS/WSS、TURN认证、限流和PFS；UDP丢包问题可通过FEC冗余数据缓解。
Q&A
WebRTC 规范本身不包含哪些功能？
WebRTC 规范只覆盖媒体路径，不包含信令和 NAT 穿透。信令需要开发者自行实现，NAT 穿透由 ICE/STUN/TURN 处理。
WebRTC 的三个核心 API 分别是什么？
RTCPeerConnection 负责协商编解码器并处理媒体传输；MediaStream 提供音视频源；RTCDataChannel 用于传输非音视频数据。
为什么需要 STUN 和 TURN 服务器？
STUN 帮助发现 NAT 后的公网地址，用于直接连接；TURN 在 STUN 失败时中继流量，确保连通性，但会增加延迟和服务器带宽消耗。
如何实现一个可扩展的 WebRTC 信令服务器？
使用 Node.js 和 Socket.IO 处理 WebSocket 连接，通过 Redis 共享房间状态，并配置负载均衡器的粘性会话，确保连接固定到同一后端实例。
P2P、SFU 和 MCU 三种拓扑在带宽和连接数上有什么差异？
P2P 连接数呈平方增长，带宽消耗大；SFU 将连接数降为线性，上传带宽大幅减少；MCU 进一步降低带宽但需要服务器转码，CPU 负载高。
WebRTC 的安全性如何保障？
WebRTC 默认使用 DTLS 进行密钥交换，SRTP 加密媒体包。但这是传输加密，不是端到端加密。还需强制 HTTPS/WSS、TURN 认证、限流和完美前向保密。
