用 HTML + WebRTC 做直播模块

用 HTML + WebRTC 做直播模块：架构原理、依赖与整体流程

1. WebRTC 直播到底在干什么？

WebRTC 的核心是：浏览器到浏览器（或浏览器到服务器）的实时音视频传输。
它不是传统 RTMP/HTTP-FLV 那种“推到媒体服务器再分发”的协议栈，而是：

• 采集：getUserMedia() 拿到摄像头/麦克风
• 编码与传输：RTCPeerConnection 内部完成（浏览器实现）
• 连接建立：靠 信令（Signaling） 交换 SDP/ICE 信息
• 穿透 NAT：靠 ICE + STUN/TURN

你要做“直播模块”，最常见的两种架构：

纯 WebRTC P2P

• 主播浏览器 ↔ 多个观众浏览器：每个观众一条 PeerConnection
• 优点：实现简单、延迟低
• 缺点：主播上行带宽会爆炸（观众越多，主播发得越多）

---

2. WebRTC 必须的三件事：SDP、ICE、信令

2.1 SDP 是什么？

SDP（Session Description Protocol）就是“我能发什么、怎么发”的描述，包含：

• 编码：VP8/VP9/H264、OPUS
• 媒体流信息：audio/video
• 传输参数

在 WebRTC 中，SDP 被包在：

• Offer（发起方的连接提议）
• Answer（接收方的回应）

2.2 ICE 是什么？

ICE（Interactive Connectivity Establishment）是“找到一条能通的网络路径”的机制。

• STUN：帮你发现公网映射地址（大多数家用网络可用）
• TURN：当 P2P 直连失败时“中继转发”（公司网/对称 NAT 常见）

2.3 信令是什么？为什么 WebRTC 不自带？

WebRTC 只负责 媒体传输，但 Offer/Answer/ICE 这些信息得“先交换”，于是你需要一个 信令通道：

• WebSocket（最常见）
• HTTP 轮询
• Socket.IO

信令服务器的职责非常简单：

转发消息（Offer/Answer/ICE/Join/Leave），不碰音视频数据。

---

3. 推流 vs 拉流：在 WebRTC 里怎么理解？

在传统直播：

• 推流：主播推到服务器（RTMP）
• 拉流：观众从服务器拉（HTTP-FLV/HLS）

在 WebRTC（P2P）：

• 推流端 = 采集本地媒体并 addTrack() 发给对端
• 拉流端 = 通过 ontrack 收到远端媒体流并播放

换句话说：

• 推流就是“把轨道塞进 PeerConnection”
• 拉流就是“接收轨道并播放”

---

4. 依赖与运行环境

4.1 前端

• 纯 HTML + JS（不依赖框架也能做）
• API：getUserMedia、RTCPeerConnection、RTCSessionDescription、RTCIceCandidate

4.2 后端（信令服务器）

• Node.js（最简单）
• WebSocket 库：ws

安装：

mkdir webrtc-live && cd webrtc-live
npm init -y
npm i ws express

4.3 为什么必须 HTTPS/localhost？

浏览器对摄像头/麦克风权限要求：

• 必须是 https 或 localhost
• 直接 file:// 打开会失败（很多浏览器不允许）

开发阶段推荐：

• 本机 http://localhost（可用）
• 局域网访问最好配自签 https（后面我第 3 篇会给你给出建议）

---

5. 整体流程

以“主播 A + 观众 B”为例：

1. B 进入房间：通知服务器 “join room”
2. 服务器通知 A：有观众加入
3. A 创建 Offer（包含自己的音视频能力）发给 B
4. B 设置 remote description，创建 Answer 回给 A
5. 双方持续交换 ICE Candidate
6. 连接建立后：
   • A 的 localStream 通过 PeerConnection 发给 B
   • B 的 ontrack 接收播放