webrtc整体架构

WebRTC（Web Real-Time Communication）是一套支持浏览器和移动应用进行实时音视频通信的开源技术标准，其架构设计围绕 “实时性”“低延迟”“跨平台” 和 “安全性” 展开，整体可分为核心引擎层、API 层、支撑服务层三大部分，各部分协同实现端到端的实时媒体传输。是谷歌 2010 年以 6820 万美元收购 Global IP Solutions 公司而获得的一项技术。
WebRTC 提供了实时音视频的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。

架构简介：

• 第一层 C++ API：提供给外面的接口，最主要的是（PeerConnedtion 对等连接）
• 第二层 Session：上下文管理层（音视频）
• 第三层【最重要的部分】
  • 音视频引擎 ：编解码；音频缓冲 BUFFER 防止音频网络抖动 NetEQ；回音消除；降噪；静音检测；
  • 视频引擎 ：编解码；jitter buffer 防止视频网络抖动；图像处理增强；
  • 传输：SRTP 加密后的 RTP；多路复用；P2P（STUN+TURN+ICE)
• 第四层，硬件相关层：音视频采集；网络 IO

整体架构
WebRTC是RTC的一部分：

一、核心引擎层（WebRTC Core）

核心引擎是 WebRTC 的底层实现，包含音视频处理、网络传输、编解码等核心功能，主要用 C++ 编写（确保跨平台和高性能），是实时通信的 “引擎心脏”。

1.1、 媒体引擎（Media Engine）

负责音视频的采集、处理、编解码和渲染，分为音频引擎和视频引擎。

• 音频引擎（Audio Engine）
  处理所有音频相关的流程，核心功能包括：

  • 采集：通过系统 API（如 iOS 的 AVFoundation、Android 的 AudioRecord）捕获麦克风音频。
  • 预处理：关键技术包括：
  • 回声消除（AEC，Acoustic Echo Cancellation）：消除扬声器播放的声音被麦克风重新采集导致的回声。
  • 噪声抑制（NS，Noise Suppression）：过滤背景噪声（如键盘声、环境杂音）。
  • 自动增益控制（AGC，Automatic Gain Control）：平衡不同距离下的音量（避免离麦克风近时声音过大）。
  • 静音检测（VAD，Voice Activity Detection）：检测是否有有效语音，节省带宽。
  • 编解码：支持 OPUS（默认，低延迟、高音质，适合实时通信）、G.711、G.722 等编码格式，其中 OPUS 在窄带（8kHz）到宽带（48kHz）下均有优异表现。
  • 混音：多人通话时将多路音频混合为一路（客户端或服务器端实现）。

• 视频引擎（Video Engine）
  处理视频的采集、处理、编解码和渲染，核心功能包括：

  • 采集：通过系统 API（如 iOS 的 AVCaptureSession、Android 的 Camera2）捕获摄像头画面或屏幕内容（屏幕共享）。
  • 预处理：
    • 自动曝光、自动对焦（基于硬件能力）。
    • 美颜、滤镜（可选，通常由上层应用实现）。
    • 分辨率 / 帧率调整（根据网络状况动态适配）。
  • 编解码：支持 VP8（开源，默认）、VP9（更高压缩率，适合 4K）、H.264（与传统设备兼容性好）、H.265（HEVC，高分辨率下带宽更优）等，编码决策会根据网络带宽动态调整（如丢包时降低码率）。
  • 传输优化：
    • 抖动缓冲（Jitter Buffer）：接收端缓存一定量视频帧，解决网络抖动导致的播放卡顿。
    • 丢包补偿（FEC，Forward Error Correction）：发送冗余数据，接收端可恢复部分丢失的帧。
    • 重传机制（NACK，Negative Acknowledgment）：对关键帧请求重传（非关键帧可能直接丢弃以保证实时性）。

• 渲染：将解码后的视频帧通过系统 API（如 iOS 的 Metal、Android 的 OpenGL ES）渲染到屏幕。

1.2、传输引擎（Transport Engine）

负责媒体数据（音视频）和非媒体数据（如文本、文件）的实时传输，核心是P2P 连接建立和可靠 / 实时传输协议。

• 连接建立：ICE/STUN/TURN
  WebRTC 的 P2P 连接依赖 ICE（Interactive Connectivity Establishment，交互式连接建立）框架，解决 NAT（网络地址转换）和防火墙导致的端到端连接难题：
  • STUN（Session Traversal Utilities for NAT）：客户端向 STUN 服务器发送请求，获取自己在公网中的 IP 和端口（NAT 映射地址），用于生成 “ICE 候选者”（Candidate）。
  • TURN（Traversal Using Relays around NAT）：当 P2P 连接失败（如对称 NAT 环境）时，作为中继服务器转发数据（牺牲部分实时性，保证连接可用性）。
  • ICE 候选者交换：双方通过信令服务器交换各自的 ICE 候选者，ICE 框架会测试所有候选者（优先直连，其次中继），选择最优连接路径。
