前言

最近在给一个仿B站项目加直播功能，技术选型阶段就碰到了一个很典型的问题：到底该用什么架构来做直播？

查了一圈资料，发现很多人张口就是“用WebRTC”，理由是延迟低、浏览器原生支持、不用装插件。听起来很美好对吧？

但仔细研究下去，发现事情没那么简单。这篇文章就把我技术选型的思考过程完整记录下来，重点讲清楚一个核心问题：为什么B站、抖音这种视频平台，直播架构都不是WebRTC P2P，而是服务端转发（SRS/Nginx-RTMP）？

一、两种直播架构的本质区别

先抛开技术名词，我们从底层的数据流向来理解这两种架构。

架构A：WebRTC P2P（点对点）

text

主播                   观众1
  │                     │
  ├──────── 视频流 ────→│
  │                     │
  ├──────── 视频流 ────→ 观众2
  │                     │
  ├──────── 视频流 ────→ 观众3
  │                     │
  └──────── 视频流 ────→ 观众100...

核心特点：主播直接把视频流发给每一个观众，有多少观众就发多少份。

架构B：服务端转发（SRS / SFU）

text

主播                    SRS服务器              观众1
  │                       │                     │
  └── 推1份流 ──────────→ ├──────── 复制分发 ──→│
                          ├──────── 复制分发 ──→ 观众2
                          ├──────── 复制分发 ──→ 观众3
                          └──────── 复制分发 ──→ 观众100...

核心特点：主播只推1份流到服务器，服务器负责复制和分发给所有观众。

二、算一笔带宽账，P2P就露馅了

我们做个简单的数学计算。

假设主播用1080P直播，视频码率大约 5 Mbps。

P2P模式下：

观众数量	主播需要上传的总带宽	家用宽带上行带宽（典型值）	结果
1人	5 Mbps	50 Mbps	✅ 没问题
5人	25 Mbps	50 Mbps	⚠️ 勉强
10人	50 Mbps	50 Mbps	❌ 已占满
50人	250 Mbps	50 Mbps	❌ 不可能
1000人	5000 Mbps	50 Mbps	❌ 想都别想

结论：家用宽带上行带宽通常只有20-50Mbps，P2P模式下撑死同时给5-10个人推流。观众再往上加，主播电脑的网络就直接炸了。

服务端转发模式下：

无论你有1个观众还是10000个观众，主播始终只上传 5 Mbps 的一路流。剩下的分发工作，全由部署在数据中心的SRS服务器完成，服务器的带宽是百兆、千兆甚至万兆级别的。

这就是为什么所有正经的视频直播平台，都不可能用P2P架构。

三、B站、抖音用的是什么？

B站和抖音的直播架构，本质上都是服务端转发，只是在具体实现上有各自的选择：

• 推流端（主播）：用OBS等专业软件，通过RTMP协议推到服务器。RTMP是Adobe搞的协议，虽然老了点，但极其稳定，兼容性好得离谱，所有推流工具都支持。

• 服务端（转发）：自研或基于SRS这类开源方案搭建的流媒体服务器集群。收到流之后，转成多种格式（FLV、HLS、WebRTC）分发给不同类型的观众。

• 播放端（观众）：

  • 大部分观众用 FLV 协议拉流，延迟2-3秒，体验流畅

  • iOS Safari用户用 HLS 协议，原生支持，不用装任何东西

  • 连麦场景用 WebRTC，延迟毫秒级，保证互动实时性

注意到了吗？WebRTC在B站只用于连麦这个特定场景，而不是用来做直播分发的主干。主干分发用的还是RTMP推流 + FLV/HLS拉流这套经典方案。

四、WebRTC P2P就没用了吗？

也不是。WebRTC P2P有它的适用场景：

• 视频通话：一对一或者小群组通话（腾讯会议、Zoom）。人数少，P2P完全够用。

• 连麦互动：主播和特定观众之间需要极低延迟的音视频交互。B站的连麦功能就是基于WebRTC做的。

• 小规模测试：开发阶段快速验证推拉流链路是否通畅。

但一旦场景变成“一对多直播分发”，P2P的带宽模型就完全不够看了。

五、我的技术选型

搞清楚这些之后，我的选择就很明确了：

环节	选型	原因
主播推流	RTMP（OBS推流）	稳定、兼容性好、所有推流工具都支持
服务端	SRS	开源、高性能、支持RTMP转FLV/HLS/WebRTC
观众拉流	FLV（flv.js）	延迟低（2-3秒）、浏览器播放方便
实时消息	WebSocket	弹幕、礼物、房间控制等业务逻辑

这个架构画成图就是：

text

OBS (RTMP推流) 
        │
        ↓
  SRS 流媒体服务器
   ├── 转 HTTP-FLV ──→ flv.js 播放（Web观众）
   ├── 转 HLS ──────→ 移动端/Safari播放
   └── 转 WebRTC ───→ 连麦场景
        │
        ↓
  WebSocket 信令服务（弹幕/礼物/房间管理）

六、为什么SRS是你绕不开的选择

简单来说，SRS（Simple Realtime Server）是目前开源社区最成熟、最活跃的流媒体服务器，它帮你搞定了直播中最难的那部分：

1. 协议转换：RTMP进去，FLV/HLS/WebRTC出来，一条龙

2. 高并发：单机就能撑几万并发，还可以组集群

3. 低延迟：RTMP转FLV延迟可以控制在3秒以内

4. 运维友好：有Docker镜像，有管理后台，部署简单

你当然也可以用Nginx-RTMP模块，但那个项目已经多年不更新了，功能远不如SRS完善。

总结

技术选型这事，最怕的就是跟风用流行技术，而不去理解背后的适用场景。

WebRTC是好技术，但它解决的是“低延迟音视频通话”的问题，不是“一对多直播分发”的问题。你非要拿螺丝刀去钉钉子，结果只能是费力不讨好。

如果你的项目需要做直播功能，记住这个公式就够了：

RTMP推流 + SRS转发 + FLV拉流 + WebSocket信令

这套组合已经被B站、斗鱼、虎牙无数平台验证过，是最务实、最可靠的选择。

---

下一篇预告：选型定了之后，我开始动手搭建SRS+浏览器推流的Demo，结果遇到了一个诡异的Bug——码率明明设置了4Mbps，SRS后台却显示只有100多kbps。踩了一整天的坑才找到根因，下一篇详细记录排查过程。