WebRTC

WebRTC

全称	Web Real-Time Communication
类型	开放标准 / 通信协议
标准化机构	W3C、IETF
标准化时间	2021年1月（W3C Recommendation）
首次开源	2011年5月
开发者	Google（初始）
传输层	UDP（RTP/DTLS）、TCP（信令）
核心API	getUserMedia、RTCPeerConnection、RTCDataChannel

WebRTC（全称：Web Real-Time Communication）是一套由W3C与IETF联合标准化的开放技术框架，包含一组JavaScript API及底层通信协议，支持浏览器与移动应用在不依赖插件的情况下实现点对点实时音视频通话与数据传输。 该框架于2021年1月被W3C正式采纳为Recommendation，同时其协议栈被IETF确立为互联网标准，标志着WebRTC成为Web平台原生实时通信的基础性技术。

历史

WebRTC的技术根基可追溯至1990年代末成立的瑞典公司Global IP Solutions（GIPS），该公司专注于开发高鲁棒性的实时音视频编解码与网络传输引擎，其技术曾应用于Skype等早期VoIP产品。 2010年，Google以约6820万美元收购GIPS，同时收购了拥有VP8视频编解码技术的On2 Technologies。

2011年5月，Google将相关代码开源并正式提出WebRTC项目，同年IETF成立rtcweb工作组，W3C成立WebRTC工作组，两个标准化机构开始了长达十年的协同标准化工作。 2013年，首个跨浏览器WebRTC视频通话演示成功。2021年1月26日，W3C与IETF联合宣布WebRTC成为正式标准，使其成为继插件时代终结后唯一 survived 的浏览器原生媒体传输标准。

技术架构

核心API

WebRTC在浏览器端通过三个核心JavaScript API暴露其功能。MediaStream API（又称getUserMedia）负责访问本地摄像头、麦克风及屏幕捕获设备，输出MediaStream对象供后续处理。 RTCPeerConnection API管理点对点连接的完整生命周期，包括编解码协商、带宽自适应、丢包恢复、回声消除及加密握手等。 RTCDataChannel API则提供双向、低延迟的任意数据传输通道，支持可靠与不可靠两种传输模式，适用于实时游戏状态同步、文件传输及即时消息等场景。

协议栈

WebRTC的底层协议栈由IETF标准化。会话描述协议（SDP）用于在通信双方间交换媒体能力、编解码偏好及传输参数，遵循offer/answer模型。 交互式连接建立（ICE）框架负责在复杂网络环境下发现最优通信路径，其通过STUN服务器协助对等端发现公网IP地址与端口，并在直接连接不可行时借助TURN服务器中继媒体流量。 所有媒体流均强制采用DTLS-SRTP进行端到端加密，其中DTLS用于密钥交换与身份验证，SRTP用于加密RTP媒体包，该加密机制为规范强制要求而非可选配置。

信令机制

WebRTC规范本身不定义信令协议，开发者可自行选择WebSocket、HTTP或SIP等传输方式完成初始握手。信令阶段需交换三类信息：会话控制消息、网络地址（ICE候选）及媒体元数据（SDP offer/answer）。 一旦ICE完成路径选择并建立安全通道，媒体与数据即可直接在peer间传输，信令服务器不再参与实际通信。

安全性

WebRTC从设计之初即将安全性作为核心原则。所有媒体流强制启用端到端加密，无法通过API禁用或降级。 浏览器在访问摄像头与麦克风前必须获得用户明确授权。此外，ICE候选收集过程可能暴露用户本地IP地址，引发隐私关切，现代浏览器已逐步采用mDNS候选替代私有IP地址以缓解该问题。

与VoIP的比较

WebRTC与传统VoIP技术存在显著差异。WebRTC为浏览器原生技术，无需安装插件或专用客户端，而传统VoIP通常依赖桌面应用或硬件终端。 WebRTC基于开放标准且无授权费用，传统VoIP生态则常涉及SIP服务器、媒体网关及编解码许可等成本。 在架构上，WebRTC优先采用点对点直连以降低延迟与服务器负载，传统VoIP多采用集中式服务器架构。

应用领域

WebRTC已成为现代实时通信的基础设施。在视频会议领域，Google Meet、Microsoft Teams及Zoom的Web客户端均基于WebRTC构建。 在协作工具中，它支持文档协同编辑与屏幕共享。在物联网与远程医疗场景中，WebRTC为设备远程监控与实时健康数据传输提供低延迟通道。 此外，在线多人游戏、P2P文件传输、直播流媒体及客户支持嵌入式音视频通话等场景亦广泛采用该技术。

扩展架构

纯点对点WebRTC在多方会议场景中存在带宽瓶颈——每增加一个参与者，各端的上行带宽需求线性增长。为此，生产级应用通常引入媒体服务器扩展架构。 选择性转发单元（SFU）接收各参与者的媒体流后选择性转发给其他 peer，显著降低客户端带宽压力，支持数十至数百人规模的会议。 多点控制单元（MCU）则将所有输入流混合为单一输出流，适用于传统视频会议终端兼容场景，但服务器计算开销较高。