WebRTC是浏览器原生支持的实时音视频通信技术，核心组件包括MediaStream（获取音视频）、RTCPeerConnection（建立P2P连接）和RTCDataChannel（传输数据），需信令服务器交换SDP和ICE候选者，并依赖STUN/TURN穿透NAT。
WebRTC（Web Real-Time Communication）是浏览器原生支持的实时音视频通信技术，无需插件即可实现点对点（P2P）的视频通话、音频通话和数据传输。它直接在浏览器中运行，核心能力包括媒体采集、编解码、网络传输和连接建立，关键在于用 JavaScript 控制整个流程。
WebRTC 的三个核心组件
要实现点对点视频通话，离不开以下三部分协同工作：
-
MediaStream（获取音视频）：通过
navigator.mediaDevices.getUserMedia()获取本地摄像头和麦克风流，生成MediaStream对象，可直接绑定到<video>标签播放。 - RTCPeerConnection（建立P2P连接）：负责加密、传输、重传、带宽自适应等，是 WebRTC 的“通信管道”。它不关心信令，但依赖信令交换 SDP 和 ICE 候选者。
- RTCDataChannel（可选，传数据）：在已建立的 P2P 连接上双向传输任意二进制或文本数据，适合聊天、共享白板等场景。
为什么需要信令服务器？
RTCPeerConnection 本身不负责发现对方或传递连接信息。两个浏览器必须先交换三类关键信息才能连通：
- SDP（Session Description Protocol）：描述本端支持的编解码器、分辨率、传输协议等，分为 offer（发起方创建）和 answer（应答方返回）。
- ICE 候选者（ICE Candidates）：可能的网络路径，比如本机 IP、公网 STUN 地址、中继 TURN 地址。双方需互相告知所有候选者，让 RTCPeerConnection 自动选择最优链路。
- 这些信息不能靠 WebRTC 自己传递，必须借助外部通道——即信令服务器（如 WebSocket、Socket.IO、甚至 HTTP 轮询）。它只负责“递纸条”，不参与媒体传输。
实现视频通话的典型流程
以 A 主叫 B 为例，简化步骤如下：
立即学习“Java免费学习笔记（深入）”；
- A 调用
getUserMedia获取本地流 → 添加到RTCPeerConnection（addTrack或addStream）→ 调用createOffer()→setLocalDescription(offer)→ 通过信令服务器把 offer 发给 B。 - B 收到 offer → 创建自己的
RTCPeerConnection→setRemoteDescription(offer)→ 调用createAnswer()→setLocalDescription(answer)→ 把 answer 发回 A。 - A 收到 answer →
setRemoteDescription(answer)；B 在收集到 ICE 候选者后，通过信令逐个发给 A；A 同样将自己收集到的候选者发给 B。 - 双方都收到对方的候选者并调用
addIceCandidate()后，若网络可达，连接自动建立，ontrack事件触发，远端视频流即可渲染到页面。
绕不开的 NAT/防火墙：STUN 与 TURN
大多数用户处于路由器后（私有 IP），无法被直接访问。WebRTC 用以下方式解决连接问题：
-
STUN 服务器：帮助客户端发现自己的公网 IP 和端口（即“我在外网看起来是什么地址”），适用于大多数对称性不强的 NAT 环境。免费可用（如
stun:stun.l.google.com:19302）。 - TURN 服务器：当 STUN 失败（如企业级对称 NAT 或防火墙严格拦截），TURN 充当中继，所有音视频流经其转发。需自行部署或使用商业服务（如 Twilio Network Traversal Service）。
- 实际配置中，通常同时提供 STUN 和 TURN 服务器地址给
RTCPeerConnection，由其自动按优先级尝试连接路径。
不复杂但容易忽略。真正写起来要处理错误回调、连接状态监听（iceConnectionState）、流事件（ontrack、onremovetrack）、重连逻辑和兼容性（如 Safari 对某些 API 的差异）。但只要理清信令职责、SDP 生命周期和 ICE 流程，一个基础双人视频通话就能跑通。
