如果你曾在浏览器中加入视频通话而无需安装任何东西，你就使用过 WebRTC。如果你想知道它实际上是如何工作的——两个浏览器如何在地球的另一端以亚秒级延迟相互传输视频，没有插件、没有 Flash、没有 Java 小程序——这份指南就是为你准备的。

WebRTC（Web 实时通信）是一个开源框架，允许浏览器和移动应用以实时方式进行点对点的音频、视频和任意数据交换。Google 在 2011 年发布了初始代码，W3C 在 2021 年对其进行了标准化，到 2026 年，它已支撑从 Zoom 风格的会议到 AI 语音代理再到远程医疗平台的一切应用。全球 WebRTC 市场预计今年将达到 108.9 亿美元，到 2034 年的年复合增长率约为 37%。

多年来，我已在几个生产应用中集成了基于 WebRTC 的功能，我可以告诉你：该协议优雅，API 出人意料地易于使用，但边界情况会让你谦虚。让我们深入探讨所有内容。

目录

WebRTC 是什么？开发者完整指南 2026

WebRTC 实际上是什么

WebRTC 的核心是一组 JavaScript API 和底层网络协议，允许两个端点——通常是浏览器——建立直接连接并交换媒体或数据。在理想情况下，没有服务器位于媒体路径的中间。没有插件。没有下载。

"实时"部分很重要。我们讨论的延迟是以毫秒为单位，而不是秒。传统的基于 HTTP 的流媒体（HLS、DASH）通常会引入 3-30 秒的延迟。WebRTC 将其降低到 500 毫秒以下，通常在 200 毫秒以下。这是对话和对讲机通话之间的区别。

2026 年，WebRTC 受到所有主要浏览器的支持：

浏览器 WebRTC 支持 备注
Chrome 完全支持 参考实现
Firefox 完全支持 强大的 DataChannel 支持
Safari 完全支持 自 2020 年以来已显著跟上
Edge 完全支持 基于 Chromium，与 Chrome 相同
Brave 完全支持 基于 Chromium
Mobile Chrome/Safari 完全支持 iOS 历史上存在怪癖，大多已解决

它也可在浏览器外使用。存在用于 iOS、Android、C++、Rust 和 Python 的本地库。如果你正在构建 VoIP 应用、无人机控制系统或 IoT 数据管道，WebRTC 也可以在那里工作。

WebRTC 的底层工作原理

这是当我第一次接触 WebRTC 时真正帮助我理解它的心理模型。

想象两个人试图进行电话通话，但都不知道对方的电话号码，两人都被锁在门后（NAT 和防火墙）。他们需要一个共同的朋友（信令服务器）来交换号码。一旦他们获得彼此的信息，他们就直接通话——共同的朋友不再参与。

技术流程如下：

1. 媒体捕获

浏览器通过 getUserMedia() 请求访问用户的摄像头和麦克风的权限。这将返回一个 MediaStream 对象。

2. 信令（带外）

在两个对等方连接之前，他们需要交换连接元数据：他们支持哪些编解码器、他们的网络地址、安全指纹。这个交换称为信令，WebRTC 刻意不指定它如何发生。你可以使用 WebSocket、HTTP 轮询、信鸽——任何有效的方式。

信令交换涉及两种类型的消息：

  • SDP（会话描述协议）：描述对等方想要发送/接收什么媒体以及如何发送/接收
  • ICE 候选项：可以到达对等方的网络地址

3. 连接建立（ICE）

ICE（交互式连接建立）框架尝试多个路径来连接对等方。它首先尝试直接连接，然后使用 STUN 服务器发现公共 IP，如果点对点失败则回退到 TURN 中继服务器。

4. 安全媒体流

连接后，媒体在对等方之间直接流动，使用 DTLS 和 SRTP 加密。规范禁止任何未加密的 WebRTC 连接——这是强制性的。

三个核心 API

WebRTC 向 JavaScript 公开三个主要 API。理解这些占战斗的 80%。

getUserMedia()

从用户的设备捕获音频和视频。

