WebRTC
2015-02-08 10:57:02 阿炯
本站赞助商链接，请多关照。 WebRTC是一项在浏览器内部进行实时视频和音频通信的技术，是谷歌2010年以6820万美元收购收购Global IT Solutions公司而获得一项技术。即网页实时通信(英语：Web Real-Time Communication)的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。它由用于 Web 实时通信的 JavaScript API 和一组通信协议构成，支持网络上的任何已连接设备成为 Web 上潜在的通信端点。WebRTC 已成为线上通信及协作服务的基石。



WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

Our mission: To enable rich, high quality, RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.

The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others. This page is maintained by the Google Chrome team.

谷歌在官方博客中称：“我们希望让浏览器成为实时通信的创新地所在，到目前为止，实时通信需要使用受版权保护的信号处理技术，并通过插件或下载客户端才能实现，而WebRTC则允许开发人员使用HTML和JavaScript API来创建实时应用。”谷歌码同时还称：“为此我们将与Mozilla和Opera等浏览器厂商密切合作，以便让更广泛的Web社区来部署这项技术。此外，我们还将与IETF和W3C工作组等标准机构合作，以定义一套实时通信标准。”

2012年1月，Google已经把这款软件集成到Chrome浏览器中，同时FreeSWITCH项目宣称支持iSAC audio codec。

如今WebRTC已广泛用于视频通话，但它的功能还不止如此。WebRTC也是完全免费的，它是已嵌入到浏览器中的开源项目，但是你可以根据自己的需要采用它。反过来，当前已经围绕WebRTC创建了一个充满活力和动态的生态系统，围绕着各种开源项目和框架以及科技公司的软件来帮助你构建自己创意想法。WebRTC技术已经较为成熟，其集成了最佳的音/视频引擎，十分先进的代码栈，但是Google对于这些技术不收取任何费用。强大的穿透能力，包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术，并支持代理。

WebRTC在顶部带有一个Javascript API层，可以在浏览器中使用它，这使得在任何地方开发和集成实时通信变得更加容易。在内部，WebRTC仍主要使用C/C++实现，但是大多数使用WebRTC的开发人员无需深入研究这些层即可开发其应用程序。也可以将其集成到应用程序或嵌入式设备中，这样就不需要浏览器。WebRTC的作用是允许访问设备，可以访问设备的麦克风，手机或笔记本电脑上的摄像头，也可以是屏幕本身；可以捕获用户的显示，然后远程共享或记录该屏幕。WebRTC不仅限于语音和视频，它允许发送任何类型的任意数据。它已经围绕着不同的供应商和公司创建了一个充满活力的生态系统，可以为应用提供帮助。比如，基于开源WebRTC技术开发的EasyRTC视频会议云服务，广泛应用在教育、金融、医疗健康、企业培训、远程办公等场景。


2021年1月26日，W3C(万维网联盟)和 IETF (互联网工程任务组)同时宣布 WebRTC(Web Real-Time Communications，Web 实时通信)现发布为正式标准，将音视频通信带到 Web 上任何地方。目前全球都面临着 COVID-19 疫情，WebRTC 让数十亿人无论其设备或地域如何，在疫情期间也能保持联络。WebRTC 的使用已经超越了最初的核心设计，即在浏览器和其他生态(例如本地应用)中支持视频会议和协作系统。现在需要更多的特性和优化。

IETF WebTransport (WEBTRANS) 和 WebRTC Ingest Signaling over HTTPS (WISH) 工作组已经在开展工作，在 IETF 其他工作组的基础上进一步协调、拓展相关工作。其中包括 QUIC(定义支持 WebTransport API 开发的新协议)和 HTTPBIS(指定简单、可扩展的、基于 HTTPS 的信令协议)，以在广播工具和实时媒体广播网之间建立基于 WebRTC 的单向视听会话。W3C WebRTC 工作组已经开始研究 WebRTC Next Version Use Cases，规划 WebRTC 的未来，特别是：
在服务器介导的视频会议中的端到端加密
即时处理音视频材料，包括通过机器学习
物联网(例如 IoT 传感器维持长期连接并寻求最小功耗)

WebRTC 工作组正对现有及新的用例进行迭代，重点理解全部需求及其优先级。W3C 近期开始的 WebTransport 和 Web Codecs 工作预计将低延迟流媒体的优势引入更广大的媒体和娱乐生态系统。它已经成为 W3C 为应用程序开发定义开放 Web 平台的众多标准之一，具有前所未有的潜力。其让开发人员能够构建丰富的交互体验，由巨大的数据存储提供动力，可用于任何设备以及环境。

WebRTC 标准文档可见此处。


组件

视频引擎(VideoEngine)
音效引擎(VoiceEngine)
会议管理(Session Management)
iSAC：音效压缩
VP8：Google自家的WebM项目的视频编解码器
APIs(Native C++ API, Web API)

