WebRTC 直播推流实战：从零搭建低延迟直播系统

为什么选择 WebRTC？

在直播技术选型中，延迟是核心指标之一。传统的 RTMP + HLS 方案延迟通常在 3-10 秒，而 WebRTC 可以将端到端延迟控制在 500ms 以内。

WebRTC 的核心优势

• 超低延迟：基于 UDP，无需等待 TCP 重传
• 浏览器原生支持：无需安装插件
• NAT 穿透：内置 ICE/STUN/TURN 机制
• 自适应码率：根据网络状况动态调整

架构设计

一个典型的 WebRTC 直播系统包含以下组件：

推流端 → 信令服务器 → SFU → 信令服务器 → 拉流端
  │                      │
  └── ICE/STUN/TURN ─────┘

1. 信令服务器

信令服务器负责交换 SDP 和 ICE Candidate 信息。我们使用 WebSocket 作为传输协议：

// 推流端：创建 PeerConnection 并发送 Offer
const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});

const stream = await navigator.mediaDevices.getUserMedia({
  video: { width: 1280, height: 720 },
  audio: true
});

stream.getTracks().forEach(track => pc.addTrack(track, stream));

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// 通过 WebSocket 发送到信令服务器
ws.send(JSON.stringify({
  type: 'offer',
  sdp: pc.localDescription
}));

2. SFU（Selective Forwarding Unit）

SFU 是 WebRTC 直播的核心，负责将媒体流转发给多个观众。推荐使用 mediasoup 或 LiveKit。

SFU 不会解码/重编码媒体流，只做转发。这使得一台 4C8G 的服务器可以承载 数百路 并发观看。

NACK 重传机制

WebRTC 使用 RTCP 的 NACK（Negative Acknowledgement）包来请求丢失的数据包重传：

• 接收端检测到 RTP 包序列号不连续
• 发送 RTCP NACK 包给发送端
• 发送端在重传缓冲区查找对应包并重传

// 监听丢包统计
pc.getStats().then(stats => {
  stats.forEach(report => {
    if (report.type === 'inbound-rtp' && report.kind === 'video') {
      console.log(丢包率: ${report.packetsLost / report.packetsReceived * 100}%);
    }
  });
});

小结

WebRTC 直播方案的核心在于 SFU 架构 + 信令优化 + NACK 重传。下一篇文章我们将深入探讨如何优化 Simulcast 以适配不同带宽的观众。

---

如果你对 WebRTC 直播有任何疑问，欢迎在评论区交流！