// 基本的摄像头 + 麦克风访问
const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    frameRate: { ideal: 30 }
  },
  audio: {
    echoCancellation: true,
    noiseSuppression: true
  }
});

// 附加到视频元素
document.getElementById('localVideo').srcObject = stream;

你也可以使用 getDisplayMedia() 获取屏幕共享：

const screenStream = await navigator.mediaDevices.getDisplayMedia({
  video: { cursor: 'always' },
  audio: true // 系统音频，浏览器支持可能不同
});

RTCPeerConnection

这是主力。它管理对等连接的整个生命周期：编解码器协商、ICE 候选项收集、DTLS 握手、带宽估计、丢包恢复。

const config = {
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    {
      urls: 'turn:turn.yourserver.com:3478',
      username: 'user',
      credential: 'pass'
    }
  ]
};

const pc = new RTCPeerConnection(config);

// 添加本地轨道
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// 处理来自远程对等方的传入轨道
pc.ontrack = (event) => {
  document.getElementById('remoteVideo').srcObject = event.streams[0];
};

// 创建提议（调用方）
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
// 通过信令服务器将提议发送给远程对等方

// 在另一方，接收提议并创建应答
await pc.setRemoteDescription(receivedOffer);
const answer = await pc.createAnswer();
await pc.setLocalDescription(answer);
// 通过信令将应答发送回去

RTCDataChannel

这个没有得到足够的关注。DataChannel 允许你在对等方之间发送任意数据——文本、二进制、文件、游戏状态，任何东西。它建立在 SCTP 之上，所以你可以选择有序/无序交付和可靠/不可靠的传输。

const dataChannel = pc.createDataChannel('chat', {
  ordered: true // 保证消息顺序
});

dataChannel.onopen = () => {
  dataChannel.send('Hello from peer A!');
};

dataChannel.onmessage = (event) => {
  console.log('Received:', event.data);
};

// 在远程对等方
pc.ondatachannel = (event) => {
  const channel = event.channel;
  channel.onmessage = (e) => console.log('Got:', e.data);
};

我已使用 DataChannel 进行实时协作编辑、多人游戏状态同步，甚至大文件传输。由于数据不通过服务器路由，延迟远远低于 WebSocket。

WebRTC 是什么？开发者完整指南 2026 - 架构

信令：WebRTC 不处理的部分

这会在第一次让每个开发者失败。WebRTC 是媒体传输的协议，而不是发现的协议。两个对等方无法在没有帮助的情况下相互找到。

你需要构建（或使用）一个信令服务器，它：

  1. 让对等方注册其存在
  2. 转发对等方之间的 SDP 提议和应答
  3. 中继 ICE 候选项

大多数团队使用 WebSocket 进行信令。这是一个最小的 Node.js 示例：

// 服务器（使用 ws 库）
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

const rooms = new Map();

wss.on('connection', (ws) => {
  ws.on('message', (data) => {
    const msg = JSON.parse(data);
    
    if (msg.type === 'join') {
      rooms.set(msg.roomId, [...(rooms.get(msg.roomId) || []), ws]);
    }
    
    if (['offer', 'answer', 'ice-candidate'].includes(msg.type)) {
      // 转发给房间中的其他对等方
      const peers = rooms.get(msg.roomId) || [];
      peers.forEach(peer => {
        if (peer !== ws && peer.readyState === WebSocket.OPEN) {
          peer.send(JSON.stringify(msg));
        }
      });
    }
  });
});

信令服务器是你必须运行的唯一服务器。一旦连接建立，它可以离开（尽管你会想在重新连接场景中将其保留）。

NAT 穿透：STUN、TURN 和 ICE

这是 WebRTC 变得复杂的地方。大多数设备位于 NAT（网络地址转换）后面，这意味着其本地 IP 地址无法从互联网到达。WebRTC 使用三层方法来解决这个问题：

STUN（NAT 的会话穿越实用工具）：一个轻量级服务器，告诉你的浏览器"这是你的公共 IP 和端口"。Google 运行免费的 STUN 服务器（stun:stun.l.google.com:19302）。STUN 快速、便宜，并在大约 80-85% 的时间里有效。

