WebRTC 初识

WebRTC 的发展历程

WebRTC 是一项实时通讯技术，它允许网络应用或者站点在不借助中间媒介的情况下，建立浏览器之间点对点的连接，实现视频流、音频流或其他任意数据的传输。

功能

• 音视频处理：提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、显示等功能。例如，使用 iSAC、iLBC 等音频编解码器以及 VP8 视频编解码器，还具备回声消除、噪声抑制等声音处理和图像质量增强功能。
• 数据传输：支持任意数据的传输，通过 RTCDataChannel 组件可实现二进制数据（如文件或图像）和文本数据的点对点交换。
• 设备管理：在不同平台上采用相应技术管理音频和视频设备，如在 Windows 平台上，采用 Windows Core Audio 和 Windows Wave 技术管理音频设备，采用 DShow 技术实现枚举视频设备信息和视频数据采集。

特点

• 方便易用：用户无需安装插件或第三方软件，通过浏览器就能实现实时通信。开发者使用简单的 HTML 标签和 JavaScript API 就能实现 Web 音 / 视频通信功能。

• 免费开源：Google 对 WebRTC 技术不收取任何费用，且该技术开源，开发者可访问并获取其源代码、规格说明和工具等。

• 跨平台性强2：支持多种浏览器和操作系统，如 Windows、Linux、Mac、Android 等，具有良好的跨平台性。

• 实时性好：基于 P2P 技术，能提供低延迟的实时通信，适用于对实时性要求高的应用场景。

• 安全性高3：支持端到端加密，采用安全实时传输协议（SRTP），可防止窃听或篡改数据包，保障通信安全。

缺点

• 传输质量难保证：传输设计基于 P2P，难以保障传输质量，优化手段有限，在跨地区、跨运营商、低带宽、高丢包等复杂网络场景下表现可能不佳。
• 设备端适配问题多：安卓设备厂商众多，每个厂商都会在标准的安卓框架上进行定制化，导致在安卓设备上容易出现访问麦克风失败、回声、啸叫等可用性和质量问题。
• 对 Native 开发支持不足：涉及音视频采集、处理、编解码、实时传输等较多领域知识，整个框架设计复杂，API 粒度细，工程项目编译难度大。
• 隐私保护有挑战：使用 P2P 技术，可能会泄露用户的 IP 地址和位置信息，需要进行额外的隐私保护措施。

应用范围

• 在线会议：实现多人实时音视频会议，支持屏幕共享、文件共享等功能，广泛应用于企业远程办公等场景。
• 视频聊天：实现一对一或多人视频聊天，增强社交互动，满足人们的沟通需求。
• 直播：用于构建低延迟的实时直播平台，支持观众与主播互动，提升直播体验。
• 物联网：适用于智能家居设备、医疗保健设备等智能设备间的数据传输，可确保低延迟、安全地传输数据。

学习参考地址

WebRTC 官方网站

WebRTC 官方中文网

官方源码仓库

GitHub 镜像仓库

架构设计

MDN Web Docs - WebRTC

架构设计

一. 整体架构

WebRTC 的架构设计可分层理解，每层各司其职，共同实现实时通信功能，以下是通俗化描述：

最上层：Web API（面向网页开发者）

由 W3C 组织制定规范，为网页开发者提供接口（如 JavaScript 调用）。开发者无需关心底层复杂技术，直接通过这层 API 就能在网页中实现实时音视频通话、数据传输等功能，像搭建积木一样简单。

中间核心层：WebRTC 功能模块

• PeerConnection（对等连接） ：
  基于 C++ API，负责建立和管理点对点连接，就像在两个设备间搭起一条专属通道，确保数据直接、高效地传输。
• 会话管理（Session） ：
  对信令（如连接建立前的协商信息）进行抽象处理，不关心信令具体如何传输（比如通过什么服务器），只专注于管理会话逻辑，让不同场景下的信令处理更灵活。

功能模块细分

