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

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 全景图

+--------------------------------------------------+ | 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()

功能：请求用户授权访问摄像头/麦克风等媒体设备
返回：Promise 解析为 MediaStream 对象

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

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

3.3.2 MediaStream 结构：

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

3.3.3 常见应用方式：

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

视频处理：

// 通过 Canvas 处理视频帧 const canvas = document.getElementById('videoCanvas'); const ctx = canvas.getContext('2d'); function processFrame() { ctx.drawImage(videoElement, 0, 0); // 应用图像滤镜等处理 requestAnimationFrame(processFrame); }

直接播放：

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

四、网络穿透：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）