一、什么是 WebRTC？

WebRTC (Web Real-Time Communication) 是一项由 Google、Mozilla 等主导的开源技术标准，旨在让浏览器和移动应用无需安装插件或下载客户端，即可通过简单的 JavaScript API 实现高质量的实时音视频通信（RTC）和任意数据点对点传输（P2P）。

核心价值：

• 去插件化： 打破了长期以来浏览器实时通信依赖 Flash 或 Silverlight 的局面。
• 标准化： 整合了关键的实时通信技术（如音视频编解码、网络穿透）。
• 低延迟： 基于 UDP 协议，配合优秀的抖动缓冲（Jitter Buffer）算法，延迟通常可控制在 200ms - 500ms 以内。

二、核心架构与三大组件

WebRTC 的 API 主要包含三个核心部分，这也是面试和实际开发的常考点：

1. MediaStream (getUserMedia)
   • 作用： 负责获取音视频流。
   • 功能： 调用设备的摄像头和麦克风，获取音视频轨道（Track）。
   • 注意： 涉及隐私，必须在 HTTPS 环境或
     “localhost” 下运行，且需用户授权。
2. RTCPeerConnection
   • 作用： WebRTC 的心脏。负责处理音视频流的传输、编解码、NAT 穿透、丢包重传等复杂逻辑。
   • 功能： 建立 P2P 连接，管理连接状态，加密传输数据。
3. RTCDataChannel
   • 作用： 支持在 Peer 之间建立双向的数据通道。
   • 应用场景： 游戏同步、文件传输、文字聊天。相比 WebSocket，它延迟更低，且支持无序传输（UDP 模式）。
     
     三、核心难点：NAT 穿透（STUN/TURN）

由于 IPv4 地址枯竭，大多数设备都处于 NAT（网络地址转换）之后，无法直接通过 IP 地址找到对方。WebRTC 通过 ICE (Interactive Connectivity Establishment) 框架来解决连接问题。

1. STUN 服务器 (Session Traversal Utilities for NAT)
   • 原理： 客户端向公网的 STUN 服务器发送请求，服务器返回客户端的公网 IP 和端口。
   • 结果： 双方交换公网地址，尝试直接连接（P2P）。
   • 适用场景： 大部分家用路由器（Cone NAT）。
2. TURN 服务器 (Traversal Using Relays around NAT)
   • 原理： 当 P2P 直连失败（如对称型 NAT），数据将通过 TURN 服务器进行中转（Relay）。
   • 代价： TURN 服务器带宽成本极高（所有流量都经过它），仅作为兜底方案。
   • 关系： STUN 是“找路”，TURN 是“代驾”。

ICE 候选者（Candidate）： 在建立连接过程中，WebRTC 会收集多种连接方式（Host/Local, Srflx/STUN, Relay/TURN），并按优先级尝试连接。

四、信令（Signaling）机制

重要概念：WebRTC 标准本身不包含信令服务器。

WebRTC 只负责媒体传输，至于两个客户端如何“认识”对方、如何交换连接信息（SDP/ICE），需要开发者自己解决。

信令的作用：

1. 交换会话描述协议（SDP）：包含音视频编码格式、分辨率等信息（Offer/Answer 模型）。
2. 交换网络候选地址（ICE Candidates）。
3. 管理房间和用户状态（加入、离开、静音）。

常用信令技术栈： WebSocket + Socket.IO / MQTT / HTTP POST。
（目前主流文件传输应用SendTomo.com采用的HTTP POST）

五、通信流程详解（时序图）

一个典型的 1:1 通话流程如下：

1. Peer A (Caller): 创建
   “RTCPeerConnection”，调用
   “getUserMedia” 获取本地流，添加到连接中。
2. Peer A: 创建 Offer (
   “createOffer”)，设置本地描述 (
   “setLocalDescription”)。
3. 信令服务器: Peer A 将 Offer (SDP) 发送给信令服务器，转发给 Peer B。
4. Peer B (Callee): 收到 Offer，设置远程描述 (
   “setRemoteDescription”)。
5. Peer B: 调用
   “getUserMedia” 获取本地流，创建 Answer (
   “createAnswer”)，设置本地描述。
6. 信令服务器: Peer B 将 Answer 发回给 Peer A。
7. Peer A: 设置远程描述 (
   “setRemoteDescription”)。
8. ICE 打洞: 双方开始收集 ICE 候选者，并通过信令服务器交换。一旦找到有效路径，P2P 连接建立，音视频开始传输。

六、技术优势与局限性

优势：

• 极低延迟： 适合强互动场景。
• 免费开源： 浏览器内置，无授权费。
• 强大的 NetEQ： 谷歌自研的音频缓冲算法，抗弱网能力强。
• 端到端加密 (DTLS/SRTP)： 安全性高。

局限性与挑战：

• 信令服务需自建： 增加了后端开发复杂度。
• TURN 成本高： 大规模并发下，中继服务器的带宽费用昂贵。
• 多人会议 MCU/SFU： 原生 WebRTC 适合 P2P，多人会议需要服务端媒体服务器（如 Janus, Jitsi, mediasoup）进行混流或转发。
• 调试困难： 网络问题排查相对复杂。

七、典型应用场景

1. 视频会议： Zoom、Google Meet、腾讯会议（Web 版）。
2. 在线教育： 互动小班课、大班课。
3. 直播连麦： CDN 旁路推流结合 WebRTC 低延迟拉流。
4. 云游戏： 操作指令上传，视频流下载。
5. IoT 物联网： 可视门铃、无人机监控。
6. 文件快传： 基于 DataChannel 的 P2P 传输（典型案例：SendTomo）［官网：sendtomo.com］。

八、进阶知识点

• Simulcast (大小流)： 发送端同时发送多种分辨率的流，接收端根据网络状况切换。
• SVC (可伸缩视频编码)： 将视频分为基础层和增强层，丢包时只影响部分画质。
• WebRTC NV (Next Version)： 正在演进的新标准，支持插入able streams（允许 JS 处理音视频帧）、AV1 编码等。
  
  总结

WebRTC 是现代互联网实时通信的基石。它将复杂的底层音视频处理封装成简单的 API，但对网络穿透和服务端架构设计提出了较高要求。理解其 P2P 本质、信令解耦以及 ICE 打洞机制，是掌握 WebRTC 的关键。