• 语音引擎（Voice Engine） ：

  • 包含 ISAC / LBC 等音频编码技术，压缩音频数据以便高效传输。
  • NetEQ 技术优化语音质量，处理网络抖动带来的影响。
  • 集成回声消除（Echo Canceler）和噪声 reduction（降噪）功能，确保语音清晰，就像给声音 “打扫卫生”。

• 视频引擎（Video Engine） ：

  • 使用 VP8 等视频编码压缩视频数据。
  • 视频抖动缓冲（Video jitter buffer）处理视频传输中的延迟问题，让画面更流畅。
  • 图像增强（Image enhancements）提升视频画面质量，比如优化清晰度、色彩。

• 传输（Transport） ：

  • SRTP（安全实时传输协议）加密数据，防止传输内容被窃取或篡改。
  • 多路复用（Multiplexing）让多种数据（如音频、视频、信令）在同一通道有序传输。
  • 集成 P2P 技术（STUN + TURN + ICE），解决网络穿透问题，即使在复杂网络环境（如防火墙后）也能建立连接。

最底层：可定制模块（面向浏览器厂商）

• 音频捕获 / 渲染（Audio Capture/Render） ：负责采集声音和播放声音，浏览器厂商可自行实现优化。

• 视频捕获（Video Capture） ：控制摄像头采集视频画面，厂商可根据硬件适配。

• 网络 IO（Network I/O） ：管理网络数据的输入输出，厂商可优化网络通信效率。

整个架构通过分层设计，既为开发者提供简单易用的接口，又通过底层模块实现复杂的实时通信功能，同时保留浏览器厂商的定制空间，兼顾了实用性、灵活性与效率。

二. 交互时序

WebRTC 点对点交互的逻辑过程基于信令服务器完成会话描述（SDP）与网络地址（ICE 候选）的交换，最终建立直接连接，具体如下：

1. 会话描述（SDP）交换

• 端点 A 生成 Offer：
  A 创建 PeerConnection 对象，生成包含本地媒体信息（如音频编码、视频编码等）的会话描述（SDP），称为 Offer。
• Offer 发送至端点 B：
  A 将 Offer 通过信令服务器转发给 B。
• 端点 B 生成 Answer：
  B 收到 Offer 后，创建自己的 PeerConnection 对象，基于 Offer 内容生成应答的 SDP（即 Answer），包含本地媒体配置信息。
• Answer 反馈给端点 A：
  B 将 Answer 通过信令服务器回传给 A。至此，双方完成媒体格式、编解码等关键信息的协商。

2. ICE 候选地址交换

• 收集 ICE 候选地址：
  A 和 B 各自在本地收集网络地址信息（即 ICE 候选），包括主机地址（Host）、服务器反射地址（SRFLX，通过 STUN/TURN 服务器获取）等。
• 交换 ICE 候选：
  A 和 B 通过信令服务器互相发送各自的 ICE 候选地址。
• 连接检查与匹配：
  双方尝试用对方的候选地址进行连接测试，通过不断尝试不同组合（如 A 的某候选地址与 B 的某候选地址配对），找到能成功通信的路径，完成网络连接的打通。

3. 媒体数据传输

一旦 ICE 连接成功，A 和 B 之间建立起点对点的直接通道。此时，音频、视频等媒体数据不再经过信令服务器，而是通过该通道直接传输，实现实时通信。

整个过程中，信令服务器仅辅助交换控制信息（SDP、ICE 候选），不参与媒体数据传输，确保了通信的高效性与实时性。

三. 结合应用开发的交互设计

这是一幅 WebRTC 通信流程示意图，展示了两个端点（图中以 “Caller” 和 “Callee” 为例）基于 WebRTC 实现实时通信的关键交互过程，具体解释如下

• 1. 信令（Signaling）交互：
     图中两个绿色 “App”（应用程序）通过 “Signaling”（信令）与中间的云状结构（通常代表信令服务器）通信。信令服务器负责在两个端点之间转发控制信息，如会话描述（SessionDescription）、连接配置等，这些信息是建立通信链路的基础，但不直接传输媒体数据。
