WebRTC 的架构分层

+------------------------------------------------------+
|             Application (Web or Native)              |
+------------------------------------------------------+
|            WebRTC API (JavaScript or Native C++)     |  <--  API 层 (供开发者调用)
+------------------------------------------------------+
|                Session & Signaling Layer             |
|  (Session Description Protocol - SDP)                |  <--  会话层 (WebRTC 未定义，需自行实现)
+------------------------------------------------------+
|                                                      |
|                 WebRTC C++ Core Engine               |  <--  核心引擎
|                                                      |
| +------------------+     +-------------------------+ |
| |   Voice Engine   |     |      Video Engine       | |
| +------------------+     +-------------------------+ |
| | - iSAC/iLBC/Opus |     | - VP8/VP9/AV1/H.264     | |
| | - NetEQ (Jitter) |     | - Jitter Buffer         | |
| | - AEC, NR, AGC   |     | - Image Enhancement     | |
| | - PLC            |     | - NACK/FEC/PLC          | |
| +------------------+     +-------------------------+ |
|                                                      |
| +--------------------------------------------------+ |
| |                 Transport Layer                  | |
| +--------------------------------------------------+ |
| | - SRTP/SRTCP (Media)                             | |
| | - ICE (STUN/TURN) (NAT Traversal)                | |
| | - DTLS (Key Exchange)                            | |
| | - SCTP (Data Channel)                            | |
| | - Congestion Control (GCC)                       | |
| +--------------------------------------------------+ |
|                                                      |
+------------------------------------------------------+
|          Hardware Abstraction & OS Layer             |
|   (Audio/Video Capture & Rendering)                  |  <--  硬件抽象层
+------------------------------------------------------+

API 层

这是开发者最直接接触的一层。

  • JavaScript API: 对于 Web 开发者，W3C 标准化了一套 JavaScript API，主要包括：
    • RTCPeerConnection: 核心对象，用于建立和管理一个端到端的连接。
    • MediaStream: 代表一个媒体流，可以包含多个轨道（MediaStreamTrack），如音频轨道和视频轨道。
    • getUserMedia(): 用于从浏览器获取本地的摄像头和麦克风数据，并封装成 MediaStream。
    • RTCDataChannel: 用于在端之间传输任意的二进制数据。
  • Native C++ API: 对于移动端（iOS/Android）或桌面应用开发者，WebRTC 提供了一套完整的 C++ API，其逻辑和 JavaScript API 类似，允许你将整个 WebRTC 引擎集成到原生应用中。

核心功能：这一层的主要职责是抽象和简化底层复杂的连接建立、媒体协商和数据传输过程，让开发者可以专注于应用逻辑。

会话层

WebRTC 本身不包含信令协议！

WebRTC 负责端到端（Peer-to-Peer）的数据传输，但它不知道如何找到对方（Peer）。因此，你需要一个信令服务器 (Signaling Server) 来帮助通信双方交换建立连接所需的三种元数据：

  1. 会话控制消息: 如 call、hangup 等，用来管理通话的生命周期。

  2. SDP: 会话描述协议。它是一个纯文本格式，用来描述媒体的属性和能力，例如：

    • 使用什么音视频编解码器 (Codecs)？
    • 视频分辨率是多少？帧率是多少？
    • 网络 IP 和端口是什么？（虽然现在这部分被 ICE Candidate 替代）
    • …

    WebRTC 使用一种叫做 Offer/Answer 的模型来交换 SDP。A 端创建一个 Offer (提议)，通过信令服务器发给 B 端；B 端收到后创建一个 Answer (应答)，再通过信令服务器发回给 A。协商完成后，双方就知道了如何收发媒体。

  3. ICE Candidates: 这是用于 NAT 穿透的网络候选地址。详见传输层。

信令的实现方式非常灵活，你可以使用任何你喜欢的技术，如 WebSocket、XMPP、MQTT 或者自定义的 HTTP 轮询。