TURN（使用 NAT 周围的中继进行穿越）：当直接点对点失败时（对称 NAT、严格防火墙），TURN 充当媒体中继。所有流量通过 TURN 服务器。这在 100% 的时间里有效，但消耗带宽并增加延迟。为生产应用运行你自己的 TURN 服务器是强制性的。Coturn 是标准的开源选项。

ICE（交互式连接建立）：协调 STUN 和 TURN 的框架。ICE 收集候选地址（本地、通过 STUN 的服务器反射、通过 TURN 的中继）并系统地测试它们以找到最佳的工作路径。

根据我的经验，生产中约 15-20% 的连接最终通过 TURN。企业防火墙是最大的罪魁祸首。为 TURN 服务器成本预算——它们不是可选的。

WebRTC 中的安全性

WebRTC 在默认情况下是安全的，这很令人欣慰。以下是内置的内容：

  • DTLS（数据报传输层安全）：加密所有数据通道。类似于 TLS 但针对 UDP。
  • SRTP（安全实时传输协议）：加密所有媒体流。
  • 强制加密：你无法建立未加密的 WebRTC 连接。规范禁止这样做。
  • 权限提示：浏览器在访问摄像头或麦克风之前需要明确的用户同意。
  • 源隔离：网页只能从安全源（HTTPS）访问 WebRTC API。

没有"禁用加密"标志。没有不安全的回退。这是一个经过深思熟虑的设计选择，这是个好选择。

也就是说，你的信令服务器是一个潜在的漏洞。如果有人破坏信令，他们可以将连接重定向到恶意对等方。使用经过身份验证的 WebSocket 连接并在服务器端验证一切。

2026 年 WebRTC 的使用场景

显而易见的用例是视频通话，但 WebRTC 已远远超出这个范围。

视频会议

Zoom、Google Meet、Microsoft Teams 和数十个较小的参与者都使用 WebRTC（或其底层协议的修改版本）。对于多方通话，大多数平台使用 SFU（选择性转发单元）架构而不是纯点对点——下面会有更多关于这一点的信息。

AI 语音代理

这是 2026 年增长最快的用例。Vapi、Retell 和 Bland.ai 等公司使用 WebRTC 在用户和 AI 模型之间实时传输音频。亚 200 毫秒的延迟至关重要——任何更多的延迟都会使对话感觉不自然。

远程医疗

远程医生访问在 COVID 期间激增，从未消退。WebRTC 提供符合 HIPAA 的加密视频，无需安装软件。

直播购物和广播

超低延迟流媒体用于直播电商。观众实时看到产品演示并可以立即互动。传统流媒体协议增加太多延迟。

客户支持

屏幕共享和视频聊天直接嵌入到支持小部件中。客户不下载任何东西。代理实时看到问题。

IoT 和无人机

DataChannel 非常适合向边缘设备发送控制命令和接收遥测。WebRTC 中内置的 NAT 穿透解决了许多 IoT 开发人员需要手动处理的麻烦。

2026 年的新内容

WebRTC 并未停滞不前。几个重要的发展正在塑造我们现在使用它的方式。

AI 集成无处不在

实时转录、实时翻译、由 ML 模型驱动的背景噪声抑制、通话期间的情感分析——所有这些都依赖于 WebRTC 的低延迟传输。WebRTC 基础设施与大语言模型的融合可以说是今年实时通信中最大的单一趋势。

WebTransport 和 WebCodec

WebTransport（建立在 HTTP/3 和 QUIC 之上）为某些流媒体场景提供替代传输层。它不是在替代 WebRTC——它不处理点对点或 NAT 穿透——但对于服务器到客户端流媒体来说是一个强有力的补充，在这种情况下你希望更好地控制编码。

WebCodec 使开发者可以直接访问硬件视频编码器和解码器，绕过浏览器的媒体管道。结合 WebRTC 的可插入流 API，这支持自定义视频处理（端到端加密、AR 过滤器）的性能要好得多。

可扩展视频编码（SVC）

