【音视频】WebRTC 介绍

一、WebRTC 简述

WebRTC（Web Real-Time Communication，网页实时通信）是一套开源技术标准和 API，旨在让浏览器、移动应用等终端之间无需依赖插件或第三方软件，即可实现实时音视频通话、数据传输等互动功能。它由 Google 于 2011 年发起，目前由 W3C（负责 API 标准化）和 IETF（负责底层协议标准化）共同维护，已成为实时 Web 通信的核心技术之一

WebRTC跨平台，浏览器网页支持， Android、IOS用原生WebRTC C++

二、WebRTC框架

2.1 架构分层与角色定位

WebRTC架构采用分层解耦设计，不同层级服务于不同角色（Web开发者、浏览器厂商），核心是通过抽象降低复杂度：

2.2 各层级详细解析

1. Your Web App（应用层）

• 角色：Web开发者开发的产品（如视频会议网页、在线教育平台）。
• 工作方式：通过浏览器提供的 Web API 调用WebRTC功能，无需关心底层实现。
• 核心价值：WebRTC让“实时通信”像调用普通JS API一样简单，开发者聚焦业务逻辑（如界面、信令交互）。

2. Web API（紫色层，W3C标准化接口）

• 定位：面向Web开发者的JavaScript API，是WebRTC的“入口”。
• 关键接口：
  • getUserMedia：捕获摄像头/麦克风的音视频流（MediaStream）。
  • RTCPeerConnection：管理端到端连接（协商媒体能力、网络穿透、数据传输），是WebRTC的核心抽象。
  • RTCDataChannel：基于连接传输自定义数据（如文本、文件）。
• 意义：标准化后，开发者无需适配不同浏览器的私有接口，一套代码即可实现跨浏览器实时通信。

3. WebRTC Native C++ API（蓝色实线，浏览器厂商层）

• 定位：浏览器厂商需实现的C++接口，用于对接上层Web API和底层引擎。
• 核心组件：PeerConnection（C++类），封装了媒体处理、网络协商、传输控制的复杂逻辑。
• 角色分工：
  • Web开发者：只需调用JS版RTCPeerConnection，无需关心C++实现。
  • 浏览器厂商：通过实现C++ API，将WebRTC能力集成到浏览器中（如Chrome、Firefox的WebRTC模块）。

4. 引擎与传输层（核心功能模块）

这一层是WebRTC的技术核心，包含音频处理、视频处理、网络传输三大核心引擎：

（1）Transport / Session（传输/会话层）

• 会话管理：
  • 负责交换 SDP（会话描述协议）：协商双方的媒体能力（如支持的编解码器、分辨率、音视频格式）。
  • 不依赖特定协议（如XMPP/Jingle），浏览器厂商可灵活实现信令交互逻辑。
• 传输核心：
  • SRTP：加密媒体流，保障通信安全（WebRTC默认强制加密）。
  • Multiplexing（多路复用）：复用网络连接，减少资源消耗。
  • P2P + STUN/TURN/ICE：
    • STUN：获取设备的公网IP/端口（解决NAT穿透第一步）。
    • TURN：当P2P失败时，作为中继服务器转发数据（“保底方案”，增加延迟）。
    • ICE：统一管理STUN/TURN候选地址，智能选择最佳连接路径（优先P2P，失败则用TURN）。

（2）VoiceEngine（音频引擎）

• 技术背景：源于Google收购的GIPS公司，是WebRTC在VoIP领域领先的核心技术。
• 核心组件：
  • 编解码器：
    • iSAC：自适应码率（6kbps~510kbps），支持宽频语音（适合网络波动场景）。
    • iLBC：低码率（窄带），适合弱网环境下的语音传输。 （注：现代WebRTC主流使用Opus编解码器，支持更灵活的码率和采样率，兼容更多场景。）
  • NetEQ模块：
    • 动态抖动缓冲 + 错误隐藏：处理网络抖动（数据包到达时间不稳定）和丢包，平衡延迟与语音质量（延迟过高会导致对话卡顿，过低会丢失细节）。
    • 是实现“流畅语音通话”的关键技术。
  • 回声消除（Echo Canceler）+ 噪声抑制（Noise Reduction）：
    • 消除环境噪音（如键盘声、背景音）和回声（如扬声器声音被麦克风拾音），提升通话体验。

（3）VideoEngine（视频引擎）

