WebRTC

定义

WebRTC 指让网页应用具备实时通信能力的一整套技术和规范。它使网页与网站能够采集并传输音频、视频媒体，也能在不借助中间件的情况下于浏览器之间交换任意数据，点对点数据共享和电话会议因此无需用户安装插件，也不必另行下载本地程序。^[2]

从规范构成看，WebRTC 包含两个主要部分：一是互联网工程任务组制定的协议规范，二是万维网联盟制定的一系列 JavaScript 接口文档。二者配合，使网页中嵌入的脚本在获得用户授权后，能够建立包含音频、视频和辅助数据的通信；协议规范并不要求通信的另一方也实现这套接口，因此浏览器与实现同一协议的其他设备可以互通。^[3]

万维网联盟的 WebRTC 1.0 规范将该技术定义为：允许媒体数据和通用应用数据在浏览器或设备之间收发的 ECMAScript 接口集合，其配套的协议工作由互联网工程任务组的对应工作组完成。^[4]

原理

WebRTC 规范的核心接口是 RTCPeerConnection，它负责连接位于不同端点的两个应用，使其通过点对点方式通信。该接口与用于访问摄像头和麦克风的媒体采集接口配合，也与用于捕获屏幕内容的相关接口配合；连接建立并打开后，可以加入媒体流或数据通道。

在一次连接中，媒体流由若干轨道组成，轨道可以承载音频、视频或文本等不同数据。除媒体流外，两个对等方之间还可通过数据通道接口交换二进制数据，用于文件传输、游戏状态同步等场景。^[2]连接建立的协调过程称为信令，涉及会话控制以及网络地址、编解码器、带宽等元数据的交换；信令本身不在 WebRTC 技术规范的规定范围内，开发者可选用适合自身需求的协议，但信令过程通常需要有服务器中继消息。^[5]

要让处在网络地址转换(Network Address Translation)之后的设备互相通信，WebRTC 借助网络地址转换穿越技术，主要依赖 STUN 与 TURN 两种服务器：前者帮助设备获知自己的公网地址与端口，后者在受限严格的网络中充当媒体中继。媒体数据用实时传输协议传输，其安全版本提供加密与消息认证，实时传输控制协议则为传输质量提供反馈。^[5]

连接过程可简略表示为：网页脚本发起连接，双方经信令交换会话描述与候选地址，再通过连通性检查选出可用路径，随后媒体流或数据通道在该路径上传输。WebRTC 连接始终处于加密状态，加密由 DTLS 与 SRTP 两个已有协议实现；规范对音频编解码器与视频编解码器设定了必须支持的最低要求。

发展历程

WebRTC 的技术基础可追溯到 Global IP Solutions 这家从事网络电话与视频会议软件的公司，其编解码器、回声消除等技术是实时通信所需的关键组件。2010 年 5 月，Google 收购该公司，随后将相关技术开源，并与互联网工程任务组、万维网联盟等标准组织合作推动行业共识。^[6]

2011 年 5 月 31 日，Google 对外发布 WebRTC 开源软件包，用于在网页上实现实时语音与视频，并表示将把它集成进 Chrome 浏览器，同时希望以统一的标准接口让音频和视频在各类浏览器中可用。^[7]同年，爱立信实验室用改造过的 WebKit 库做出首个 WebRTC 实现，万维网联盟则于当年 10 月发布该规范的首份草案。^[6]

此后标准化工作与浏览器实现交替推进。2013 年 2 月出现首次跨浏览器视频通话，2014 年 2 月实现首次跨浏览器数据传输，其间 Mozilla、Microsoft、Cisco、Ericsson 等厂商与 Google 一同参与标准制定；随着规范逐步定型，浏览器之间的实现差异大多得到解决，规范还配套了测试集与工具来处理兼容性问题。^[6]

2021 年 1 月 26 日，万维网联盟与互联网工程任务组同时宣布 WebRTC 成为正式标准，其中包含 JavaScript 接口与一组通信协议，使任何联网设备都可能成为网页上的通信端点。^[1]2024 年 10 月，万维网联盟又发布了该规范的修订版本，包含若干实质性修改与新增特性。^[4]

应用

WebRTC 最直接的用途是网页中的音视频通信，包括视频会议、远程教育与远程医疗、娱乐、游戏以及专业协作等场景；由于相关能力被标准化并内置于浏览器和其他平台，构建一套音视频通信系统无需安装插件，也不必单独下载应用。^[1]

在时间敏感的场景中，WebRTC 的用途还包括远程手术、系统监控、自动驾驶车辆的远程控制，以及无法缓冲的语音或视频通话。多家公司提供的基于浏览器的视频通话服务以及云游戏串流平台，都采用该技术把游戏画面从云端传输到浏览器。

除了音视频，WebRTC 的数据通道还支持浏览器之间直接交换数据，可用于在线协作、实时游戏、文件分享，以及设备之间的通信。^[5]其技术也被用于与物联网相关的场景，例如传感器维持长期连接。^[1]

局限

WebRTC 的规范并不包含信令，即连接建立的协调过程没有统一规定。开发者必须自行选择协议并提供中继消息的服务器，这既带来灵活性，也意味着不同应用之间不能仅凭 WebRTC 规范直接互通。^[5]

点对点连接并不总能直接建立。当网络地址转换策略严格时，STUN 无法满足需要，必须改用 TURN 服务器中继媒体流，此时数据要绕经第三方服务器，路径不再是端到端的直连。^[5]

在隐私方面，连接过程会向通信对端暴露用于建立通信的 IP 地址。收集候选地址时可能暴露出局域网地址、经 STUN 服务器获知的公网地址或 TURN 服务器分配的地址，网页因此可能获知用户位于 VPN 或代理之后仍被隐藏的地址，这些信息也可被用于识别用户。^[8][9]

为减少此类暴露，浏览器厂商默认只暴露默认路由的候选地址，并采用掩藏本地地址的机制；但相关研究显示，局域网地址泄露在桌面浏览器上已基本消失，却在移动端仍然存在，伪装标识还可能成为会话期间稳定的指纹，运营商级网络地址转换本身也会带来可用于识别的信息，因此隐私问题尚未彻底解决。^[10][11]

参见

• RTCPeerConnection —— WebRTC 规范中表示对等连接的核心接口。

• STUN —— 帮助设备发现自身公网地址与端口的协议。

• TURN —— 在直连不可行时中继媒体数据的协议。

• SDP —— 用于描述和协商多媒体会话参数的协议。

• WebSocket —— 常被用于实现 WebRTC 信令的传输协议。

• WebTransport —— 受 WebRTC 数据通道启发而发展的客户端与服务器通信接口。