WebRTC 如何让网页实现端到端的通信

一、 初识WebRTC：它是什么？

想象一下，当你想通过网页和好友视频聊天时，通常需要下载一个软件（如Skype、Zoom）或插件。而WebRTC就是为了打破这个限制而生。

• 它的全称是 Web实时通信。
• 它的目标是为网页（Web）赋予直接进行实时音视频通话、数据传输的“超能力”。
• 它的核心特点是点对点（P2P） 和端到端加密。这意味着，一旦连接建立，数据（你的语音、画面、聊天文字）会直接在两个浏览器之间传输，不再需要通过中心服务器“绕路”，从而延迟更低、隐私性更强。

二、 核心概念：它是如何工作的？

WebRTC的整个过程可以类比为两位陌生人准备通过一个安全的秘密隧道直接通话。这需要三个关键步骤：

1. 交换“接头方式”
2. 打通“网络通道”
3. 开始“安全通话”

具体到技术层面，这由三大API和两种服务器角色实现：

🔑 三大核心JavaScript API

这是前端开发者直接使用的工具。

• getUserMedia: 获取“麦克风”和“摄像头”的访问权限。这是获取音视频流的起点。
• RTCPeerConnection: 核心中的核心。它负责在两端的浏览器之间建立并维护那个高效的、加密的“点对点连接通道”，处理所有复杂的音视频编码、网络传输等工作。
• RTCDataChannel: 在已建立的RTCPeerConnection通道上，再开一个数据传输的小通道。你可以用它来发送任何二进制或文本数据（比如聊天文字、文件），实现一个“端到端加密的聊天室”。

🖥️ 两大后台服务器角色（非内容中转）

这些服务器只负责“牵线搭桥”，不负责传递通话内容本身，因此它们无法窃听。

• 信令服务器: 这是一个由开发者自己搭建的简单服务器（可以用WebSocket、Socket.io等轻松实现）。它的作用就像一个“传话员”，帮助交换两位陌生人的“接头方式”（即网络信息和连接参数）。
• STUN/TURN服务器: 用来帮助浏览器在复杂的网络环境（如防火墙或路由器后）发现自己和对方的公网地址，并建立连接。如果无法直连，TURN服务器会充当中转站，但它转发的是加密后的数据，依然无法解密内容。

三、 实现流程：一个简化的通话/聊天步骤

让我们通过一个经典的“A呼叫B”的例子，看看这些部分如何协同工作。

flowchart TD
    A[用户A<br>发起通话] --> B[调用 getUserMedia<br>获取本地音视频流]
    B --> C[创建 RTCPeerConnection 对象]
    C --> D[创建“邀约” Offer<br>并设置本地流]

    D -- 通过信令服务器转发 --> E{用户B<br>接受通话}

    E --> F[调用 getUserMedia<br>获取本地音视频流]
    F --> G[创建 RTCPeerConnection 对象]
    G --> H[收到“邀约”<br>创建“应答” Answer]

    H -- 通过信令服务器转发 --> I

    subgraph I [关键交互：网络协商与连接]
        direction LR
        J[A与B交换<br>ICE候选地址] --> K[通过STUN/TURN服务器<br>探测连通性]
        K --> L[建立最佳P2P连接]
    end

    L --> M[连接成功！<br>开始加密的端到端通话/数据传输]

下面，我们来拆解上图中信令交换和网络协商这两个关键环节：

步骤 1 & 2：发起邀约与接受应答

• 用户A：调用 createOffer 生成一个包含其媒体信息和加密密钥的 “邀约” 。A将此 offer 通过信令服务器发给B。
• 用户B：收到 offer 后，调用 createAnswer 生成一个 “应答” 。B将此 answer 通过信令服务器发回给A。

这就是“交换接头方式”。offer 和 answer 里包含了双方的“能力清单”（如支持哪些编解码器）和加密密钥的“种子”。

步骤 3：交换网络“地图”

• 在交换 offer/answer 的同时，A和B的浏览器会各自通过询问STUN服务器，获知自己的公网IP和端口，这些地址称为 ICE候选。
• 双方每发现一个候选地址，就立刻通过信令服务器告诉对方。
• 最终，双方根据这些“候选地址”列表，尝试各种连接路径（通常直连最快），选出最佳的一条，建立最终的点对点通道。