• 媒体传输：RTP/RTCP
  音视频数据通过 RTP（Real-time Transport Protocol，实时传输协议）传输，特点是轻量、低延迟，不保证可靠性（优先实时性）：
  • RTP：封装媒体数据（如视频帧、音频帧），包含时间戳（同步音视频）、序列号（检测丢包）等信息。
  • RTCP（RTP Control Protocol）：与 RTP 配合，传输控制信息（如丢包率、带宽估算），用于发送端动态调整码率（如网络变差时降低发送速率）。
• 数据通道：SCTP over DTLS
  除了音视频，WebRTC 还支持通过RTCDataChannel传输非媒体数据（如文本消息、文件），底层依赖：
  • SCTP（Stream Control Transmission Protocol）：提供可靠传输（保证数据有序、不丢失）和部分可靠传输（按需配置），适合不同类型数据（如游戏控制指令需可靠，实时消息可容忍丢失）。
  • DTLS（Datagram Transport Layer Security）：对 SCTP 和 RTP 数据进行加密（基于 TLS 1.3），确保传输安全性。

1.3、 会话管理（Session Management）

负责两端媒体能力协商和会话描述，核心是SDP 协议：
SDP（Session Description Protocol）：一种文本格式，用于描述本地媒体能力（如支持的编解码器、分辨率、IP / 端口等）。
协商流程：双方通过信令服务器交换 SDP（本地发送 “offer”，对方回复 “answer”），最终确定共同支持的媒体参数（如编解码器、传输端口），建立媒体会话。

二、API 层（WebRTC APIs）

为了方便开发者集成，WebRTC 提供了跨平台的 API，屏蔽底层复杂逻辑。

2.1、浏览器 API（JavaScript）

WebRTC 标准化的浏览器 API，主要包括：
getUserMedia()：访问用户摄像头和麦克风，获取本地媒体流（MediaStream）。
RTCPeerConnection：核心 API，负责创建 P2P 连接、处理 ICE 候选者交换、SDP 协商、媒体流传输。
RTCDataChannel：创建数据通道，传输非媒体数据。

2.2、原生 API（移动应用）

针对 iOS 和 Android 平台，提供原生语言接口：
iOS：通过GoogleWebRTC库提供 Objective-C/Swift 接口（如RTCPeerConnection、RTCMediaStream），与系统音视频框架（AVFoundation）集成。
Android：提供 Java 接口（如PeerConnection、MediaStream），与 Camera、AudioManager 等系统服务交互。

三、支撑服务层（Supporting Services）

WebRTC 本身不包含这些服务，但实际应用中必须依赖它们才能完成通信。

3.1、信令服务器（Signaling Server）

作用：WebRTC 的 P2P 连接需要交换 “信令信息”（SDP、ICE 候选者），但 WebRTC 未定义信令协议，因此需要信令服务器作为中介转发这些信息。
特点：不参与媒体数据传输，仅负责 “牵线搭桥”，可基于 WebSocket、HTTP 等协议实现（如使用 Node.js、Java 搭建）。

3.2、STUN/TURN 服务器

STUN 服务器：帮助客户端获取公网 IP 和端口（解决 NAT 映射问题），常用开源实现有coturn、libjingle。
TURN 服务器：在 P2P 连接失败时作为中继，转发媒体数据，确保通信不中断（需注意带宽成本）。

3.3、媒体服务器（可选，多人场景）

一对一通信可直接 P2P，但多人场景（如视频会议）通常需要媒体服务器中转，实现：

• 媒体混合（将多路视频合成为一个画面）。
• 选择性转发（只向用户发送其需要的视频流）。
• 录制、转码（适配不同设备能力）。
• 常用开源媒体服务器：Mediasoup、Kurento、Janus。

四、安全层（Security）

WebRTC 强制要求加密传输，核心安全机制包括：
DTLS：对所有媒体数据（RTP）和数据通道（SCTP）进行加密，防止窃听。
证书验证：SDP 交换时包含证书指纹，确保通信双方身份合法。
权限控制：访问摄像头 / 麦克风需用户授权（浏览器或系统层面）。

五、WebRTC 源码功能模块