WebRTC C++ 核心引擎

主要分为三大块：音频引擎、视频引擎和传输层。

音频引擎

Voice Engine 负责处理所有与音频相关的任务，从采集到编码，再到网络优化和播放，它的目标是在不稳定的网络下提供清晰、流畅的音频体验。

  • 编解码器 (Codecs):
    • Opus: WebRTC 的首选音频编解码器。它是一个功能极其强大的、开源免费的编解码器，可以动态调整码率（6 kbps 到 510 kbps），支持从窄带语音到高保真立体声音乐的各种场景，适应性极强。
    • iSAC/iLBC: Google 早期的自研语音编解码器，用于窄带和宽带语音，鲁棒性好，但现在基本被 Opus 取代。
    • G.711/G.722: 传统的电话网络编解码器，用于兼容传统 VoIP 系统。
  • NetEQ: 这是 WebRTC 音频引擎的精华所在。它是一个高度自适应的动态抖动缓冲器 (Jitter Buffer) 和丢包隐藏 (Packet Loss Concealment, PLC) 模块。
    • 功能: 解决网络包乱序、延迟抖动和丢包问题。它会根据网络状况动态调整缓冲区大小，对收到的 RTP 包进行重排序，并用先进的信号处理技术（如预测、插值）来生成丢失的音频数据，使得最终播放出来的声音平滑流畅。这是 WebRTC 音频质量远超简单 RTP 播放器的核心原因。
  • 音频处理单元:
    • 回声消除 (Acoustic Echo Canceler, AEC): 消除扬声器播放的声音被麦克风重新采集后传回给对方的问题。
    • 自动增益控制 (Automatic Gain Control, AGC): 自动调整麦克风音量，使得对方听到的声音大小适中。
    • 降噪 (Noise Reduction, NR): 抑制背景环境中的稳态噪声（如风扇声、空调声）。

视频引擎

Video Engine 负责处理所有视频相关的任务，核心目标是在有限的带宽和不稳定的网络下，提供尽可能清晰和实时的视频画面。

  • 编解码器 (Codecs):
    • VP8/VP9/AV1: Google 主导的开源、免版税的视频编解码器。VP9 和 AV1 的压缩效率非常高。
    • H.264/H.265: 业界最主流的视频编解码器，由 ITU-T 和 ISO/IEC 定义。H.264 的优势在于硬件编解码支持非常普遍（几乎所有手机、PC 都有硬编/硬解），能极大地降低 CPU 消耗和功耗。因此，在实际应用中 H.264 仍然是兼容性和性能的首选。
  • 视频抖动缓冲器 (Video Jitter Buffer): 类似于 NetEQ，但为视频设计。它负责接收 RTP 视频包，处理乱序和抖动，并将完整的视频帧（Frame）交给解码器。
  • 网络鲁棒性工具: 视频数据量远大于音频，丢包对画质影响极大，因此需要多种策略来对抗网络丢包。
    • NACK (Negative Acknowledgement): 接收方发现 RTP 包丢失后，立即通过 RTCP 消息通知发送方，请求重传丢失的包。适用于延迟较低的网络。
    • FEC (Forward Error Correction): 发送方在发送媒体数据的同时，额外发送一些冗余的纠错码（如 Reed-Solomon 或 XOR）。接收方即使丢失了部分数据包，也可以利用纠错码恢复出原始数据，无需等待重传，延迟更低，但会消耗额外带宽。
    • PLC (Packet Loss Concealment): 当一个包无法通过重传或 FEC 恢复时，解码器会尝试“隐藏”这个错误，比如重复播放前一帧，或者利用运动矢量预测丢失的宏块，避免出现花屏或卡顿。
  • 图像增强 (Image Enhancement): 对从摄像头采集的原始图像进行处理，如视频降噪，以提升编码前的图像质量。

传输层