重要API

WebRTC原生APIs文件是基于WebRTC规格书撰写而成，这些API可分成Network Stream API、 RTCPeerConnection、Peer-to-peer Data API三类。

Network Stream API
MediaStream：MediaStream用来表示一个媒体数据流。
MediaStreamTrack在浏览器中表示一个媒体源。

RTCPeerConnection
RTCPeerConnection：一个RTCPeerConnection对象允许用户在两个浏览器之间直接通讯。
RTCIceCandidate：表示一个ICE协议的候选者。
RTCIceServer：表示一个ICE Server。

Peer-to-peer Data API
DataChannel：数据通道(DataChannel)接口表示一个在两个节点之间的双向的数据通道。

WebRTC 无疑推动和改变了互联网视频，而这仅仅是刚刚开始，除了大家熟悉的 WebRTC-PC、Simulcast 和 SVC，有太多的新技术和新架构出现在 WebRTC 新的标准中，比如 WebTransport、WebCodecs、AV1、E2EE、SFrame、ML 等等。


W3C WebRTC 工作组的主要工作包括以下三个方面：
1、目前最重要的工作，是完成 WebRTC Peer Connection (WebRTC-PC) 标准化，以及相关的标准比如 WebRTC-Stats。

2、Capture，Streams 和 Output 相关的标准，包括 Media Capture and Streams，Screen Capture，Media Capture from DOM Elements，MediaStream Image Capture，MediaStream Recording，Audio Output Devices，以及 Content-Hints。

3、下一代 WebRTC，也就是 WebRTC-NV。

WebRTC-NV 是下一代 WebRTC，在当前 WebRTC 1.0 之后的标准。WebRTC-NV 的工作主要是四个方面：

第一类是对 WebRTC PeerConnection 的扩展。这包括 WebRTC Extensions, WebRTC-SVC, 以及 Insertable Streams。我特别强调这些工作都依赖于 “Unified Plan”，现在已经是默认的 SDP 规范了。例如，如果要使用 Insertable Streams 来支持 E2EE (End-to-End Encryption，端到端加密)，那么首先要支持 “Unified Plan”。

第二类，和 WebRTC-PC 相比，还不够成熟和完善，比如 WebRTC Identity，WebRTC Priority Control 和 WebRTC DSCP。

第三类是对 Capture 的扩展，比如 MediaStreamTrack Insertable Streams，Media Capture and Streams Extensions，和 MediaCapture Depth Stream Extensions。

第四类是独立的标准，它们没有必要依赖 RTCPeerConnection 或者 Media Capture。比如 WebRTC-ICE，目前就是独立的标准。有些标准不是 W3C WebRTC 小组定义的，比如 WebTransport，由 W3C WebTransport 小组定义；WebRTC-QUIC，由 ORTC 小组定义；WebCodecs，由 WICG 定义。


WebTransport 是一组 API，由 W3C WebTransport 组定义的；同时，WebTransport 也是一系列的协议，由 IETF 定义的。这些协议包括 WebTransport over QUIC，简称 QUIC Transport；也包括 WebTransport over HTTP/3，也可能 HTTP/2。因此，WebTransport 的 API 不仅仅支持 QUIC，也支持 HTTP/3，以及 HTTP/2（主要考虑 Fail-over 的回退）。 WebTransport 的 API 是一个 CS 模型的 API，构造和函数都很像 WebSocket。在 WebTransport 的构造函数中，你需要指定一个 URL。但是和 WebSocket 不同的是，WebTransport 支持可靠传输的流传输，也可以支持不可靠的数据报。

WebScoket 只是客户端发起的，不能由服务器发起；而 WebTransport 可以由服务器发起。另外WebTransport over QUIC 时连接是非 Pooled，而 WebTransport over HTTP/3 是 Pooled，这创造了一些新的应用场景，有些在 IETF BoFs 中由提到过。这意味着，在同一个 QUIC 连接中，你可以传输很多内容，比如 HTTP/3 请求和响应、WebTransport、Streams 和 Datagrams。Justin Uberti 提出过一个标准 IETF RIPT BOF，就是将这些不同的东西放在了一起。在这个场景下，有来回的 RPC 请求，也包括服务器主动发起的请求。比如一个客户端，发出请求说要播放一个电影，或者进入一个游戏，或者加入视频会议，然后服务器就开始主动发起多路不同的视频流的传输了。我认为 WebTransport 有可能会给 Web 带来革命性的变化，HTTP/3 本身就是对 Web 的一种革命。而这些关键变化，是 HTTP/3 Pooled Transport；相比之下，QUIC 就更简单了，它只是给了一个 Socket 一样的能力，可以发送和接收数据。