WebRTC 实现了基于网页的视频会议，标准是 WHATWG 协议，目的是通过浏览器提供简单的 javascript 就可以达到实时通讯（Real-Time Communications (RTC)）能力。

5.1、视频相关

① 视频采集—video_capture
源代码在 webrtc\modules\video_capture\main 目录下， 包含接口和各个平台的源代码。
在 windows 平台上，WebRTC 采用的是 dshow 技术，来实现枚举视频的设备信息和视频数据的采集，这意味着可以支持大多数的视频采集设备；对那些需要单独驱动程序的视频采集卡（比如海康高清卡）就无能为力了。
视频采集支持多种媒体类型，比如 I420、YUY2、RGB、UYUY 等，并可以进行帧大小和帧率控制。

② 视频编解码—video_coding
源代码在 webrtc\modules\video_coding 目录下。
WebRTC 采用 I420/VP8 编解码技术。VP8 是 google 收购 ON2 后的开源实现，并且也用在 WebM 项目中。VP8 能以更少的数据提供更高质量的视频，特别适合视频会议这样的需求。

③ 视频加密—video_engine_encryption
视频加密是 WebRTC 的 video_engine 一部分，相当于视频应用层面的功能，给点对点的视频双方提供了数据上的安全保证，可以防止在 Web 上视频数据的泄漏。
视频加密在发送端和接收端进行加解密视频数据，密钥由视频双方协商，代价是会影响视频数据处理的性能；也可以不使用视频加密功能，这样在性能上会好些。

④ 视频媒体文件—media_file
源代码在 webrtc\modules\media_file 目录下。
该功能是可以用本地文件作为视频源，有点类似虚拟摄像头的功能；支持的格式有 Avi，另外 WebRTC 还可以录制音视频到本地文件，比较实用的功能。

⑤ 视频图像处理—video_processing
源代码在 webrtc\modules\video_processing 目录下。
视频图像处理针对每一帧的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。

⑥ 视频显示—video_render
源代码在 webrtc\modules\video_render 目录下。
在 windows 平台，WebRTC 采用 direct3d9 和 directdraw 的方式来显示视频，只能这样，必须这样。

⑦ 网络传输与流控
对于网络视频来讲，数据的传输与控制是核心价值。WebRTC 采用的是成熟的 RTP/RTCP 技术。

5.2、音频相关

WebRTC 的音频部分，包含设备、编解码（iLIBC/iSAC/G722/PCM16/RED/AVT、 NetEQ）、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控（RTP/RTCP）等功能。
① 音频设备—audio_device
源代码在 webrtc\modules\audio_device\main 目录下， 包含接口和各个平台的源代码。
在 windows 平台上，WebRTC 采用的是 Windows Core Audio 和 Windows Wave 技术来管理音频设备，还提供了一个混音管理器。
利用音频设备，可以实现声音输出，音量控制等功能。

② 音频编解码—audio_coding
源代码在 webrtc\modules\audio_coding 目录下。
WebRTC 采用 iLIBC/iSAC/G722/PCM16/RED/AVT 编解码技术。
WebRTC 还提供 NetEQ 功能—抖动缓冲器及丢包补偿模块，能够提高音质，并把延迟减至最小。
另外一个核心功能是基于语音会议的混音处理。

③ 声音加密—voice_engine_encryption
和视频一样， WebRTC 也提供声音加密功能。

④ 声音文件
该功能是可以用本地文件作为音频源，支持的格式有 Pcm 和 Wav。
同样，WebRTC 也可以录制音频到本地文件。

⑤ 声音处理—audio_processing
源代码在 webrtc\modules\audio_processing 目录下。
声音处理针对音频数据进行处理，包括回声消除（AEC）、AECM（AEC Mobile）、自动增益（AGC）、降噪（NS）、静音检测（VAD）处理等功能， 用来提升声音质量。

⑥ 网络传输与流控
和视频一样，WebRTC 采用的是成熟的 RTP/RTCP 技术。

总结：WebRTC 架构协同流程

媒体采集：客户端通过 API（如 getUserMedia）采集本地音视频，经媒体引擎预处理。
信令交换：双方通过信令服务器交换 SDP（媒体能力）和 ICE 候选者（网络地址）。
P2P 连接：ICE 框架基于候选者建立最优连接（优先直连，失败则用 TURN 中继）。
媒体传输：音视频通过 RTP 实时传输，RTCP 动态调整质量；数据通过 RTCDataChannel 传输。
渲染播放：接收端解码后渲染音视频，完成实时通信。
这套架构既保证了实时性（低延迟），又通过 P2P 降低了服务器压力，同时兼顾跨平台和安全性，是实时音视频通信的主流技术方案。