• 2. 会话描述（SessionDescription）传递：
     应用程序（App）层生成包含媒体参数（如编解码方式、媒体类型等）的会话描述（SessionDescription），并将其传递给底层的 WebRTC 模块（蓝色 “Browser” 部分）。这一步是双方协商通信参数的关键，确保两端支持相同的媒体格式和传输配置。
• 3. 媒体（Media）传输：
     在完成信令交互和参数协商后，两个浏览器（Browser）中的 WebRTC 模块直接建立连接，实现媒体数据（如音频、视频）的点对点传输（图中虚线箭头 “Media”）。此时，媒体数据不再经过信令服务器，而是通过优化后的网络路径直接传输，保证实时性和效率。

总结来说， WebRTC 通信的核心逻辑：通过信令服务器交换会话描述以协商通信参数，最终在浏览器端建立直接的媒体传输链路，实现实时音视频交互。

四. 协议栈

各位开发人员，下面我们来详细介绍 WebRTC 的协议栈设计，它是为实现实时通信而优化的分层架构，每一层都有明确的职责和核心技术，具体如下：

1. 传输层（Transport）：UDP 优先

• 协议：使用 UDP（用户数据报协议）  作为底层传输协议。
• 原因：UDP 具有低延迟特性，适合实时音视频传输场景（允许一定数据丢失，但强调速度），满足 WebRTC 对实时性的要求。

2. 会话层（Session）：DTLS 加密

• 协议：采用 DTLS（数据报传输层安全协议） 。
• 作用：为 UDP 传输的数据提供加密保护，防止数据在传输过程中被窃听、篡改，确保通信安全，类似 TLS 对 TCP 的保护，但适用于 UDP 场景。

3. 网络与连接层：ICE、SDP、STUN、TURN

• ICE（交互式连接建立） ：

  • 收集所有可能的网络地址（如主机地址 Host、服务器反射地址 SRFLX、中继地址 Relay），尝试不同地址组合，找到两端点间最佳通信路径，实现 NAT 穿透。
  • 优先级排序：Host > SRFLX > Relay，尽量使用直接连接以减少延迟。

• SDP（会话描述协议） ：

  • 协商通信参数，如音视频编解码格式（如 VP8、Opus）、媒体类型、带宽等，描述终端能力，是通信双方达成一致的基础。

• STUN（会话遍历实用网络地址转换） ：

  • 帮助获取公网地址，检测 NAT 类型，辅助 ICE 进行网络穿透。

• TURN（中继穿越 NAT） ：

  • 当 STUN 无法穿透时，作为中继服务器转发数据，确保在复杂网络环境下仍能建立连接。

4. 媒体与数据传输层

• RTP/SRTP（实时传输协议 / 安全实时传输协议） ：

  • RTP：定义音视频数据的封装格式、时间戳等，实现实时媒体流传输。
  • SRTP：在 RTP 基础上增加加密和完整性保护，防止媒体数据被窃取或篡改。

• SCTP（流控制传输协议） ：

  • 提供可靠、有序的数据传输通道，用于 DataChannel（数据通道），支持非媒体数据（如文本、文件、二进制数据）的传输，满足实时通信中多样化的数据交互需求。

5. 应用接口层

• RTCPeerConnection：

  • WebRTC 的核心接口，用于建立和管理端到端的连接，处理媒体流传输、带宽管理、连接状态监控等，是实现音视频通话的基础。

• DataChannel：

  • 支持浏览器间直接交换任意数据，拓展了 WebRTC 的应用场景，如实时聊天、文件传输、游戏数据交互等。

WebRTC 协议栈通过 UDP 保证实时性，DTLS/SRTP 保障安全，ICE/SDP/STUN/TURN 解决网络连接与协商问题，RTP 处理媒体流，SCTP/DataChannel 支持多样化数据传输，最终通过 RTCPeerConnection 提供简洁的应用接口。这种设计既兼顾了实时通信的高效性，又通过多层协议确保了安全性、兼容性和灵活性，是现代浏览器实时通信的核心技术架构。

实战开发

使用js开发的最简单的点对点视频通话。欢迎观看

视频讲解地址

GitHub项目源码地址