WebRTC是浏览器原生支持的实时通信标准，核心包括getUserMedia、RTCPeerConnection和RTCDataChannel；需配合外部信令服务交换SDP、ICE候选及offer/answer角色标识，且依赖HTTPS与STUN/TURN网络配置。
WebRTC（Web Real-Time Communication）是浏览器原生支持的实时通信技术，无需插件就能直接在网页中实现音视频通话、数据传输等点对点（P2P）功能。它不是某个库或框架，而是一套由W3C和IETF共同制定的标准API集合，核心能力包括获取媒体流（getUserMedia）、建立连接（RTCPeerConnection）、传输数据（RTCDataChannel）。
关键组件：三步缺一不可
要完成一次浏览器间的视频通话，必须协同使用以下三个核心接口：
-
MediaDevices.getUserMedia()：请求用户授权并获取本地摄像头和麦克风流（
MediaStream），这是画面和声音的源头； - RTCPeerConnection：负责建立并维护两端之间的加密P2P连接，自动处理NAT穿透、编解码协商、丢包重传等底层细节；
- RTCDataChannel（可选但常用）：在已建立的连接上开辟低延迟数据通道，可用于传递信令以外的信息（如文字、状态、自定义控制指令）。
信令（Signaling）不是WebRTC的一部分，但必不可少
WebRTC本身不提供发现对方、交换网络信息的方式。你需要额外搭建一个信令服务（比如用WebSocket + Node.js、Firebase、或现成的信令中继如PeerJS Server），来传递三类关键信息：
- 会话描述协议（SDP）：包含本端支持的编解码器、分辨率、网络候选地址等，用于“告诉对方我怎么连你”；
- ICE候选（ICE Candidate）：本端探测到的可能的网络路径（如局域网IP、公网STUN地址、TURN中继地址），需逐条发送给对方；
- 角色标识（offer/answer）：发起方发offer，接收方回answer，双方通过这个握手明确谁主谁从。
注意：这些信息本身不走P2P，必须经由第三方服务器中转——这不违背P2P原则，只是“连接前的引路”，真正音视频流一旦连通就完全绕过服务器。
立即学习“Java免费学习笔记（深入）”；
简易实现流程（以两个浏览器为例）
假设A想呼叫B，典型步骤如下：
- A调用
getUserMedia拿到本地流，加到RTCPeerConnection实例中； - A调用
createOffer()生成offer，用setLocalDescription()保存，并通过信令服务器发给B； - B收到offer后，调用
setRemoteDescription()存下A的信息，再调用createAnswer()生成answer，发回A； - A收到answer后，也调用
setRemoteDescription()； - 双方监听
icecandidate事件，把各自发现的ICE候选实时发给对方； - 当双方都收集到可用候选且连接状态变为
connected，视频流就会自动渲染到标签中。
常见卡点与建议
-
HTTPS必需：现代浏览器只允许在安全上下文（
https://或localhost）中启用摄像头和RTCPeerConnection； -
STUN/TURN服务要配好：纯内网测试可用
stun:stun.l.google.com:19302，但跨运营商或企业防火墙时大概率需要自建或商用TURN服务器； -
不要手动操作SDP字符串：除非有特殊需求，否则全程用
setLocalDescription/setRemoteDescription交由浏览器处理； -
监听连接状态变化：关注
iceConnectionState（如connected、disconnected、failed）比单纯看onaddstream（已废弃）更可靠。
基本上就这些。不复杂但容易忽略信令和网络配置环节。跑通一次端到端视频后，扩展聊天、共享屏幕、多端会议就都是水到渠成的事了。
