去年到今年，后台被问得最多的一个技术问题就是 WebRTC企业直播能不能扛住万人级并发。有人是被供应商的方案书吓到了，有人是自己搭了一套小规模的觉得挺香、想直接往上堆。我从收到的几十条留言里挑了七封有代表性的，一封封回。不讲教科书定义，只说我们在真实项目里踩过的坑和算过的账。
回信人是我，摄行科技技术方案组的老周，干这行第九年。以下数据都来自我们经手的项目，具体客户名字就不点了。
第一封：某制造业IT负责人，问"三千人内部大会能不能上"
原话是："我们年底有个三千人的全员大会，供应商推荐 WebRTC，说延迟能做到三百毫秒，靠谱吗？"
靠谱，但你得问清楚他打算怎么部署。三千人在一个 SFU 节点上是撑不住的。我们实测过一台 32 核 64G 的云主机跑 SFU 转发，纯下行、720p、2Mbps 码率，稳定承载大约在四百二十到四百八十路之间。再往上推，CPU 占用会先冲到九成，然后开始出现丢包重传，画面就开始糊了。
三千人意味着你至少要七到八个转发节点做级联，还要一层调度。这套东西不是不能建，是建起来之后你得有人运维。我通常会反问客户一句：这场会一年开几次？如果答案是一次，那这笔基础设施投入怎么摊都不划算。
第二封：某券商，问"为什么我们测的时候好好的"
这位朋友在办公室里拉了三十个同事测试，效果拔群，正式那天崩了。
原因很朴素：办公室里三十个人走的是同一条内网出口，实际只有一路上行、三十路本地分发；正式那天三千人分布在全国四十多个城市，网络质量参差不齐。WebRTC企业直播的资源消耗跟"人数"关系没那么大，跟"连接数×网络劣化程度"关系极大。弱网用户会触发大量的重传和码率协商，一个丢包率百分之八的用户，对服务器的负担相当于三到四个正常用户。
我们给客户做压测的时候，会强制把百分之二十的模拟连接设成弱网。这个比例是从摄行科技过去两年一百多场活动的日志里统计出来的中位数。关于弱网这件事本身怎么兜底，弱网环境下直播如何保底那篇讲了链路侧的做法，可以配着看。
第三封：某教育机构，问"SFU和MCU到底选哪个"
简单说，SFU 是"我只负责转发，你自己解码"，MCU 是"我把所有画面合成一路给你"。
WebRTC企业直播里，绝大多数场景选 SFU，因为它不解码不编码，服务器压力小得多，延迟也低。MCU 的价值在于观看端设备烂、或者要出一路标准信号给别的系统。我们做过一个项目，客户要把直播画面同时送进内部的会议室大屏系统，那套系统只认 SDI，那就得在末端加一层合成，本质上就是局部 MCU。
有个反常识的点：很多人以为 SFU 更省钱。在几百人规模确实是，但到了万人级，SFU 的带宽账会变得很难看——因为它是一对一转发，一万人就是一万路下行。这时候反而是"WebRTC 做前端互动区、CDN 做大规模分发"的混合方案更省。摄行科技现在给万人以上活动出方案，默认就是这个混合结构。
第四封：某快消品牌市场部，问"我们只想要低延迟互动"
这位说得很实在："我不关心技术，我就要观众点了抽奖按钮之后三秒内出结果。"
那你要的其实不是 WebRTC 全链路，是"低延迟互动通道"。画面走普通的低延迟 HLS 或者 SRT，延迟三到五秒完全够用；抽奖、投票、连麦这些交互走单独的长连接。这样成本能砍掉一大半，体验上观众基本感知不到差别。
我见过不少甲方被"全链路 WebRTC"这个词绕进去，最后为了三秒延迟多付了六位数。真正需要亚秒级的场景其实很窄：远程互动教学、需要实时对话的连麦访谈、竞拍。别的场合，把钱花在画面质量和保障冗余上回报更高。
第五封：某政务单位，问"能不能私有化"
能，而且这类客户我们做得最多。WebRTC企业直播的私有化部署难点不在信令服务器，在 TURN 中继。
内网环境里，客户的防火墙策略通常只放行几个固定端口，而 WebRTC 默认要用一大段 UDP 端口范围做媒体传输。我们的常规做法是把媒体端口收敛到单端口复用，再配合 TCP 兜底。有一次在某地的单位机房，安全组死活不肯开 UDP，最后全走 TCP 中继，延迟从两百八十毫秒涨到了六百多，但至少通了。
私有化的整体取舍逻辑，私有化部署直播系统的取舍那篇里有更完整的决策路径。协议层面的实现细节，可以直接翻 IETF 发布的相关标准文档，IETF官网上 RTCWEB 工作组的材料是最权威的一手来源；浏览器侧的接口定义则以W3C公布的规范为准，前端同学对接前建议先过一遍。
第六封：某会展公司，问"服务器要准备多少台"
这个问题得倒着算。先定并发峰值，再定单节点承载，再乘一个冗余系数。
我们内部用的经验值：单节点按实测承载的百分之七十封顶（不要跑满），冗余系数取一点四。假设你要撑五千人纯观看、单节点实测四百五十路，那实际可用是三百一十五路，需要十六个节点，乘一点四是二十三个节点。听着很多？所以我上面才说万人级别不要硬扛纯 WebRTC。
顺便提醒一句，节点数量只是账单的一半，另一半是带宽。五千人 2Mbps 就是 10Gbps 的下行峰值，这个数字按公有云的按量计费能吓死人。
第七封：某能源集团，问"崩了怎么办"
这是七个问题里我最愿意回答的一个，因为它说明提问的人真的在做事。
我们的标准答案是三层降级：媒体节点故障自动切备用节点，观众端感知为一到两秒卡顿；整个 WebRTC 集群不可用，自动降级到 CDN 直播地址，延迟从零点三秒变成六秒，但画面不断；全网络异常，推备用的低码率流并弹出提示。这套降级路径必须在彩排时真跑一遍，不能只写在文档里。摄行科技的验收流程里有一条硬规定：没做过降级演练的项目不允许上线。彩排到底要跑哪些内容，直播彩排到底在彩排什么里列了完整的检查表。
写在最后：三个数字帮你做决定
回完这七封信，我把判断标准压缩成三个数字，你可以直接拿去用。
并发在八百以内、要求亚秒级互动，纯 WebRTC 划算。并发八百到三千，看预算和场次频率，混合方案更稳。并发超过三千，老老实实让 CDN 承担分发，WebRTC 只留给需要互动的那一小撮人。
至于万人并发这个原始问题的答案：技术上做得到，工程上很少值得。真正扛住万人的项目，我经手的那几个无一例外都是混合架构，没有一个是纯 WebRTC 硬顶上去的。有想法的项目可以把人数、场次、预算区间发过来，摄行科技这边可以出一版对比测算，把纯 WebRTC、混合、纯 CDN 三种方案的成本摆在一张表上给你看，咨询和初步测算都不收费。多路信号怎么在一场活动里统一调度，直播中台：一场活动多路信号的调度那篇也值得一读。
#摄行科技