步骤 4：开始通信

• 当 RTCPeerConnection 状态变为“已连接”时，那个安全的秘密隧道就建好了。
• 此时，A和B的音视频流会通过这个隧道直接、加密地传输。如果要聊天，可以再通过 RTCDataChannel 在这个隧道里开一个数据小通道。

四、 为何安全？后台能监控吗？

这是WebRTC设计精妙之处，也是对开篇问题的直接回答：

1. 内容全程加密：RTCPeerConnection 使用 DTLS（用于数据）和 SRTP（用于音视频）协议对数据进行端到端加密。加密密钥只在交换 offer/answer 时由双方生成和共享，信令服务器只能看到加密后的密钥“种子”，无法算出真正的密钥。
2. 服务器不接触内容：信令服务器只传递“元数据”（连接信息）。STUN/TURN服务器只处理网络地址转换或转发加密后的数据包。它们都无法解密和看到通话或聊天内容。

因此，一个标准实现的WebRTC应用，后台无法监控聊天内容。除非应用本身在客户端做了手脚（例如，在本地录制并上传日志），但这已超出了WebRTC协议本身的范围。

五、 快速开始：一个简单的代码示例

以下是一个极度简化的代码片段，展示了如何使用 RTCPeerConnection 的核心方法。

// 假设我们已经通过信令服务器（signaling）建立了连接
const signaling = new SignalingChannel(); // 你的WebSocket连接
const pc = new RTCPeerConnection();

// 1. 当有远程流到来时，显示在video标签里
pc.ontrack = (event) => {
  document.getElementById('remoteVideo').srcObject = event.streams[0];
};

// 2. 发起方：创建邀约
async function createOffer() {
  // 获取本地媒体流（需要用户授权）
  const localStream = await navigator.mediaDevices.getUserMedia({video: true, audio: true});
  localStream.getTracks().forEach(track => pc.addTrack(track, localStream));

  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer); // 设置本地描述
  signaling.send({type: 'offer', sdp: offer.sdp}); // 通过信令发送
}

// 3. 接收方：处理邀约并应答
signaling.onMessage(async (message) => {
  if (message.type === 'offer') {
    // 设置远程描述（对方的邀约）
    await pc.setRemoteDescription(new RTCSessionDescription(message));

    // 获取本地流并添加
    const localStream = await navigator.mediaDevices.getUserMedia({video: true, audio: true});
    localStream.getTracks().forEach(track => pc.addTrack(track, localStream));

    // 创建并发送应答
    const answer = await pc.createAnswer();
    await pc.setLocalDescription(answer);
    signaling.send({type: 'answer', sdp: answer.sdp});
  }
});

// 4. 发起方：处理应答
signaling.onMessage(async (message) => {
  if (message.type === 'answer') {
    await pc.setRemoteDescription(new RTCSessionDescription(message));
  }
});

希望这份文档能帮你建立起对WebRTC清晰、直观的理解。如果你想深入了解信令服务器的具体搭建方法，或 RTCDataChannel 的使用细节，我可以为你提供进一步的资料。

本站提供了一个 WebRTC 的 MVP，可以立即体验 https://rx.sc.cn/dev-tools/rtc

补充介绍：🌐 STUN/TURN服务器：WebRTC的“网络向导”与“备用桥梁”

简单来说，STUN/TURN服务器是帮助WebRTC在复杂网络世界中建立直接连接的关键后台服务。它们本身不传递通话内容，而是专门解决“两个设备如何找到并连通彼此”这个难题。

一、STUN/TURN 核心比喻：它们像什么？

想象一下，你（浏览器A）和朋友（浏览器B）各自住在一个有门卫和复杂内部结构的公寓楼（局域网）里，你们想直接对话。