• 定位：覆盖视频采集→处理→传输→渲染的全流程解决方案。
• 核心组件：
  • 编解码器：VP8（默认），专为低延迟实时通信设计（相比H.264，编码延迟更低，适合视频通话）。 （现代扩展支持VP9、AV1，但VP8仍为实时场景首选。）
  • 视频抖动缓冲（Video Jitter Buffer）：
    • 类似音频NetEQ，处理网络波动导致的视频帧到达时间不稳定，避免播放卡顿。
  • 图像增强（Image Enhancements）：
    • 包含降噪、美颜、低光增强等算法，提升视频画面质量。

5. 硬件交互层（蓝色虚线，浏览器厂商自定义）

• 组件：Audio Capture/Render（音频采集/渲染）、Video Capture（视频采集）、Network I/O（网络输入输出）。
• 角色：浏览器厂商需适配不同操作系统的硬件接口：
  • 音频：Windows（WASAPI）、Linux（ALSA）、Mac（Core Audio）。
  • 视频：Windows（DirectShow）、Mac（AVFoundation）、Linux（V4L2）。
  • 网络：优化不同系统的网络栈（如Windows的WinSock、Linux的Socket），提升传输效率。

三、WebRTC通话原理

3.1 媒体协商

两个设备（Peer）要互通音视频，必须统一 编解码格式、媒体类型（音频 / 视频）、分辨率 等参数。例如：

• PeerA 支持 VP8、H.264 编码，PeerB 支持 VP9、H.264，需协商出共同支持的 H.264，否则无法解码对方的流。

解决方案：SDP 协议

• SDP（Session Description Protocol） 是一种文本格式，用于描述 “媒体会话的能力和参数”，包含：

  • 会话元数据：会话名称、时间、所有者等。
  • 媒体轨道信息：每个音视频轨道的编码格式（如 H.264）、端口、采样率等。
  • 网络信息：后续会整合 ICE Candidate（网络协商结果），但核心还是媒体能力。

• WebRTC 中的 SDP 交换流程（Offer-Answer 模型）：

• 发起方（Offer）：调用 RTCPeerConnection.createOffer() 生成 SDP（包含自己支持的媒体格式），通过 setLocalDescription 保存。
• 接收方（Answer）：收到 Offer 后，调用 createAnswer() 生成自己的 SDP（筛选双方交集），通过 setLocalDescription 保存。
• 双向交换：双方通过信令服务器转发 SDP，完成 “媒体能力对齐”

3.2 网络协商

设备多处于 NAT（局域网）后，没有公网 IP，直接通信会被防火墙拦截。需解决：

• 如何让双方发现彼此的可达网络地址？
• 如何在复杂网络（多层 NAT、防火墙）中找到最佳通信路径（优先 P2P，避免中继延迟）？

解决方案：ICE 框架 + Candidate 交换

STUN

• STUN（Session Traversal Utilities for NAT，NAT会话穿越应用程序）是一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。该协议由RFC 5389定义。

• 使用一句话说明STUN做的事情就是：告诉我你的公网IP地址+端口是什么。搭建STUN服务器很简单，媒体流传输是按照P2P的方式。

• 那么问题来了，STUN并不是每次都能成功的为需要NAT的通话设备分配IP地址的，P2P在传输媒体流时，使用的本地带宽，在多人视频通话的过程中，通话质量的好坏往往需要根据使用者本地的带宽确定。那么怎么办？TURN可以很好的解决这个问题。

TURN

• TURN的全称为Traversal Using Relays around NAT，是STUN/RFC5389的一个拓展，主要添加了Relay功能。如果终端在NAT之后， 那么在特定的情景下，有可能使得终端无法和其对等端（peer）进行直接的通信，这时就需要公网的服务器作为一个中继， 对来往的数据进行转发。这个转发的协议就被定义为TURN。

在上图的基础上，再架设几台TURN服务器：

• 在STUN分配公网IP失败后，可以通过TURN服务器请求公网IP地址作为中继地址。这种方式的带宽由服务器端承担，在多人视频聊天的时候，本地带宽压力较小，并且，根据Google的说明，TURN协议可以使用在所有的环境中。（单向数据200kbps 一对一通话）

总结