SVC 支持已大幅成熟。VP9 SVC 和 AV1 SVC 等编码器允许单个编码流服务多个质量级别，这对于基于 SFU 的架构来说是巨大的。与其编码三个单独的质量流（模拟播放），你编码一次，SFU 根据每个接收器的带宽剥离层。

WHIP 和 WHEP

WebRTC-HTTP 摄入协议（WHIP）和 WebRTC-HTTP 出口协议（WHEP）正在标准化 WebRTC 如何连接到媒体服务器。在这些协议之前，每个媒体服务器都有自己的专有信令。WHIP/WHEP 为生态系统带来理智。

WebRTC vs. 替代方案

WebRTC 与其他实时通信技术相比如何？

技术 延迟 方向 NAT 穿透 浏览器支持 最适合
WebRTC < 500ms P2P 或通过 SFU 内置（ICE） 所有主要浏览器 视频通话、实时交互
HLS 3-30s 服务器 → 客户端 N/A 通用 VOD、向大观众直播
DASH 3-30s 服务器 → 客户端 N/A 大多数浏览器 自适应比特率 VOD
WebSocket ~50ms（仅数据） 客户端 ↔ 服务器 否 所有主要浏览器 聊天、通知、实时数据
WebTransport ~50ms 客户端 ↔ 服务器 否 Chrome、Firefox、Edge 低延迟服务器流媒体
RTMP 1-5s 客户端 → 服务器 否 需要播放器 摄入到流媒体平台
SRT 0.5-2s 点对点 受限 需要应用 广播贡献

关键区别：WebRTC 是唯一的浏览器原生选项，可进行点对点通信，并具有内置的 NAT 穿透和强制加密。如果你需要在浏览器中进行实时双向通信，它仍然是答案。

使用 WebRTC 构建：库和平台

你可以使用原始浏览器 API 从头开始构建一切。我已经做过。除非你有深厚的专业知识和特定的原因，否则我不建议为生产推荐。

以下是 2026 年重要的工具：

媒体服务器（SFU）

  • LiveKit：开源，使用 Go 构建，开发者体验出色。我对大多数项目的当前建议。支持 SFU 架构、模拟播放、数据通道，并为每个主要平台都有 SDK。
  • Janus：成熟的基于 C 的媒体服务器。非常灵活，但较低级别。你会编写更多代码。
  • mediasoup：基于 Node.js 的 SFU。如果你的团队在 JavaScript 生态系统中工作很好。
  • Pion：Go 中的 WebRTC 实现。不是完整的媒体服务器，但对于构建自定义 WebRTC 基础设施非常有用。

CPaaS 平台

  • Twilio：800 磅的大猩猩。广泛的 API、良好的文档、优质的定价。
  • Agora：在亚太地区实力强劲，SDK 质量好。
  • Daily.co：开发者友好，简洁的 API，合理的定价。
  • Vonage（原 Tokbox）：可靠，一直都在。

何时构建 vs. 购买

如果你正在构建一个产品，其中视频是一个功能（比如向支持仪表板添加视频聊天），使用 CPaaS 或 LiveKit。如果视频是产品，你可能需要更多控制权，应该考虑运行自己的 SFU 基础设施。

对于使用 Next.js 或 Astro 等框架构建的 web 应用，通过 LiveKit 的 React SDK 等库集成 WebRTC 很简单。我们已经将实时视频功能集成到无头 CMS 驱动的网站——解耦架构实际上使其更容易，因为你的前端框架处理 UI，而 WebRTC 独立处理媒体传输。

常见陷阱和经验教训

在构建多个 WebRTC 应用后，以下是我希望有人之前告诉我的内容：

始终部署 TURN 服务器。 我看到开发者跳过 TURN，因为"在测试中工作良好"。它工作良好是因为你的测试设备在同一网络上。在生产中，15-20% 的用户将位于限制性 NAT 或防火墙后面。没有 TURN，那些用户根本无法连接。

优雅地处理断开连接。 网络条件不断变化。你的应用需要检测连接断开、尝试重新连接并通知用户——所有这一切都不会丢失应用状态。iceconnectionstatechange 事件是你的朋友。

