WebRTC是HTML5实现浏览器间低延迟P2P音视频通信的核心技术，依赖getUserMedia、RTCPeerConnection和RTCDataChannel三组件协同工作，需信令服务器交换SDP与ICE候选，并通过STUN/TURN穿透NAT。
WebRTC（Web Real-Time Communication）是HTML5中实现浏览器间点对点音视频通信的核心技术，无需插件、不依赖中间服务器传输媒体流，真正实现实时、低延迟的P2P交互。但需注意：**“点对点”仅指媒体流直连，信令交换和连接协商仍需服务端辅助**。
核心三组件：getUserMedia + RTCPeerConnection + RTCDataChannel
WebRTC并非单一API，而是由三个关键接口协同工作：
-
getUserMedia：获取本地摄像头/麦克风权限并生成媒体流（
MediaStream），是视频通话的“源头”； - RTCPeerConnection：管理P2P连接生命周期，负责媒体流传输、编解码协商、NAT穿透（通过STUN/TURN）、加密与QoS控制；
- RTCDataChannel：在已建立的PeerConnection上开辟双向数据通道，可用于传输文本、文件或自定义信令（非必须，但扩展性强）。
连接建立离不开信令服务（Signaling Server）
浏览器无法直接知道对方IP和媒体能力，必须通过第三方服务交换SDP（会话描述协议）和ICE候选地址。常见做法：
- 用WebSocket或HTTP API搭建轻量信令服务（如Node.js + Socket.IO）；
- A端调用
createOffer()生成本地SDP，发送给B端； - B端收到后调用
setRemoteDescription()，再用createAnswer()回应； - 双方通过
addIceCandidate()持续交换网络可达的ICE候选（如主机地址、STUN反射地址、TURN中继地址）。
绕不开的NAT/防火墙：STUN与TURN服务器
纯P2P在公网直连场景可行，但多数用户处于路由器后（NAT环境），需借助服务器辅助穿透：
立即学习“前端免费学习笔记（深入）”；
-
STUN服务器（如
stun.l.google.com:19302）帮助获取公网映射地址，适用于大多数对称NAT以外的情况； -
TURN服务器（如
coTURN）在STUN失败时充当中继，保障连通性，但会增加延迟和带宽成本； - 初始化
RTCPeerConnection时需传入iceServers配置，至少包含一个STUN地址。
基础代码结构示例（简化版）
以下为发起方关键逻辑片段（接收方逻辑对称）：
const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
// 获取本地视频流
navigator.mediaDevices.getUserMedia({ video: true, audio: true })
.then(stream => {
document.getElementById('localVideo').srcObject = stream;
stream.getTracks().forEach(track => pc.addTrack(track, stream));
});
// 创建offer并发送至对方
pc.createOffer()
.then(offer => pc.setLocalDescription(offer))
.then(() => sendToSignalingServer({ type: 'offer', sdp: pc.localDescription }));
// 监听远端SDP和ICE候选
pc.ontrack = e => {
document.getElementById('remoteVideo').srcObject = e.streams[0];
};
pc.onicecandidate = e => {
if (e.candidate) sendToSignalingServer({ type: 'candidate', candidate: e.candidate });
};
实际项目中还需处理错误回调、连接状态监控（iceConnectionState）、重连逻辑及移动端兼容性（如iOS Safari对自动播放的限制）。WebRTC强大但细节繁多，建议从成熟库（如simple-peer或peerjs）起步，再逐步深入原生API。
