一句话总结：
WebRTC搞视频会议就像拉个微信群聊——不用中间服务器转手（P2P直连），自带降噪美颜（音视频处理），网卡了还能智能降分辨率（抗弱网）！
一、WebRTC的两大核心平面
WebRTC本身只负责建立端到端的加密媒体传输通道，但一个完整的通信系统需要两个独立的层面协同工作：
1. 信令平面（Signaling Plane）：系统的大脑
-
定义：WebRTC规范未定义信令标准。开发者需要自行实现一个服务器（通常使用WebSocket + HTTP API），用于处理以下逻辑：
- 会话协商（SDP交换） ：交换“名片”，A告诉B自己的编码能力、IP地址候选等。
- 房间管理：谁在房间里，谁加入了，谁离开了。
- 权限控制：谁有权发言，谁是管理员。
- 消息路由：将A的Offer转发给B，将B的Answer转发给A。
2. 媒体平面（Media Plane）：系统的管道
- 定义：WebRTC的核心能力所在，使用SRTP（安全实时传输协议）传输加密的音视频数据。
- 关键技术：包括音视频引擎（采集、编解码、降噪AEC）、传输层（RTP/RTCP）和网络自适应（拥塞控制）。
二、架构演进：从P2P到SFU
1. 架构一：P2P（Peer-to-Peer）模型
- 适用场景：1对1通话。
- 工作原理：数据流直接在两个用户之间传输，不经过服务器中转。服务器仅在建立连接时提供信令交换和NAT穿透辅助（STUN/TURN）。
- 优势：延迟最低，隐私性最好，服务器成本极低。
- 致命缺陷：不适用于多人会议。当有N个用户时，每个用户需要同时向N-1个其他用户上传数据。如果N=10，上行带宽需求会飙升至无法承受的水平。
2. 架构二：SFU（Selective Forwarding Unit）模型
-
适用场景：多人会议（目前业界标准方案）。
-
工作原理：所有用户都只向SFU服务器发送一路上行流。SFU服务器接收到数据后，根据需要将其复制并转发给房间内的其他所有参会者。
-
优势：
- 上行友好：无论房间多少人，每个用户始终只需1路上行带宽。
- 服务端控制：服务器可以决定转发哪些流，实现动态布局和权限管理。
-
成本：需要消耗服务器带宽，但远低于需要转码的MCU架构。
graph TD
subgraph P2P (Mesh) 架构 (3人会议)
User1 -- Stream --> User2
User1 -- Stream --> User3
User2 -- Stream --> User1
User2 -- Stream --> User3
User3 -- Stream --> User1
User3 -- Stream --> User2
end
subgraph SFU 架构 (3人会议)
U1(User1) -- Upstream --> S(SFU Server)
U2(User2) -- Upstream --> S
U3(User3) -- Upstream --> S
S -- Downstream --> U1
S -- Downstream --> U2
S -- Downstream --> U3
end
三、SFU架构下的高级特性：Simulcast与SVC
为了让SFU能够高效地服务不同网络状况的设备（例如PC和手机同时在线），需要Simulcast或SVC技术。
1. Simulcast（联播/多流发送）
- 原理：发送端（如PC）同时编码并发送三个独立分辨率的流（高、中、低）。
- SFU操作：SFU服务器接收全部三路流。当转发给网络好的PC端时，选择高分辨率流；当转发给网络差的手机端时，选择低分辨率流。
- 优点：实现简单，兼容性好。
- 缺点：额外消耗发送端的编码性能和上行带宽。
2. SVC（Scalable Video Coding，可伸缩视频编码）
- 原理：发送端只发送一个经过分层的码流。该码流包含一个基础层（保证基本图像）和多个增强层（提升清晰度）。
- SFU操作：SFU服务器可以根据接收端网络情况，决定转发多少层数据。网络好就转发全部层，网络差就只转发基础层。
- 优点：带宽利用率高，切换更平滑。
- 缺点：对编解码器要求高，部分旧设备支持不佳。
四、连接建立与NAT穿透（ICE流程）
WebRTC如何找到P2P或P2P到SFU的最佳路径？答案是ICE（Interactive Connectivity Establishment）框架。
1. 收集候选地址（Candidate Gathering）
- Host Candidate：设备本地IP地址（如192.168.1.10）。
- STUN Server (Session Traversal Utilities for NAT) ：向公网STUN服务器发请求，服务器返回该设备在公网上的IP和端口（NAT映射地址）。类比：查询自己家在地图上的公开坐标。
- TURN Server (Traversal Using Relays around NAT) ：当中转服务器使用。当STUN失败时（如对称型NAT），所有流量都通过TURN服务器转发。这是最后的保底方案，会增加延迟和服务器成本。
2. 协商与连通性检查
- 双方通过信令服务器交换所有收集到的候选地址。
- 双方尝试向对方的所有候选地址发送“连通性检查”包。
- 路径选择：优先选择P2P直连路径（Host/STUN），如果失败，则降级到TURN中继路径。
// 示例：配置STUN和TURN服务器
const config = {
iceServers: [
{ urls: 'stun:stun.l.google.com:1902' }, // 谷歌的公共STUN服务
{
urls: 'turn:my-turn-server.com:3478', // 备用的TURN服务器
username: 'user',
credential: 'password'
}
]
};
const peerConnection = new RTCPeerConnection(config);
五、实战避坑指南
- 信令服务器的健壮性：断线重连和状态同步是信令服务器设计的核心难点。必须保证用户在网络切换（Wi-Fi/4G）后能快速恢复会话状态。
- TURN服务器的必要性：根据统计，约有10%-15%的网络连接无法通过STUN完成P2P穿透，必须依赖TURN中转。为保证接通率，商业部署中TURN服务器必不可少。
- HTTPS环境要求：出于安全考虑，现代浏览器禁止在非HTTPS环境下调用
getUserMedia获取摄像头和麦克风权限。 - 音视频处理顺序：在获取
MediaStream后，应先进行本地预览和音频处理（如关闭本地回声），然后再通过addTrack添加到RTCPeerConnection中。 - 资源释放：会议结束后，必须调用
track.stop()关闭媒体轨道，并调用peerConnection.close()释放连接资源，否则会导致摄像头指示灯常亮和内存泄漏。