WebRTC 直播技术
本节感谢“阿武时代(26-04)”。

WebRTC 直播解决方案
WebRTC (Web Real-Time Communication) 是一套支持浏览器和移动应用进行实时音视频通信的开源项目，通过P2P 直连或SFU 转发实现 ** 超低延迟 (500ms 内)** 直播体验，超传统 RTMP (3-5 秒) 方案。以下从架构、核心组件、实现流程、优化策略、部署方案到典型应用进行简单解析。

1、WebRTC 直播核心架构对比
其主要有三种组网模式，各有适用场景：
架构 工作原理 带宽消耗 延迟 扩展性 适用场景
Mesh(P2P) 所有客户端两两直连，无中心服务器 上行: N-1 路，下行: N-1 路 最低 (直连) 差 (≤4 人) 小型私密直播、1v1 互动
SFU (选择性转发) 客户端→SFU→观众，SFU 仅转发不转码 上行: 1 路，下行: N-1 路 低 (+50-100ms) 好 (≤1000 人) 中小型直播、多人互动
MCU (混流) 客户端→MCU 混流→观众，MCU 转码合成 上行: 1 路，下行: 1 路 中 (+200-500ms) 中 (≤500 人) 大型直播、低性能设备观看

SFU 是当前 WebRTC 直播主流选择，平衡延迟、扩展性和成本，典型实现有 Mediasoup、LiveKit、SRS 等。

2、WebRTC 直播核心组件
1. 信令服务器 (Signaling Server)
核心功能：交换 SDP (媒体能力协商) 和 ICE Candidate (网络地址)，不传输媒体数据
常用实现：WebSocket (主流)、MQTT、HTTP REST
关键流程：客户端 A 创建 Offer (SDP) 发送给信令服务器 信令服务器转发 Offer 给客户端 B 客户端 B 生成 Answer (SDP) 返回 双方交换 ICE Candidate 建立连接

2. STUN/TURN 服务器 (NAT 穿透)
STUN：轻量级 (RFC 5389)，获取设备公网 IP + 端口，无法穿透对称 NAT (约 30% 网络)
TURN：中继传输，当 STUN 穿透失败时，所有媒体流量通过 TURN 服务器转发，必部署以保障连通性
ICE 框架：自动尝试 P2P 直连→STUN→TURN，保障连接可靠性

3. SFU 服务器 (媒体转发核心)
核心能力：接收发布者媒体流 (RTP 包) 选择性转发给订阅者，不做转码 (低 CPU 消耗) 支持 Simulcast (多分辨率流) 和 SVC (可伸缩编码) 提供房间管理、流订阅控制
性能指标：单节点支持 500-1000 路并发，1Gbps 带宽约承载 500 路 1080p@3Mbps 流

4. 媒体处理组件
编解码器：音频 (Opus)、视频 (VP8/VP9/H.264/AV1)，Opus 和 VP8 为 WebRTC 原生支持
加密机制：DTLS (传输层) 和 SRTP (媒体层)，保障端到端安全
拥塞控制：GCC (Google Congestion Control)，实时监测网络状态调整码率

3、WebRTC 直播实现完整流程
发布者(浏览器/OBS) → 信令交换 → STUN/TURN穿透 → SFU连接 → 媒体流发布
↓
观众(浏览器/APP) → 信令订阅 → STUN/TURN穿透 → SFU连接 → 媒体流接收

1. 发布端流程
// 1. 获取媒体流
const stream = await navigator.mediaDevices.getUserMedia({
video: { width: 1280, height: 720, frameRate: 30 },
audio: true
});

// 2. 初始化PeerConnection
const pc = new RTCPeerConnection({
iceServers: [{ urls: "stun:stun.l.google.com:19302" },
               { urls: "turn:your-turn-server.com", username: "user", credential: "pass" }]
});

// 3. 添加媒体轨道
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// 4. 创建Offer并设置本地描述
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// 5. 通过信令发送Offer给SFU/观众
sendSignaling("offer", offer);

// 6. 监听ICE Candidate并发送
pc.onicecandidate = e => {
if (e.candidate) sendSignaling("ice-candidate", e.candidate);
};

2. 观众端流程
// 1. 初始化PeerConnection(同上)
const pc = new RTCPeerConnection({ iceServers: [...] });

// 2. 监听远程轨道并播放
pc.ontrack = e => {
document.getElementById("remoteVideo").srcObject = e.streams[0];
};

// 3. 接收Offer并设置远程描述
receiveSignaling("offer", async offer => {
await pc.setRemoteDescription(new RTCSessionDescription(offer));

// 4. 生成Answer并发送
const answer = await pc.createAnswer();
await pc.setLocalDescription(answer);
  sendSignaling("answer", answer);
});

