【流媒体协议】WebRTC 技术详解

[一、什么是 WebRTC？](#一、什么是 WebRTC？)

[1.1 技术背景与发展历程](#1.1 技术背景与发展历程)

1.2核心特点与技术优势

[二、WebRTC 架构全景图](#二、WebRTC 架构全景图)

[2.1 全景图](#2.1 全景图)

[2.2 信令层（Signaling）](#2.2 信令层（Signaling）)

[2.3 媒体引擎](#2.3 媒体引擎)

[2.4 网络传输](#2.4 网络传输)

[2.5 安全层](#2.5 安全层)

[三、WebRTC 核心组件详解](#三、WebRTC 核心组件详解)

[3.1.RTCPeerConnection ------ 音视频通信主干](#3.1.RTCPeerConnection —— 音视频通信主干)

[3.1.1 关键流程](#3.1.1 关键流程)

[3.1.2 核心概念](#3.1.2 核心概念)

[2. RTCDataChannel ------ 低延迟数据传输](#2. RTCDataChannel —— 低延迟数据传输)

[3.2.1 底层协议栈](#3.2.1 底层协议栈)

[3.2.2 特性对比](#3.2.2 特性对比)

[3.2.3 典型应用场景](#3.2.3 典型应用场景)

[3. 媒体处理：getUserMedia 与 MediaStream](#3. 媒体处理：getUserMedia 与 MediaStream)

[3.3.1 navigator.mediaDevices.getUserMedia()](#3.3.1 navigator.mediaDevices.getUserMedia())

[3.3.2 MediaStream 结构：](#3.3.2 MediaStream 结构：)

[3.3.3 常见应用方式：](#3.3.3 常见应用方式：)

[四、网络穿透：ICE / STUN / TURN](#四、网络穿透：ICE / STUN / TURN)

五、安全机制：端到端加密

一、什么是 WebRTC？

WebRTC（Web Real-Time Communication）是由 Google 主导、W3C 与 IETF 标准化的开源项目与浏览器 API，旨在让 Web 应用无需插件即可实现点对点（P2P）的实时音视频通信与数据传输。

1.1 技术背景与发展历程

WebRTC 的诞生源于 2011 年 Google 收购 GIPS（Global IP Solutions）公司，这是一家在音视频编解码和实时通信领域具有深厚技术积累的企业。Google 将 GIPS 的核心音视频引擎开源，并与 W3C（World Wide Web Consortium）和 IETF（Internet Engineering Task Force）合作推动标准化进程。2011 年 5 月，WebRTC 项目正式发布第一个公开版本。

1.2核心特点与技术优势

低延迟性能：通过优化的传输协议和编解码技术，WebRTC 能够实现端到端延迟通常小于 500ms，甚至在某些理想网络条件下可达到 100-200ms 级别
强制加密安全：所有 WebRTC 通信默认使用 DTLS-SRTP 进行端到端加密，支持身份验证和数据完整性保护
跨平台兼容：原生支持现代浏览器（Chrome、Firefox、Safari、Edge等），同时提供 Android 和 iOS 的移动端 SDK，以及 Windows、macOS 和 Linux 的桌面端实现

典型应用场景

视频会议系统：如 Zoom、Google Meet、Microsoft Teams 等主流会议平台都采用了 WebRTC 技术
在线教育平台：支持实时互动白板、屏幕共享和音视频授课功能
远程医疗：用于医生与患者之间的高清视频问诊和医学影像共享
云游戏服务：实现低延迟的游戏画面流传输和操作反馈
IoT 设备控制：通过浏览器直接与智能家居设备建立实时视频监控和控制通道
金融身份验证：用于银行开户等场景的实时人脸识别和活体检测

二、WebRTC 架构全景图

WebRTC 不是一个简单的单一协议实现，而是一个包含多层次的完整技术栈。它主要由以下核心组件构成：协议栈 + API 层 + 媒体引擎的综合体.

2.1 全景图

bash 复制代码

+--------------------------------------------------+
|            Application (JavaScript / C++)        |
+--------------------------------------------------+
|        WebRTC API (PeerConnection, DataChannel)  |
+--------------------------------------------------+
|   Signaling |    Media Engine    |  Networking   |
|   (外部)    | (Audio/Video Codec)| (ICE/STUN/TURN)|
+--------------------------------------------------+
|        DTLS      |       SRTP       |     SCTP     |
+--------------------------------------------------+
|                    UDP / TCP                     |
+--------------------------------------------------+

2.2 信令层（Signaling）

这是 WebRTC 架构中唯一未被标准化的部分
开发者可以根据具体需求选择实现方案：
- WebSocket：适用于浏览器端实时通信
- HTTP：用于简单的轮询式通信
- SIP：适合与 VoIP 系统集成
- 自定义协议：满足特定业务需求
典型信令交互包括：会话初始化、媒体能力协商、网络地址交换等

2.3 媒体引擎

音频编解码：
- 默认采用 Opus 编码（8-48kHz，6-510kbps）
- 支持动态调整比特率和采样率
视频编解码：
- 默认支持 VP8/VP9/AV1（开源方案）
- 可选支持 H.264（需要专利授权）
- 支持 SVC（可伸缩视频编码）
其他功能：
- 回声消除（AEC）
- 噪声抑制（NS）
- 自动增益控制（AGC）

2.4 网络传输

传输协议：
- 基于 UDP 实现低延迟传输
- 通过 QUIC 协议优化传输效率
NAT 穿透方案：
- ICE 框架整合 STUN/TURN
- STUN：用于发现公网地址
- TURN：在中继服务器转发数据
- 支持多种候选地址类型（主机、反射、中继）

2.5 安全层

加密体系：
- DTLS：用于密钥交换（类似 TLS）
- SRTP：媒体流加密（AES 加密）
- SCTP：数据通道加密（支持可靠/不可靠传输）
安全特性：
- 强制加密所有通信
- 支持 Perfect Forward Secrecy
- 端到端加密保护

三、WebRTC 核心组件详解

3.1.RTCPeerConnection ------ 音视频通信主干

RTCPeerConnection 是 WebRTC 的核心 API，负责管理端到端(P2P)连接的整个生命周期，包括媒体协商、连接建立、网络传输和质量监控等关键功能。

3.1.1 关键流程

创建连接 ：new RTCPeerConnection(configuration)，其中 configuration 包含 ICE 服务器配置等参数
添加媒体流 ：addTrack() 方法将本地媒体流添加到连接中
信令交换 ：
- 发起方调用 createOffer() 生成 SDP Offer
- 接收方处理 Offer 后调用 createAnswer() 生成 SDP Answer
ICE 候选交换 ：通过 onicecandidate 事件收集并交换网络候选地址
连接建立：自动选择最优路径建立连接

3.1.2 核心概念

SDP（Session Description Protocol）：

文本格式的协商协议，描述媒体能力（编码器、分辨率、端口等）

示例格式：

复制代码

v=0
o=- 123456789 2 IN IP4 127.0.0.1
s=-
t=0 0
m=video 9 UDP/TLS/RTP/SAVPF 96
a=rtpmap:96 VP8/90000

Offer/Answer 模型：

一方发起 Offer（包含媒体能力），另一方回复 Answer（确认或调整能力）
协商过程确保双方使用兼容的编解码器和传输参数

ICE Candidate：

网络地址候选类型：
- Host Candidate：本地网络接口地址
- Server Reflexive Candidate：通过 STUN 服务器获取的外网映射地址
- Relay Candidate：通过 TURN 服务器中继的地址
使用 ICE 算法选择最优连接路径（通常优先选择直连路径）

2. RTCDataChannel ------ 低延迟数据传输

在已建立的 PeerConnection 上，可创建可靠或不可靠的数据通道，用于传输任意数据（文本、文件、游戏指令等）。

3.2.1 底层协议栈

应用层：RTCDataChannel API
传输层：SCTP（流控制传输协议）
安全层：DTLS（Datagram Transport Layer Security）
网络层：UDP

3.2.2 特性对比

特性	RTCDataChannel	WebSocket
协议	SCTP over DTLS over UDP	TCP
延迟	通常 <100ms	通常 >200ms
可靠性	可配置（可靠/部分可靠）	仅可靠
有序性	可配置（有序/无序）	仅有序
连接方式	P2P	客户端-服务器

3.2.3 典型应用场景

实时游戏状态同步
文件分块传输
远程桌面控制
传感器数据实时传输

3. 媒体处理：getUserMedia 与 MediaStream

3.3.1 navigator.mediaDevices.getUserMedia()

功能：请求用户授权访问摄像头/麦克风等媒体设备

参数：constraints 对象指定所需媒体类型和质量

javascript 复制代码

{
  audio: true,
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    frameRate: { ideal: 30 }
  }
}

返回：Promise 解析为 MediaStream 对象

3.3.2 MediaStream 结构：

包含一个或多个 MediaStreamTrack（媒体轨道）
- AudioTrack：音频数据流
- VideoTrack：视频数据流
每个 Track 有自己的设置和状态（enabled/muted）

3.3.3 常见应用方式：

直接播放：

javascript 复制代码

const videoElement = document.getElementById('localVideo');
videoElement.srcObject = mediaStream;

视频处理：

javascript 复制代码

// 通过 Canvas 处理视频帧
const canvas = document.getElementById('videoCanvas');
const ctx = canvas.getContext('2d');

function processFrame() {
  ctx.drawImage(videoElement, 0, 0);
  // 应用图像滤镜等处理
  requestAnimationFrame(processFrame);
}

流媒体操作：
- 添加/移除 Track：addTrack()/removeTrack()
- 克隆流：clone()
- 获取 Tracks：getAudioTracks()/getVideoTracks()

四、网络穿透：ICE / STUN / TURN

WebRTC 的最大挑战是穿越 NAT 和防火墙 。为此，它采用 ICE（Interactive Connectivity Establishment）框架：

ICE 工作流程

收集候选地址 ：
- Host Candidate：本地 IP（如 192.168.1.10）
- Server Reflexive Candidate：通过 STUN 服务器获取公网映射 IP
- Relay Candidate：通过 TURN 服务器中转（最后手段）
连通性检查 ：双方交换候选地址，尝试所有组合，选择延迟最低、带宽最高的路径
建立连接：成功后锁定最优路径，媒体流直连（P2P）或经 TURN 中转

五、安全机制：端到端加密

WebRTC 强制加密，无法关闭：

媒体流：SRTP（Secure Real-time Transport Protocol） + AES 加密
密钥交换：DTLS（Datagram Transport Layer Security）握手
数据通道：SCTP over DTLS
证书：自动生成自签名证书（可通过 setIdentityProvider 集成 WebAuthn）