带宽估计很困难。 WebRTC 具有内置的带宽估计，但它不是魔法。在拥塞的网络上，视频质量会下降。使用 getStats() 监视连接质量并相应地调整你的 UI——也许显示"连接不佳"指示器或降至仅音频。

Safari 有怪癖。 它变得好得多，但 Safari 仍然以不同的方式处理一些边界情况。尽早和经常在实际 iOS 设备上测试。特别是，模拟播放行为可能会让你感到惊讶。

扩展超越点对点需要 SFU。 1 对 1 通话是直接的 P2P。4 人通话使用网格（每个人都与每个人连接）意味着每个参与者维护 3 个连接，编码和上传 3 个视频流。它不能扩展。对于超过 3 个参与者的任何内容，使用一个 SFU，其中每个参与者向服务器发送一个流，服务器转发给其他所有人。

如果你正在构建实时应用，需要在无头 CMS 设置旁边帮助架构 WebRTC 层，与我们联系——我们做过足够多次的此操作以了解地雷在哪里。

常见问题

WebRTC 代表什么？ WebRTC 代表 Web 实时通信。这是一个开源项目和 W3C 标准，为浏览器和移动应用提供了通过简单 JavaScript API 进行实时音频、视频和数据通信的功能。

WebRTC 可以免费使用吗？ WebRTC API 和协议完全免费且开源。但是，构建生产应用涉及信令服务器、TURN 中继服务器（消耗带宽）的成本，以及可能的媒体服务器（SFU）用于多方通话的成本。STUN 服务器通常是免费的——Google 提供公共的。

WebRTC 无需服务器即可工作吗？ 并非完全如此。虽然媒体流是点对点的（媒体路径中没有服务器），但你仍然需要一个信令服务器来帮助对等方相互发现和交换连接信息。你还需要 STUN/TURN 服务器进行 NAT 穿透。关键点是服务器看不到或处理媒体数据。

WebRTC 与 WebSocket 有什么不同？ WebSocket 提供了客户端和服务器之间的持久双向连接——非常适合聊天、通知和实时数据。WebRTC 提供客户端之间的点对点连接，针对媒体（音频/视频）进行了优化。WebRTC 使用 UDP 以获得更低的延迟，而 WebSocket 使用 TCP。在实践中，许多应用使用 WebSocket 进行信令，使用 WebRTC 进行媒体传输。

WebRTC 可以用于向数千名观众直播吗？ 纯点对点 WebRTC 无法扩展到数千名观众。但是，与 SFU 或媒体服务器结合，WebRTC 可以处理大规模广播。平台使用广播方将一个流发送到服务器的架构，服务器通过 WebRTC 将其分发给数千名观众。对于超过 10,000 观众的观众，基于 CDN 的 HLS/DASH 方法通常在成本效益上更高。

WebRTC 安全吗？通话可以被截获吗？ WebRTC 在设计上是安全的。所有媒体和数据都使用 DTLS 和 SRTP 加密——加密是强制性的，无法禁用。在点对点场景中，加密是端到端的。使用 SFU 时，服务器解密并重新加密媒体，所以你信任服务器操作者。为了通过 SFU 进行真正的端到端加密，请查看可插入流（也称为 WebRTC 中的"E2EE"）。

STUN 和 TURN 服务器有什么区别？ STUN 服务器是轻量级的——他们只是告诉你的浏览器其公共对外的 IP 地址和端口，这有助于建立直接的点对点连接。TURN 服务器更重——它们充当中继，在直接连接失败时转发所有媒体流量。STUN 便宜（几乎免费），TURN 昂贵（你为带宽支付）。约 80-85% 的连接仅使用 STUN 即可成功；TURN 处理其余的。

WebTransport 会替代 WebRTC 吗？ 不会。WebTransport 和 WebRTC 解决不同的问题。WebTransport（建立在 HTTP/3 和 QUIC 之上）非常适合具有低延迟的客户端到服务器通信，但它不进行点对点连接或 NAT 穿透。WebRTC 仍然是唯一的浏览器原生解决方案用于直接点对点媒体通信。它们是互补的技术，在 2026 年许多应用同时使用两者。