• STUN服务器 就像一个 “公共地址查询服务”。你问它：“从外部看，我的公网门牌号（IP地址和端口）是什么？” 它告诉你答案。然后你和朋友交换这个“公网门牌号”，尝试直接敲门连接。多数情况下，这就成功了。
• TURN服务器 则是在直接敲门失败时启用的 “中立传话站”。当你们的公寓楼（防火墙或运营商网络）政策严格到完全禁止外来直接访问时，双方就把所有话都送到这个传话站，由它代为转发。这是最后的手段，因为会引入延迟和服务器负担。

二、技术角色详解

1. STUN服务器

• 全称：NAT会话穿越实用工具。它的核心工作是解决 NAT穿透问题。
• 工作原理：
  1. 你的设备在局域网内有一个私有IP（如 192.168.1.10）。
  2. 设备向公网上的STUN服务器发送一个请求：“从你的视角看，我是从哪里来的？”
  3. STUN服务器在回复中告诉你：“你的请求来自公网IP 203.0.113.1 的端口 55000。”
  4. 这个 203.0.113.1:55000 就是你在这个特定连接中的公网可访问地址（即ICE候选地址之一）。你将这个地址通过信令服务器告诉对方，对方就可以尝试向这个地址发送数据，建立直接连接。
• 关键点：它只进行一次性的地址发现和映射，后续的通信是点对点直接进行的，不再经过STUN服务器。它是免费的、轻量的，且不转发媒体数据。

2. TURN服务器

• 全称：使用中继穿越NAT。当所有直接连接（包括STUN发现的公网地址）尝试都失败时，它是最后的保证。
• 工作原理：
  1. 双方都无法直接连通，于是协商同意使用一个公网上的TURN服务器作为中继。
  2. 双方都与TURN服务器建立一个连接，并将自己的音视频流发送到TURN服务器。
  3. TURN服务器接收来自一方的数据，然后转发给另一方。
• 关键点：
  • 它是通信的中转站，所有数据都流经它，因此会消耗服务器的带宽和资源，通常需要付费或自行搭建。
  • 但数据仍然是加密的！TURN服务器转发的是WebRTC使用DTLS/SRTP加密后的数据包，它无法解密和窥探内容，确保了隐私性。

三、它们如何融入WebRTC连接流程？

WebRTC使用一个称为 ICE框架 的机制来自动选择最佳连接路径。STUN和TURN服务器是提供ICE候选地址的关键来源。

flowchart TD
    A[WebRTC连接开始] --> B

    subgraph B [ICE候选地址收集阶段]
        direction LR
        C[收集主机候选地址<br>（本地IP）]
        D[向STUN服务器查询<br>获取服务器反射候选地址]
        E[向TURN服务器申请<br>获取中继候选地址]
    end

    B --> F[通过信令服务器<br>交换所有候选地址列表]

    F --> G{ICE连接性检查<br>尝试按顺序连通}

    G --> H{成功?}
    H -- ✅ 是 --> I[选择最佳路径<br>（通常优先级：主机 > 反射 > 中继）]
    H -- ❌ 否 --> J[尝试列表中下一个候选地址对]
    J --> G

    I --> K[建立P2P连接<br>开始加密通信]

路径选择优先级：

1. 主机候选：双方在同一局域网内，直连最快。
2. 服务器反射候选：通过STUN发现，互联网直连，是最常见的成功模式。
3. 中继候选：通过TURN中转，是保证连接成功的最后方案。

四、重要总结与注意事项

你需要知道的：

1. 几乎每个WebRTC应用都需要它们：没有它们，大部分位于路由器或防火墙后的设备将无法建立连接。
2. 对于个人项目：你可以先使用谷歌等提供的免费公共STUN服务器（如 stun:stun.l.google.com:19302）进行测试。但对于TURN，由于资源消耗大，公共服务很少，产品上线时需要自己搭建或购买商业服务（如Twilio Network Traversal Service、Agora等）。
3. 安全须知：虽然TURN服务器中转数据，但WebRTC的端到端加密在数据离开你的设备前就已完成。TURN服务器就像邮局，负责递送一个上了锁的保险箱（加密数据），但它没有钥匙（加密密钥），所以无法看到箱内内容。

简单来说，STUN/TURN服务器是WebRTC连接得以成功的无名英雄。它们处理了网络底层的复杂性，让开发者可以专注于应用功能，让用户能享受一键即通的实时通信体验。