17370845950

WebRTC是浏览器原生支持的点对点音视频通信技术，核心由MediaStream、RTCPeerConnection和RTCDataChannel三部分组成，需信令服务与STUN/TURN服务器协同实现连接。

WebRTC 是浏览器原生支持的实时音视频通信技术，不用装插件、不依赖中间服务器转发媒体流，两个浏览器之间能直接“面对面”传视频和音频。构建视频聊天应用的核心，就是用它建立点对点连接、交换媒体流、处理网络变化。

WebRTC 的三个关键组件

它不是单个 API，而是由三部分协同工作：

• MediaStream（获取音视频）：用 navigator.mediaDevices.getUserMedia() 拿到本地摄像头和麦克风流，显示在页面上靠 标签。
• RTCPeerConnection（建立连接）：真正传输音视频的管道。它自动处理编解码、带宽适配、NAT 穿透（通过 STUN/TURN 服务器），你只需配置、创建 Offer/Answer、交换信令。
• RTCDataChannel（传任意数据）：可选，适合发送文字消息、文件片段或控制指令，走的是同一条 P2P 连接，低延迟。

必须准备的基础设施：信令 + STUN/TURN

WebRTC 自己不负责“怎么找到对方”，这得靠你实现的信令服务（比如 WebSocket 或 HTTP）。双方要交换三类信息：

• Session Description（SDP）：描述自己支持什么编码、分辨率、端口等，即 Offer 和 Answer；
• ICE Candidate：网络地址候选（如本机 IP、公网 IP、中继地址），用于连通性检测；
• 用户身份标识（比如房间号或用户 ID）：让服务端知道谁该和谁配对。

STUN 服务器帮你发现公网地址（90% 场景够用）；遇到严格防火墙或对称 NAT，就得加 TURN 服务器中转媒体流——推荐用免费的 Twilio STUN/TURN 或自建 Coturn。

最小可行视频聊天流程（两人间）

假设 A 主动发起，B 加入同一房间：

• A 调用 getUserMedia 获取本地流 → 添加到 RTCPeerConnection → 调用 createOffer → setLocalDescription → 发 Offer 给 B；
• B 收到 Offer → setRemoteDescription → 调用 createAnswer → setLocalDescription → 发 Answer 给 A；
• A 收到 Answer → setRemoteDescription；
• 双方监听 icecandidate 事件，把每个 Candidate 通过信令发给对方；
• 监听 addstream（旧版）或 track（新版）事件，把对方的远程流绑定到自己的 元素上。

实际开发中容易踩的坑

新手常卡在这几个地方：

• HTTPS 必须开启：getUserMedia 在非 HTTPS（或 localhost 以外的 http）下会被浏览器禁用；
• 忽略 ICE 状态：连接失败时多看看 iceConnectionState 是 “failed” 还是 “disconnected”，配合日志查 Candidate 是否正常交换；
• 没处理 track 动态添加：新版 Chrome/Firefox 不再触发 addstream，要用 pc.ontrack = e => { video.srcObject = e.streams[0]; }；
• 忘记关闭资源：离开页面前调用 pc.close()、stream.getTracks().forEach(t => t.stop())，否则摄像头灯常亮。

基本上就这些。不复杂但容易忽略细节。跑通两人直连后，再扩展多人（用 SFU 架构）、录制、美颜、屏幕共享，都是顺延出来的能力。