html WebRTC实时通信

2026-04-24 08:00:12 1517阅读 0评论

实时音视频在网页端的轻量实践：用HTML WebRTC搭建本地通话

在网页里做低延迟的音视频通信，最直接的方案就是用浏览器原生支持的 WebRTC。它让点对点通话、屏幕共享和实时数据传输变得简单而高效，不需要额外的中间服务器或复杂配置。这篇文章不走“正确废话”的路线，带你从零搭建一套轻量的本地通话能力，覆盖信令、本地媒体采集与传输、常见问题与优化路径，把能落地的点讲清楚。

一、场景与动机

想象一下，远程协作时需要同步演示代码、快速共享屏幕或现场语音沟通，期望的不是“能传”，而是“像面对面在聊”。WebRTC 通过直接在浏览器间建立 P2P 连接，提供了低时延、低带宽占用的实时通信基础，特别适合不需要长期留存记录、对延迟敏感的场景。

二、核心概念与准备

在开始编码前，先明确几个关键点：

Offer/Answer 机制：信令是双方交换的 SDP（Session Description Protocol）与 ICE（Interactive Connectivity Establishment）信息，用于协商媒体参数与网络路径。
getUserMedia：用于获取用户的音频与视频输入。
RTCPeerConnection：浏览器端创建的连接对象，管理媒体传输与 ICE。
iceCandidate 与 offer/answer：双方交替发送与响应的连接信息，用于完成 P2P 建立。

三、搭建轻量本地通话的步骤

1. 信令通道

信令不是 WebRTC 的一部分，但缺少它就无法建立连接。可用本地服务器、广播或简单 peer-to-peer 信令（如基于 WebSocket 的简版），此处以本地服务器为例：

// 信令服务（Node.js + Express 简化）
app.post('/signaling', (req, res) => {
  const { offer } = req.body;
  // 保存或广播 offer，双方交换 SDP
  // 这里用简单广播演示
  io.emit('offer', offer);
  res.sendStatus(200);
});

用服务端中转时，记得对 offer/answer 进行正确格式化与顺序处理。

2. 创建连接

在浏览器端初始化 RTCPeerConnection，并采集媒体：

const pc = new RTCPeerConnection();

navigator.mediaDevices.getUserMedia({ audio: true, video: true })
  .then(stream => {
    pc.addTrack(stream.getAudioTrack(), stream);
    pc.addTrack(stream.getVideoTrack(), stream);
  });

pc.onicecandidate = evt => {
  // 向服务端或其他端发送 ICE
  io.emit('ice', evt.candidate);
};

pc.ontrack = evt => {
  console.log('收到对方媒体', evt.track.kind);
};

在实际使用中，可按需只采集音频或视频，降低带宽占用。

3. 交换 SDP

当一方创建 offer 并发送给对方时，对方通过 answer 回复，双方交替交换 SDP 信息，以完成参数协商与连接建立。

4. 优化与容错

DTLS/SSL：在通话质量要求高时启用，但会增加带宽与延迟，需权衡。
ICE 优先路径：优先选择低延迟、高可用的候选，可用 pc.setLocalDescription 与候选筛选优化。
对等连接偏好：在某些网络环境（如NAT、对称/复杂NAT）下，使用 pc.setPreference 与 STUN/TURN 组合提升穿透与稳定性。