// 5. 接收ICE Candidate并添加
receiveSignaling("ice-candidate", candidate => {
  pc.addIceCandidate(new RTCIceCandidate(candidate));
});

3. SFU 转发流程 (Mediasoup 示例)
// 1. 发布者连接SFU并创建传输
const transport = await device.createSendTransport(...);

// 2. 发送媒体轨道
transport.produce({ track: videoTrack, ... });

// 3. 观众连接SFU并创建接收传输
const transport = await device.createRecvTransport(...);

// 4. 订阅媒体轨道
const consumer = await transport.consume({ producerId: "...", ... });
document.getElementById("remoteVideo").srcObject = consumer.track;

4、WebRTC 直播关键优化策略
1. 低延迟优化
禁用 B 帧：使用 I/P 帧，减少编码延迟 (+100-300ms)
降低 GOP 长度：设为 1-2 秒 (关键帧间隔)，减少关键帧丢失影响
调整缓冲区：客户端播放缓冲区≤200ms，SFU 转发延迟≤50ms
QUIC 协议：替代 TCP 用于信令，减少握手延迟

2. 抗弱网优化 (核心优势)
技术 原理 适用场景
FEC 前向纠错 发送冗余包，丢包率 < 10% 时可恢复，无延迟 随机丢包
NACK 重传 接收端请求重传丢失数据包，延迟 + 50-100ms 关键帧丢失
带宽自适应 (ABR) GCC 算法动态调整码率，丢包 > 5% 时降低码率 带宽波动
Simulcast/SVC 多分辨率流，网络差时自动切换低分辨率 网络不稳定

3. 性能优化
硬件加速：使用 WebAssembly 或 GPU 加速编解码
分层编码：对多人直播，优先保障主讲人画质
动态帧率：网络差时降低帧率 (30fps→15fps) 而非码率，保持流畅度
音频优先：网络拥塞时先保障音频质量，视频可适当降质

5、企业级 WebRTC 直播部署方案
1. 单节点基础架构
[客户端] ←WebRTC→ [信令服务器]
                ↓
[STUN/TURN] ←→ [SFU服务器] ←→ [媒体存储/录制]
                ↓
[CDN] ←→ [转码服务] (可选，适配传统直播协议)

2. 集群扩展方案 (RTC Pilot 示例)
Pilot Center：管理房间和用户信息，同步 SFU 集群状态
SFU 集群：多节点负载均衡，支持跨节点流转发
WHIP 协议：WebRTC 推流标准化协议，支持 OBS 等专业推流工具接入
跨区域部署：全球边缘节点，降低跨地域延迟

3. 容器化部署 (推荐)
Docker+K8s：快速部署和扩容 SFU、信令、STUN/TURN 服务
自动扩缩容：根据并发量自动调整资源，优化成本
监控告警：Prometheus+Grafana 监控延迟、丢包率、带宽等关键指标

6、WebRTC 直播与传统直播协议对比
特性 WebRTC RTMP HLS/DASH
延迟 50-500ms 3-5 秒 10-30 秒
互动性 高 (支持双向通信) 低 (单向) 极低
抗弱网 强 (丢包率≤20% 可正常播放) 中 (丢包> 5% 卡顿) 弱
浏览器支持 原生支持 (Chrome/Firefox/Safari) 需要 Flash 插件 (已淘汰) 原生支持
带宽效率 高 (自适应码率) 中 高 (但延迟大)

7、典型应用场景
互动直播：带货直播、游戏直播、在线教育 (师生互动)
视频会议：多人协作、远程办公、在线研讨会
实时互动娱乐：直播答题、互动游戏、虚拟活动
远程医疗：视频问诊、手术直播 (超低延迟关键)
IoT 实时监控：安防监控、工业设备实时视频传输

8、WebRTC 直播落地最佳实践
必选组件：信令服务器 + STUN+TURN+SFU，TURN 服务器建议使用商业服务 (如 Twilio、阿里云)
网络要求：发布端上行≥2Mbps，观众端下行≥1Mbps，延迟≤100ms
安全措施：启用 DTLS/SRTP 加密，信令传输使用 WSS/HTTPS，限制房间访问权限
兼容性：适配不同浏览器和设备，提供降级方案 (如 HLS 备用流)
监控运维：实时监测延迟、丢包率、连接成功率，设置告警阈值

小结
WebRTC 直播凭借超低延迟和强互动性，成为实时互动场景的首选方案。核心在于选择合适的SFU 架构，搭配完善的信令、NAT 穿透和优化策略，并根据规模选择单节点或集群部署。随着 5G 和边缘计算发展，WebRTC 将在更多直播场景中替代传统方案，带来更沉浸的实时互动体验。


项目主页：https://sites.google.com/site/webrtc/

参考来源：http://zh.wikipedia.org/wiki/WebRTC