WebRTC是浏览器原生支持的开放标准，提供MediaStream、RTCPeerConnection和RTCDataChannel三类API实现P2P音视频与数据传输；需信令服务器交换SDP和ICE候选信息以建立连接。
WebRTC（Web Real-Time Communication）是浏览器原生支持的一套开放标准，用于在网页中直接实现点对点（P2P）的音视频通话、数据传输，无需插件或中间服务器转发媒体流。
WebRTC的核心能力
它不是单一API，而是一组协同工作的接口：
- MediaStream（getUserMedia）：获取本地摄像头和麦克风流
- RTCPeerConnection：建立并管理P2P连接，处理编解码、NAT穿透、加密传输
- RTCDataChannel：在已建立的连接上发送任意二进制或文本数据（如聊天消息、文件）
为什么需要信令服务器？
WebRTC本身不负责发现对方或交换网络信息。两个浏览器要连上，必须先互相知道：
– 自己的IP和端口（通过STUN/TURN服务器获取）
– 对方的媒体能力（编解码器、分辨率等）
– 初始连接参数（SDP Offer/Answer）和候选地址（ICE Candidates）
这些信息需通过一个第三方通道传递——这就是“信令”（signaling），通常用WebSocket或HTTP实现，但信令服务器不转发音视频流，只帮忙“牵线”。
实现视频通话的最小关键步骤
以A呼叫B为例（简化逻辑）：
- A调用
getUserMedia获取本地流，塞进RTCPeerConnection.addTrack() - A创建Offer（
pc.createOffer()），设置本地描述（setLocalDescription），通过信令发给B - B收到后，用
setRemoteDescription存下A的Offer，再创建Answer并返回给A - addIceCandidate告诉对方“我能从这个地址连你”
- ontrack事件触发，拿到A的远程视频流，渲染到
标签；反之亦然
绕不开的NAT/防火墙问题：STUN 与 TURN
多数设备在路由器后面，无法被公网直连。WebRTC靠ICE框架自动尝试多种路径：
立即学习“Java免费学习笔记（深入）”；
-
STUN服务器（如
stun:stun.l.google.com:19302）：帮客户端查出自己在公网中的IP:Port，用于直连 - TURN服务器：当STUN失败（如对称NAT），作为中继转发媒体流（需自行部署或使用付费服务，如Xirsys、Twilio Network Traversal）
实际项目中，至少配置1个STUN，复杂网络环境建议加1个TURN备用。
基本上就这些。代码量不大，但逻辑环环相扣，尤其信令顺序和异步时机容易出错。调试时多看chrome://webrtc-internals，能实时看到连接状态、候选对、丢包率等关键指标。
