javascript WebRTC是什么_如何实现点对点的视频通话？_技术教程

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原则，只是“连接前的引路”，真正音视频流一旦连通就完全绕过服务器。

简易实现流程（以两个浏览器为例）

假设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（已废弃）更可靠。