17370845950

WebRTC是浏览器原生支持的实时音视频通信技术，核心组件包括MediaStream（获取音视频）、RTCPeerConnection（建立P2P连接）和RTCDataChannel（传输数据），需信令服务器交换SDP和ICE候选者，并依赖STUN/TURN穿透NAT。

WebRTC（Web Real-Time Communication）是浏览器原生支持的实时音视频通信技术，无需插件即可实现点对点（P2P）的视频通话、音频通话和数据传输。它直接在浏览器中运行，核心能力包括媒体采集、编解码、网络传输和连接建立，关键在于用 JavaScript 控制整个流程。

WebRTC 的三个核心组件

要实现点对点视频通话，离不开以下三部分协同工作：

• MediaStream（获取音视频）：通过 navigator.mediaDevices.getUserMedia() 获取本地摄像头和麦克风流，生成 MediaStream 对象，可直接绑定到 标签播放。
• RTCPeerConnection（建立P2P连接）：负责加密、传输、重传、带宽自适应等，是 WebRTC 的“通信管道”。它不关心信令，但依赖信令交换 SDP 和 ICE 候选者。
• RTCDataChannel（可选，传数据）：在已建立的 P2P 连接上双向传输任意二进制或文本数据，适合聊天、共享白板等场景。

为什么需要信令服务器？

RTCPeerConnection 本身不负责发现对方或传递连接信息。两个浏览器必须先交换三类关键信息才能连通：

• SDP（Session Description Protocol）：描述本端支持的编解码器、分辨率、传输协议等，分为 offer（发起方创建）和 answer（应答方返回）。
• ICE 候选者（ICE Candidates）：可能的网络路径，比如本机 IP、公网 STUN 地址、中继 TURN 地址。双方需互相告知所有候选者，让 RTCPeerConnection 自动选择最优链路。
• 这些信息不能靠 WebRTC 自己传递，必须借助外部通道——即信令服务器（如 WebSocket、Socket.IO、甚至 HTTP 轮询）。它只负责“递纸条”，不参与媒体传输。

实现视频通话的典型流程

以 A 主叫 B 为例，简化步骤如下：

• A 调用 getUserMedia 获取本地流 → 添加到 RTCPeerConnection（addTrack 或 addStream）→ 调用 createOffer() → setLocalDescription(offer) → 通过信令服务器把 offer 发给 B。
• B 收到 offer → 创建自己的 RTCPeerConnection → setRemoteDescription(offer) → 调用 createAnswer() → setLocalDescription(answer) → 把 answer 发回 A。
• A 收到 answer → setRemoteDescription(answer)；B 在收集到 ICE 候选者后，通过信令逐个发给 A；A 同样将自己收集到的候选者发给 B。
• 双方都收到对方的候选者并调用 addIceCandidate() 后，若网络可达，连接自动建立，ontrack 事件触发，远端视频流即可渲染到页面。

绕不开的 NAT/防火墙：STUN 与 TURN

大多数用户处于路由器后（私有 IP），无法被直接访问。WebRTC 用以下方式解决连接问题：

• STUN 服务器：帮助客户端发现自己的公网 IP 和端口（即“我在外网看起来是什么地址”），适用于大多数对称性不强的 NAT 环境。免费可用（如 stun:stun.l.google.com:19302）。
• TURN 服务器：当 STUN 失败（如企业级对称 NAT 或防火墙严格拦截），TURN 充当中继，所有音视频流经其转发。需自行部署或使用商业服务（如 Twilio Network Traversal Service）。
• 实际配置中，通常同时提供 STUN 和 TURN 服务器地址给 RTCPeerConnection，由其自动按优先级尝试连接路径。

不复杂但容易忽略。真正写起来要处理错误回调、连接状态监听（iceConnectionState）、流事件（ontrack、onremovetrack）、重连逻辑和兼容性（如 Safari 对某些 API 的差异）。但只要理清信令职责、SDP 生命周期和 ICE 流程，一个基础双人视频通话就能跑通。