WebRTC（Web 实时通信）是一项强大的技术，其核心目标是使 Web 应用程序和站点能够捕获和选择性地流式传输音频或视频媒体，以及在浏览器之间交换任意数据，而无需中间件。它允许网络应用或站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。WebRTC 是一个免费的开放项目，通过简单的 API 为浏览器和移动应用程序提供实时通信（RTC）功能，并由 Google 在 2011 年将其开源。
WebRTC 的愿景与目的
WebRTC 的最终目的是让 Web 开发者能够基于浏览器（如 Chrome、Firefox）轻易快捷地开发出丰富的实时多媒体应用。这使得用户无需下载安装任何插件或任何其他第三方软件，即可实现点对点数据共享和电话会议。Google 希望通过 WebRTC 建立一个多互联网浏览器间健壮的实时通信平台，并致力于使其技术成为 HTML5 标准之一。
核心功能与能力
WebRTC 提供了广泛的功能，包括：
音频和视频会议。
文件交换。
屏幕共享。
身份管理。
与传统电话系统的接口，包括发送 DTMF（按键拨号）信号。
通过数据通道交换任意二进制数据，可用于反向信道信息、元数据交换、游戏状态数据包、文件传输，甚至作为数据传输的主要通道。
远程访问 远端计算机或应用程序，特别适用于本地硬件无法执行繁重计算任务的场景。
分布式 CDN 和物联网（IoT） 应用，例如安全摄像头视频流传输和传感器数据交换。
媒体和数据协议桥接，允许 WebRTC 与 SIP、RTSP 或 SSH 等现有协议进行通信。
远程操作，例如通过数据通道控制远端设备并接收视频数据。
WebRTC 的主要技术组件
WebRTC 由几个相互关联的 API 和协议组成，其技术组成大致可分为三部分：Web 前端开发使用的 API、浏览器厂商使用的 API，以及包括音频引擎、视频引擎和网络传输在内的底层引擎。核心组件包括：
MediaStream：用于捕捉和管理本地和远程的音频和视频。它表示媒体数据流，可包含一个或多个轨道（MediaStreamTrack），这些轨道在渲染时同步。 getUserMedia() API 是获取本地多媒体内容的关键方法。
RTCPeerConnection：表示本地计算机与远程对等方之间的 WebRTC 连接。它是用于传输音频、视频和数据的对等连接的核心接口。
RTCDataChannel：表示连接的两个对等方之间双向数据通道，用于交换任意数据。
ICE（Interactive Connectivity Establishment，交互式连接建立）：一个框架，用于允许 WebRTC 等网络应用通过 NAT（网络地址转换）和防火墙在对等端之间找到最佳的路径来发送和接收媒体。ICE 整合了 STUN 和 TURN 两种协议。
STUN（Session Traversal Utilities for NAT，NAT 会话穿越应用程序）服务器：帮助 WebRTC 客户端发现它们的公共 IP 地址和 NAT 后面的端口，即所谓的 P2P“打洞”。它还用于判断 NAT 限制其直连的方法。
TURN（Traversal Using Relays around NAT，NAT 中继遍历程序）服务器：当直接 P2P 连接（STUN 打洞）失败时，特别是对于对称型 NAT，TURN 服务器会充当中继，转发两个无法直接连通的端点之间的流量。
SDP（Session Description Protocol，会话描述协议）：用于描述多媒体通信会话的信息格式，例如编解码器信息、媒体类型（音频或视频）和网络信息。在连接建立过程中，SDP 描述符通过信令机制在对等端之间交换，以协商连接参数。
WebRTC 的工作流程
本节已抽离为独立文章，包含完整流程解析与配套 Mermaid 图表。
阅读链接：WebRTC 工作流程：信令、SDP、ICE/STUN/TURN 全流程解析
优势与挑战
优势方面，WebRTC 的主要优点包括：
点对点直接通信，减少数据经过中间服务器的环节，提高效率和隐私性。
无需插件或第三方软件，浏览器原生支持，简化用户体验和开发过程。
内置拥塞控制和自适应比特率，能够根据网络条件变化提供最佳用户体验。
数据通道灵活性高，支持不可靠无序传输，减少队头阻塞，适用于低延迟应用如游戏。
互操作性强，支持多种编程语言，且作为通用协议，难以被轻易阻止，有助于审查规避。
然而，WebRTC 也面临一些挑战：
技术复杂性：涉及协议众多，P2P 打洞原理复杂，门槛较高。
信令服务器的实现：WebRTC 仅提供客户端 API，不包含信令服务器，需要开发者自行实现。
NAT 类型处理：经典的 NAT 类型（完全圆锥型、受限圆锥型、端口受限圆锥型、对称型）需要不同的打洞方式。特别是对称型 NAT 无法被直接穿越，必须依赖 TURN 服务器进行流量中继。
RTCDataChannel 的消息大小限制：历史上，由于 SCTP 协议的设计，大于 16 KiB 或 64 KiB 的消息可能导致传输复杂或阻塞。新的流调度器（SCTP ndata 规范）正在开发中以解决此问题。
浏览器兼容性：虽然 WebRTC 在现代浏览器中通常得到很好的支持，但仍存在一些不兼容性，需要使用 adapter.js 等库来适配.