WebRTC：实现私有化会议直播系统

如果你已经能照着示例跑通一个 WebRTC 的 1v1 通话，但一到「多人会议」就卡壳——谁跟谁连、流怎么转发、晚进来的人怎么收到画面、谁在说话怎么知道——那这门课补的正是这一段。它不教你怎么写第一个 RTCPeerConnection，而是把「私有化会议 + 直播」这套系统怎么搭出来讲清楚。

先说清楚：这门课不解决什么

它不是 WebRTC 入门课。信令、SDP、ICE、STUN/TURN 这些概念，默认你已经知道大概，或者至少愿意自己补。课程真正花力气的地方在架构决策：什么时候用 Mesh，什么时候必须上 SFU，直播场景又该怎么把会议流分发给不在会议里的人。如果你指望看完全程就懂 NAT 穿透原理，那会失望；但如果你卡在「能连两个人，连不了五个人」，这门的针对性很强。

三种架构，对应三种真实需求

课程围绕三种架构展开，这个划分本身就是能力缺口的地图：

• 简易架构：点对点或小规模多对多。适合先建立信心，搞清楚多路流的建立与关闭时机，以及人数一多带宽怎么崩。这里最容易踩的坑是以为 Mesh 能撑住十个人。
• 多对多架构：需要感知用户网络状况、通话质量，还要支持会议云录制。这一段开始涉及媒体服务器转发、质量指标采集、录制流的落盘或上云，是从「能通话」到「能运维」的分水岭。
• 直播架构：会议进行中把某些人的画面推给外部观众。这里要处理的是单向分发、延迟容忍度、观众端不需要回传媒体流这些约束，和会议内部的逻辑并不一样。

把这三条线放在一起，你会更容易理解为什么「会议直播系统」不能只当成一个加了大厅的通话应用。

私有化这件事，难在哪

公有云会议服务要么不支持私有化部署，要么报价劝退，这是很多团队自己动手的直接原因。但私有化不只是「把服务器放内网」：媒体服务器要自己运维，TURN 要自己扛流量，录制文件要自己管存储和权限，信令和业务系统还得对接。课程会把这些环节串起来讲，你需要带着「这套东西上线后谁来维护」的问题去看，而不只是跟着敲完 demo。

看完应该能回答的问题

• 五个人开会的 Mesh 方案，为什么到第七个人就开始卡，瓶颈在带宽还是 CPU？
• 用 SFU 转发时，上行和下行分别由谁承担，房间人数上限受什么限制？
• 会议里怎么拿到每个参与者的丢包、抖动、往返时延，并据此判断「他那边网络不好」？
• 云录制录的是哪一路流，录制端需不需要是会议成员？
• 把会议画面直播出去，观众端和会议成员端在协议选择上有什么不同？
• 整套私有化部署里，哪些组件必须公网可达，哪些可以只在内网？

如果这些问题你现在答不上来，边看边把答案写下来，比单纯跑通代码有用得多。配套练习建议不要只照抄，改一改参数——把房间人数调到你自己场景的上限，看它什么时候撑不住，这个「撑不住的点」就是你要补的下一块知识。

适合谁，看之前先做什么

适合已经写过基础音视频采集与信令交互、准备把它做成能多人用的系统的开发者，或者要评估「自研会议值不值」的技术负责人。看之前，先把浏览器端 getUserMedia 和 RTCPeerConnection 的最小流程亲手跑一遍，否则课程里关于协商和重连的部分会跟不上。这门课的价值在于架构取舍和工程细节，前提是你得先有那块能比较的底子。