• 以上是WebRTC中经常用到的2个协议，STUN和TURN服务器我们使用coturn开源项目来搭建。
• ICE跟STUN和TURN不一样，ICE不是一种协议，而是一个框架（Framework），它整合了STUN和TURN。
• coturn开源项目集成了STUN和TURN的功能。
• 在WebRTC中用来描述 网络信息的术语叫candidate：媒体协商 sdp 网络协商 candidate

3.3 媒体协商+网络协商数据的交换通道

• 从上面1/2点我们知道了2个客户端协商媒体信息和网络信息，那怎么去交换？是不是需要一个中间商去做交换？所以我们需要一个信令服务器（Signal server）转发彼此的媒体信息和网络信息。

• 如上图，我们在基于WebRTC API开发应用（APP）时，可以将彼此的APP连接到信令服务器（Signal Server，一般搭建在公网，或者两端都可以访问到的局域网），借助信令服务器，就可以实现上面提到的SDP媒体信息及Candidate网络信息交换。

信令服务器不只是交互 媒体信息sdp和网络信息candidate，比如：

四、WebRTC通话模型

4.1 P2P一对一通话网络模型

• 如图是 WebRTC P2P 模式下的网络拓扑结构，ClientA 和 ClientB 如果能够顺利建立 P2P 的连接，则可直接通过 P2P 互相交换数据。
• 如果由于某些网络环境原因，无法成功打通 P2P 连接的话，则可以通过一台 TURN Server 来中转数据给对方。

• 在一对一通话场景中，每个 Peer均创建有一个 PeerConnection 对象，由一方主动发 Offer SDP，另一方则应答AnswerSDP，最后双方交换 ICE Candidate 从而完成通话链路的建立。

• 但是在中国的网络环境中，据一些统计数据显示，至少1半的网络是无法直接穿透打通，这种情况下只能借助TURN服务器中转。

4.2 P2P多方通话网络模型

• 如图所示，多人通话跟单人通话唯一的不同就是每个客户端都需要跟其他两个端都分别建立P2P 连接。

• 与一对一通话一样，如果两个端能够顺利建立P2P 的连接，则直接通过 P2P 互相交换数据；如果无法打通，则利用 Turn Server 来中转数据。

• 我们把这种完全使用P2P 方式的网络拓扑结称之为 Mesh 结构

WebRTC Mesh 网络拓扑结构的优劣

优点：

缺点：

4.3 SFU通话网络模型

• SFU 的全称是：Selective Forwarding Unit，是一种通过服务器来路由和转发 WebRTC 客户端音视频数据流的方法。

• SFU 服务器最核心的特点是把自己 “伪装” 成了一个WebRTC 的 Peer 客户端，WebRTC 的其他客户端其实并不知道自己通过 P2P 连接过去的是一台真实的客户端还是一台服务器，我们通常把这种连接称之为 P2S，即：Peer to Server。

SFU服务器和TURN服务器最大的不同：

• TURN 服务器仅仅是为 WebRTC 客户端提供的一种辅助的数据转发通道，在P2P不通的时候进行透明的数据转发。
• 而 SFU 是 “懂业务” 的， 它跟 WebRTC 客户端是平等的关系，甚至 “接管了” WebRTC 客户端的数据转发的申请和控制。

4.4 MCU通话网络模型

• MCU 的全称是：Multipoint Control Unit，又被称为混合,实现多方WebRTC交流的另一种策略。

• 它的特点是，由 MCU Server 将各路客户端上行的视频流合成为一路，再转发给其他客户端。

• 这种模型相比于 SFU 降低了多人视频通话场景下客户端的下行带宽压力，但是由于合流需要转码操作，对服务器端压力比较大，而且下发给客户端的流是固定的合流画面，灵活性不是特别好。

4.5 WebRTC 通话网络模型选择

• 纯 mesh 方案无法适应多人视频通话，也无法实现服务端的各种视频处理需求，一般只适用于三方以下通话的需求。

• SFU 相比于 MCU，服务器的压力更小（纯转发，无转码合流），灵活性更好（可选择性开关任意一路数据的上下行等），受到更广泛的欢迎和应用，常见的开源 SFU 服务器有：Licode，Janus，Jitsi，mediasoup，Medooze 等等，各有特点，可以去项目主页了解更详细的情况。

• 也可以组合使用 SFU + MCU 的混合方案，以灵活应对不同场景的应用需要。

五、WebRTC 应用场景

更多资料：https://github.com/0voice