2、WebRTC整体架构：WebRTC的架构分层、核心模块介绍

好，咱们今天聊聊WebRTC的整体架构。说实话，很多初学者一上来就写代码，结果遇到问题根本不知道从哪查起。我个人习惯是，先搞清楚这玩意儿到底分几层，每层管什么。就像盖房子，你得先知道地基、承重墙、水电管线都在哪，对吧？

2.1 架构分层：三层模型

WebRTC的架构，说白了就是三层：应用层、核心引擎层、底层传输层。我画了张图，你一看就明白。

你看，最上层是应用层，就是我们写JavaScript调用的那些API——getUserMedia、RTCPeerConnection、RTCDataChannel。中间是核心引擎层，这是WebRTC最复杂、最核心的部分。最下面是传输层，负责数据怎么从A点到B点。

2.2 核心模块详解

2.2.1 音视频引擎

音视频引擎，我习惯叫它「多媒体心脏」。它负责三件事：采集、处理、编解码。

• 采集：通过getUserMedia拿到摄像头和麦克风的数据流。嗯，这里要注意，不同浏览器对设备权限的处理不太一样，我踩过坑。
• 处理：包括回声消除（AEC）、降噪（NS）、自动增益控制（AGC）。我曾经在一个会议室场景里，回声消除没调好，结果对方听到自己的声音延迟了半秒又传回来，那体验简直灾难。
• 编解码：VP8、VP9、H.264、AV1。浏览器默认支持VP8和H.264，但VP9的压缩率更高，画质更好。

2.2.2 传输层

传输层是WebRTC的「高速公路」。它要解决两个核心问题：怎么找到对方，以及怎么安全高效地传数据。

协议/技术	作用	我的经验
ICE	交互式连接建立，找到最优路径	ICE的候选者收集顺序很重要，我遇到过UDP被防火墙阻断，最后靠TURN中继才连上
STUN	获取公网IP和端口	大部分场景够用，但对称NAT下STUN会失效
TURN	中继转发，穿透失败时的保底方案	带宽成本高，我一般只在P2P连不上时才启用
DTLS	加密传输通道	握手延迟大约1-2个RTT，对实时性有轻微影响
SRTP	加密音视频数据	默认开启，你不需要额外配置

你想想看，为什么WebRTC要用UDP而不是TCP？因为实时通信最怕延迟。TCP丢包会重传，导致后续数据包排队等待，延迟越来越高。UDP丢包就丢了，大不了用前向纠错（FEC）或者丢帧补偿。说白了，实时通信是「宁可丢包，不要延迟」。

2.2.3 信令

信令是WebRTC里「最容易被误解」的部分。很多人以为WebRTC自带信令，其实不是。WebRTC只规定了信令的状态机和SDP格式，但信令的传输方式——你用WebSocket、HTTP轮询、还是邮件发送——完全由开发者自己决定。

信令的核心就是交换两样东西：

1. SDP（会话描述协议）：描述你的媒体能力，比如支持哪些编解码器、分辨率、带宽等。
2. ICE候选者：告诉对方你的IP地址和端口，方便建立P2P连接。

2.3 浏览器支持情况

说到浏览器支持，我记得2015年那会儿，Chrome和Firefox已经支持了，但Safari和Edge还在观望。现在情况好多了，主流浏览器基本都支持WebRTC，但细节上还是有差异。

浏览器	WebRTC支持	编解码器	备注
Chrome	✅ 完整支持	VP8, VP9, H.264, AV1	最稳定，推荐开发首选
Firefox	✅ 完整支持	VP8, VP9, H.264	对VP9支持较好
Safari	✅ 支持（14+）	H.264, VP8	早期版本有兼容问题，现在基本OK
Edge	✅ 完整支持	VP8, H.264	Chromium内核后与Chrome一致
微信内置浏览器	⚠️ 部分支持	H.264	X5内核，建议用H.264

为什么会这样？因为WebRTC标准虽然统一了API，但底层的编解码器实现、ICE策略、甚至getUserMedia的约束语法，各家浏览器都有「小脾气」。我建议你开发时，至少用Chrome和Safari各测一遍，这两个浏览器的差异最大。

---