1. 为什么选择WebRTC构建直播平台？

去年我在帮一个教育机构搭建在线互动课堂时，首次深度使用了WebRTC技术。当时我们需要在300ms内完成师生间的音视频传输，而传统RTMP方案仅握手就需要500ms。WebRTC的P2P特性让我们在局域网环境下实现了端到端延迟稳定在150ms以内——这个数字让所有尝试过直播开发的工程师都会眼前一亮。

WebRTC（Web Real-Time Communication）本质上是浏览器间的实时通信协议栈，它包含三大核心技术模块：

• 媒体捕获与编码 ：通过getUserMedia API获取摄像头/麦克风数据，支持H.264/VP8视频编码和Opus音频编码
• 网络传输 ：基于ICE/STUN/TURN实现NAT穿透，采用SRTP协议加密传输
• 信令控制 ：使用SDP（会话描述协议）协商媒体参数，通过信令服务器交换ICE候选地址

相比传统直播方案，WebRTC的优势在于：

1. 零插件依赖 ：现代浏览器原生支持，用户无需安装任何插件
2. 超低延迟 ：端到端延迟可控制在200ms以内，是RTMP方案的1/5
3. 自适应网络 ：支持动态调整码率和FEC（前向纠错），在30%丢包率下仍可维持通话
4. 全平台覆盖 ：iOS/Android/PC浏览器通用一套技术栈

2. 基础架构设计与核心组件选型

2.1 最小可行架构设计

一个基础的WebRTC直播平台包含以下组件：

[信令服务器] ← WebSocket → [主播浏览器]
       ↑                      |
       |                    [P2P/TURN]
       ↓                      |
[观看端浏览器] ← WebRTC → [观看端浏览器]

我推荐使用Node.js搭建信令服务器，代码量不超过200行即可实现基础功能。以下是用ws库创建信令服务器的核心代码片段：

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  ws.on('message', (message) => {
    // 广播信令消息给所有客户端
    wss.clients.forEach(client => {
      if (client !== ws && client.readyState === WebSocket.OPEN) {
        client.send(message);
      }
    });
  });
});

2.2 关键协议与API详解

SDP协商过程 是WebRTC最复杂的部分。当主播调用 createOffer() 时，会生成如下SDP片段：

v=0
o=- 761421927439352841 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111 103
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
m=video 9 UDP/TLS/RTP/SAVPF 100 101
a=rtpmap:100 VP8/90000
a=rtpmap:101 H264/90000

这个SDP描述了：

• 使用UDP传输，加密方式为TLS+SRTP
• 音频支持Opus和ISAC编码
• 视频支持VP8和H.264编码
• 媒体流通过BUNDLE策略复用同一端口

实际开发中常见坑点：Chrome和Firefox的SDP格式存在差异，需要做标准化处理。建议使用adapter.js库解决兼容性问题。

3. 实战：从零搭建直播推流端

3.1 媒体采集与参数配置

主播端需要处理的关键步骤：

// 获取媒体流
navigator.mediaDevices.getUserMedia({
  audio: {
    echoCancellation: true,
    noiseSuppression: true,
    sampleRate: 48000
  },
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    frameRate: { ideal: 30 }
  }
}).then(stream => {
  localVideo.srcObject = stream;
  
  // 创建PeerConnection
  const pc = new RTCPeerConnection({
    iceServers: [{ 
      urls: [
        'stun:stun.l.google.com:19302',
        'turn:your_turn_server.com?transport=udp'
      ],
      credential: 'turn_password',
      username: 'turn_username'
    }]
  });
  
  // 添加媒体轨道
  stream.getTracks().forEach(track => {
    pc.addTrack(track, stream);
  });
});

关键参数优化建议 ：

• 教育类直播：优先Opus音频(48kHz)+VP8视频(720p@15fps)
• 游戏直播：推荐Opus+H.264(1080p@60fps)
• 移动端适配：使用 deviceorientation 事件动态调整视频方向

3.2 信令交互流程实现

完整的信令交互时序如下：

1. 主播创建offer → 通过信令服务器转发
2. 观众收到offer → 创建answer → 回传主播
3. 双方交换ICE候选地址
4. 建立P2P连接后开始媒体传输

处理ICE候选的核心代码：

pc.onicecandidate = event => {
  if (event.candidate) {
    signalingSocket.send(JSON.stringify({
      type: 'candidate',
      candidate: event.candidate
    }));
  }
};

// 接收远端候选
signalingSocket.on('candidate', candidate => {
  pc.addIceCandidate(new RTCIceCandidate(candidate));
});

4. 大规模观看方案优化

当观众超过50人时，P2P模式会导致主播上行带宽爆炸（每人消耗约1Mbps）。这时需要引入 SFU架构 （Selective Forwarding Unit）：

[主播] → [SFU服务器] → [观众1]
                 ↘→ [观众2]
                 ↘→ [观众3]

推荐使用开源的mediasoup实现SFU，其核心优势：

• 单节点支持500+并发观看
• 支持Simulcast（动态切换1080p/720p/360p）
• 支持SVC（可伸缩视频编码）

配置示例：

const mediaCodecs = [
  {
    kind: 'audio',
    mimeType: 'audio/opus',
    clockRate: 48000,
    channels: 2
  },
  {
    kind: 'video',
    mimeType: 'video/VP8',
    clockRate: 90000,
    parameters: {
      'x-google-start-bitrate': 1000
    }
  }
];

const worker = await mediasoup.createWorker();
const router = await worker.createRouter({ mediaCodecs });

5. 常见问题排查手册

5.1 媒体无法显示问题排查流程

1. 检查 getUserMedia 是否被授权
2. 验证SDP中是否包含有效媒体行（m=audio/video）
3. 使用 chrome://webrtc-internals 查看ICE连接状态
4. 检查TURN服务器是否正常工作（通过 about:webrtc ）

5.2 高延迟问题优化

• 关闭 googCpuOveruseDetection （Chrome特有参数）

const pc = new RTCPeerConnection({
  optional: [{
    googCpuOveruseDetection: false
  }]
});

• 调整视频编码预设：

const sender = pc.getSenders().find(s => s.track.kind === 'video');
await sender.setParameters({
  ...sender.getParameters(),
  encodings: [{
    maxBitrate: 2500000,
    priority: 'high',
    scaleResolutionDownBy: 1.0
  }]
});

5.3 移动端特殊处理

iOS Safari有两个关键限制：

1. 必须在用户手势事件中触发 getUserMedia
2. 视频元素必须设置 playsinline 属性

<video autoplay playsinline muted></video>

6. 进阶：WebRTC与CDN的融合方案

对于万人级直播，推荐使用 WHIP协议 将WebRTC流转为RTMP推送到CDN。具体实现：

1. 在SFU输出端配置RTMP转推

ffmpeg -i rtmp://localhost/live/stream -c copy -f flv rtmp://cdn_server/app/stream

2. 使用低延迟HLS(LL-HLS)或DASH分发：

#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.0
#EXT-X-PART-INF:PART-TARGET=0.33334
#EXTINF:2.0000,
fileSequence1.mp4
#EXT-X-PART:DURATION=0.33334,URI=filePart1.mp4

实测数据对比：

• 纯WebRTC SFU：延迟200-500ms，成本$0.02/用户小时
• WebRTC+CDN：延迟1-3s，成本$0.005/用户小时

我在实际项目中发现，混合方案能在保证<1s延迟的同时，将带宽成本降低60%。特别是在东南亚等网络环境复杂的地区，CDN边缘节点的稳定性显著优于纯P2P传输。