这一层是 WebRTC 的网络基石，负责数据的安全、可靠传输和 NAT 穿透。

  • ICE (Interactive Connectivity Establishment): NAT 穿透的集大成者。
    • STUN (Session Traversal Utilities for NAT): 客户端通过向公网上的 STUN 服务器发送请求，来发现自己的公网 IP 地址和端口（即 Server-Reflexive Candidate），并判断自己所处的 NAT 类型。
    • TURN (Traversal Using Relays around NAT): 当 STUN 无法实现 P2P 连接时（例如双方都在对称型 NAT 之后），就需要一个公网服务器来中继所有数据。这个服务器就是 TURN 服务器。使用 TURN 会增加延迟并消耗服务器带宽，是最后的保底方案。
    • 工作流程: 客户端收集所有可能的候选地址（本地地址、STUN 返回的公网地址、TURN 中继地址），通过信令交换给对方，然后双方尝试所有地址对进行连通性检查（Connectivity Checks），最终选择一条最优路径（P2P > STUN > TURN）来传输数据。
  • SRTP/SRTCP (Secure Real-time Transport Protocol):
    • RTP: 承载音视频媒体数据的主要协议。
    • RTCP: 用于传输控制信息，如丢包统计、网络延迟（RTT）、收发报告等，是实现拥塞控制和网络状态监控的基础。
    • Secure (S): WebRTC 规定所有媒体流都必须加密。SRTP 就是在 RTP 协议上增加了加密和认证层，保证了通信的机密性和完整性。
  • DTLS (Datagram Transport Layer Security):
    • 作用: 用于 SRTP 的密钥协商。DTLS 就像是 UDP 版本的 TLS (HTTPS 用的)。在媒体传输开始前，双方通过在 P2P 连接上运行 DTLS 握手，安全地交换 SRTP 会话所需的对称加密密钥。
  • SCTP (Stream Control Transmission Protocol):
    • 作用: 用于 RTCDataChannel。SCTP 协议本身是运行在 IP 层之上的，但 WebRTC 很巧妙地将其封装在 DTLS/UDP 之上进行传输。
    • 特性: 提供了多种数据传输模式，如：
      • 可靠/不可靠传输
      • 有序/无序传输
      • 多流支持（避免队头阻塞） 这使得 DataChannel 非常灵活，既可以像 TCP 一样用于文件传输，也可以像 UDP 一样用于实时游戏状态同步。
  • 拥塞控制 (Congestion Control):
    • GCC (Google Congestion Control): 这是 WebRTC 最重要的网络自适应算法之一。它通过分析 RTCP 报告中的包到达时间、丢包率等信息，实时估算当前网络链路的可用带宽（Bandwidth Estimation, BWE）。然后，它会把这个估算值反馈给视频编码器，动态调整编码码率，使其不超过当前网络所能承载的带宽，从而避免网络拥塞，保证通话的流畅性。

硬件抽象层

这一层是 WebRTC 引擎与操作系统底层之间的桥梁。

  • 视频采集模块 (Video Capture Module, VCM): 抽象了不同操作系统下的摄像头 API（如 Windows 的 DirectShow/Media Foundation, Linux 的 V4L2, macOS/iOS 的 AVFoundation）。
  • 音频设备模块 (Audio Device Module, ADM): 抽象了不同操作系统下的麦克风采集和音频播放 API。

通过这一层，WebRTC 的核心 C++ 代码可以实现跨平台，无需关心具体平台的硬件细节。

总结

WebRTC 是一个高度集成和复杂的实时通信框架。它将音视频处理、网络传输、安全加密等众多领域的顶尖技术融为一体：

  • 上层，它为开发者提供了简洁的 API。
  • 中层，它把复杂的媒体协商和网络发现过程标准化（SDP/ICE）。
  • 底层，它拥有强大的 C++ 引擎，通过 NetEQ、AEC、GCC 等一系列先进算法，在不稳定、多变的互联网上实现了高质量、低延迟的实时音视频通信。