2026 服务器租用实时音视频 SFU 怎么配：mediasoup 与 Janus 的端口、带宽与转发六维对比 + 避坑避雷手册

2026 服务器租用实时音视频 SFU 怎么配：mediasoup 与 Janus 的端口、带宽与转发六维对比 + 避坑避雷手册

把多方实时音视频搬到自己租的服务器上，第一件事不是挑 CPU 型号，而是想清楚媒体流该怎么走。视频会议、在线课堂、主播连麦、远程协作这类场景，服务端架构的差别不在"快不快"，而在"谁为每一个新增参与者付出代价"。Mesh 让每个终端自己扛上行，MCU 让服务器扛编解码，SFU 让服务器扛网络吞吐。三条路的成本曲线完全不同，选错拓扑，加多少台机器都补不回来。本文按这条线索展开：拓扑差异、SFU 的 CPU 去向、带宽账的算、UDP 端口与 TURN 的现实、simulcast 与 SVC 的取舍、mediasoup 与 Janus 的工程差别、多机扩展的两条路、延迟构成，以及落到租用服务器上该怎么判断资源与节点。

先分清三种拓扑：Mesh、MCU、SFU 到底差在哪

Mesh（网状）是所有人两两直连。一个 N 方房间里，每个终端要维持 N-1 路上行、N-1 路下行。上行带宽与编码 CPU 都随房间人数线性增长——1 对 1 很轻松，4 人还能撑，到了 8 人，多数手机和家庭宽带的上行就先崩了。Mesh 的好处是路径最短、服务器不碰媒体、没有二次编码损失，代价是规模化能力几乎为零。

MCU（多点控制单元）把所有人的流收上来，解码、混音混画、再编码成一路合成画面，发回给每个人。终端上行 1 路、下行 1 路，对弱终端最友好。代价全部堆在服务器：N 方会议要做 N 次解码加 N 次编码（以及混音），CPU 随人数线性增长且系数很大；二次编码必然带来画质损失和一个编解码周期的延迟；接收端看到的画面布局由服务器决定，客户端没法自由排版、没法单独放大某个人的画面。

SFU（选择性转发单元）只转发不解码。终端上行 1 路、下行 N-1 路，接收端自己解码和排版。服务器对每一个 RTP 包做的事是：判断该发给哪些下游、按需改写 RTP 头与 SSRC、做 SRTP 加解密、跑带宽估计与拥塞控制、处理重传请求与关键帧请求、在 simulcast 场景里挑选合适的层。它不碰像素，吃的是网络吞吐与 PPS。

SFU 成为主流不是因为它最省，而是因为它把成本转移到了最便宜、最容易水平扩展的那一项——带宽。编解码 CPU 贵且难扩展，带宽便宜且加机器就能加。下面的对比表按工程上真正会遇到的维度拆开。

SFU 的 CPU 到底花在哪：转发、加解密与拥塞控制

一个常见误解是"SFU 要处理视频，所以 CPU 要高"。这个判断对 MCU 成立，对纯转发的 SFU 不成立。SFU 不解码、不编码、不缩放画面（除非你额外做录制转码、混流或截图），它的 CPU 开销集中在以下几处。

包转发与扇出复制。每个 RTP 包进来，要查路由表确定它该被转发给哪些下游传输通道，然后把同一份数据复制 N-1 份发出去。房间越大，扇出系数越高，同一个包的复制成本越高。这部分是内存带宽与拷贝开销，不是浮点运算。

DTLS 与 SRTP 加解密。每一路传输通道有独立的密钥材料，收包要解密校验、发包要加密封装。单包开销不大，但它乘以 PPS 之后就是实打实的 CPU 占用。小包高频是这个业务的天然特征，所以"每包开销乘 PPS"是估算 CPU 的正确思路，而不是"每个房间多少核"。

拥塞控制与带宽估计。服务器要基于 RTCP 反馈机制估算每个接收端的可用带宽，据此决定转发哪一层、要不要降码率。估算做得保守会浪费画质，做得激进会造成拥塞与丢包。这部分是算法开销，房间数越多、接收端越多，计算量越大。

丢包处理与缓冲。NACK 重传需要维护已发包的缓存，关键帧请求（PLI/FIR）要向发送端转发请求，还要做包序重排与时间戳处理。缓存开多大、保留多久，直接影响内存占用与重传命中率。

协议栈与调度。ICE 连通性检查、DTLS 握手、信令通道、定时器与事件循环。握手属于短时尖峰，大量用户同时加入房间时会形成 CPU 突刺，这一点在小机器上容易被忽略。

结论很清楚：SFU 的 CPU 曲线相对平缓，带宽曲线陡峭。所以配置服务器时先看网卡与出口带宽，再看 CPU 核数与单核性能，再往后才轮到内存和磁盘。

带宽账自己算一遍：一路视频、一个房间、一台服务器

先给一个量级概念而不是精确数字：一路 720p 视频的码率常见在几百 kbps 到 2 Mbps 量级，具体随分辨率、帧率、编码器（VP8、VP9、H.264、AV1）和画面复杂度变化；静态讲课画面和快速运动的游戏画面，同样的设置能差出好几倍。音频一路通常在几十 kbps 量级，占比不大但不能忽略。

一个房间的出向带宽可以这么算：服务器出向 ≈ 每路上行码率 ×（N-1）× 参与人数。因为房间里每个人都要收到其他 N-1 个人的流，服务器要把每一路都复制 N-1 份发出去。入向则简单得多：入向 ≈ 每路上行码率 × 参与人数。

做一次示例演算（以下为典型部署思路下的量级估算，并非特指某一真实客户或在真实环境中量出的结果）：8 人房间，按每路上行 1 Mbps 这个量级估算，服务器入向约 8 Mbps，出向约 1 × 7 × 8 = 56 Mbps。12 人房间同样口径下是 1 × 11 × 12 ≈ 132 Mbps。30 人房间若全员开摄像头，量级会逼近 870 Mbps——这个数字说明了一件事：大房间不能靠"大家都开着摄像头"硬扛，必须在产品层限制同时开视频的人数，或者让弱网端只收低层。

由这条公式能推出三个采购要点。第一，SFU 的出向是真金白银的公网带宽，出向通常远大于入向，谈带宽时盯住出向口径。第二，要按峰值算而不是按平均值算：晚间上课高峰、白天会议高峰的并发房间数是平均值的数倍，带宽要留 30% 到 50% 的余量。第三，计费方式在这类业务上差别巨大：按流量计费时，成本随房间数、人数和时长线性增长且几乎不可预测，一个爆款房间就能吃掉整月预算；而固定端口速率（比如 100M、1G 端口不限流量）把问题变成容量规划——打满就扩容，成本可预期。签约前必须问清：给的是端口速率还是月流量包，出向是否单独计价，超出之后是限速还是按量计费。

UDP 端口范围与 ICE 候选：SFU 到底要在防火墙上开什么

WebRTC 的媒体默认跑在 UDP 上的 SRTP。这意味着服务器必须开放一段 UDP 端口区间供媒体使用：mediasoup 在 Worker 层面有 rtcMinPort / rtcMaxPort 这类端口区间配置，Janus 也有对应的媒体端口范围配置。每一路媒体传输通道会从这段区间里占用端口，具体每个通道占几个端口取决于实现与配置（是否启用 RTCP 复用等），不要想当然。

安全组或机房防火墙只放行 TCP 是最常见的部署事故：信令通了、房间进去了，媒体流死活建不起来。反过来，端口区间设得太小，症状也很隐蔽——并发房间数一上去，新用户加入就报资源不足或建连失败，而这类报错和"带宽打满"长得非常像，很容易误判成带宽问题去加带宽。

估算端口区间要用这个口径：并发房间数 × 每房间人数 × 每通道端口占用系数 + 余量。小房间多、大房间少的业务，和少量超大房间的业务，算出来的区间大小完全不同。宁可一开始就开大一点，端口是本地资源，占用本身不花钱。

ICE 候选分三类，理解它们才能判断流量到底走哪条路。host 候选是客户端本机的地址；srflx 候选是客户端通过 STUN 服务器反射出来的公网地址（IP 加端口）；relay 候选是通过 TURN 服务器中转的地址。ICE 会收集所有候选、按优先级排序并做连通性检查，能直连就直连，直连失败才降级到 relay。所以"是不是走了中继"这件事，要在客户端的候选统计里看，而不是凭感觉猜。

服务器上还要部署 STUN 能力（很多 SFU 实现自带 STUN 处理，也可以单独部署）。STUN 本身只做地址反射，流量很小；真正吃带宽的是 TURN。

什么时候非上 TURN 不可：对称 NAT、企业防火墙与回落的代价

直连失败的主力场景有三类。一是对称型 NAT：客户端对不同目标地址会映射出不同的公网端口，STUN 反射出来的候选只对 STUN 服务器有效，SFU 拿这个地址发包根本到不了，直连必然失败。二是企业与校园防火墙：出向只放行 TCP 80 和 443，UDP 全部丢弃。三是运营商级 NAT 与移动网络切换，映射关系不稳定，候选刚建好就失效。

这三类场景下 TURN 是唯一解，不是可选项。而 TURN 一开，成本结构立刻改变：媒体双向都从服务器过，同一份流量在服务器上要多走一趟甚至两趟，出向带宽直接翻倍量级地增长。此时机房出口位置与带宽单价就成了核心变量，比 CPU 选型重要得多。

还有一层是 TLS 伪装。有些网络不仅封 UDP，还对出向流量做识别，只允许看起来像 HTTPS 的流量出去。这时要部署 TURN over TLS 走 443 端口，把媒体流封装进 TLS 里，从防火墙视角看就是普通 HTTPS 会话。代价是额外的封装开销、TLS 握手时间，以及服务器上 443 端口被媒体占用后与 Web 服务的端口协调问题。

要澄清一个常见期望：TCP 443 不是万能兜底。UDP 被封时确实可以回落到 TURN over TCP 或 TLS，但 TCP 的队头阻塞特性会让丢包场景下的延迟显著恶化——一个包丢了，后面的包都要等它重传。用户的主观感受就是"连得上但很卡"。回落是保底方案，不是性能优化方案。

TURN 与 SFU 是否同机部署的取舍：同机省一跳、省一次跨机带宽、鉴权与运维都简单，适合起步与中小规模；缺点是故障域重合，而且 TURN 与 SFU 的出向带宽叠加在同一张网卡、同一个端口上限上，扩容时两者容量被绑死。分机部署的好处是 TURN 可以单独多点部署、按用户地理位置就近接入，SFU 按房间分片，两者独立扩容；代价是每多一跳就多一份延迟与带宽成本，还要处理 TURN 与 SFU 之间的凭证体系（时间受限的临时凭证）、流量分开统计与分开计费的问题。规模没上来之前不要提前拆分，规模上来之后不要拖着不拆。

simulcast 与 SVC：让服务器挑层，代价由发送端承担

同一个房间里，有人用千兆宽带，有人在地铁上用 4G。如果服务器只为每个发送端保留一路码流，那么为了保证弱网用户不卡，只能把码率压到最弱那一档，结果是所有人陪着一起糊。simulcast 就是为了解决这件事。

simulcast（联播）的做法是：发送端同时编码并上传 2 到 3 路不同分辨率与码率的同一画面（例如一路低清、一路中档、一路高清），SFU 收到后按每个接收端的实际带宽与显示窗口大小，挑合适的那一层转发下去。服务器不做任何转码，只是"选哪一包发下去"，这正是 SFU 名字里"选择性"的来源。

代价很明确：发送端的上行码率与编码 CPU 都增加了。这就是"开了 simulcast 之后发送端反而更卡"的原因——本来只上传 1 Mbps，现在要上传 1 Mbps 加若干低层，上行差的客户端自己先撑不住了。所以正确的做法不是全局开关，而是按发送端的实际上行能力动态决定开几层、各层码率多少；上行一变差就立刻关掉高层。SFU 侧要能识别并只订阅它负担得起的那几层。

SVC（可伸缩视频编码）是另一种思路：单路码流内部按时间、空间、质量分层，SFU 可以按层裁剪转发，粒度比 simulcast 更细，发送端的上行开销相对小。但它对编码器支持、浏览器实现和 SFU 的层处理逻辑要求都更高，落地前要逐项验证你实际使用的编解码组合是否真的支持你要的层模式，不能只看文档上的一句话。

无论 simulcast 还是 SVC，都需要 SFU 侧有对应的 RTP 扩展与层选择策略，并且要和拥塞控制联动——带宽估计掉了就降层，估计回升了再升层，还要做防抖避免层数来回跳导致画面抖动。这些逻辑不是开个开关就完事的，也是两种 SFU 实现差异最大的地方之一。

mediasoup 与 Janus：库与服务器，选型的分水岭在哪

两者都是成熟的开源 WebRTC 服务端，但形态完全不同，这个差别决定了团队要投入什么。

mediasoup 是库。核心是一个 C++ 写的 Worker 子进程，配套有 Node.js 等语言的控制层。你用代码一层层创建对象：Worker、Router、Transport、Producer、Consumer。它不做信令、不做房间管理、不做鉴权，这些全由业务代码写。好处是控制粒度最细——你可以做到只给当前发言人推高清层、给观众推低清层，可以在用户加入前就根据地理位置和机器负载决定落在哪台机器，可以按业务规则限制每房间的摄像头数。代价是"要自己写的东西很多"：信令协议、状态机、断线重连、房间编排、多 Worker 调度、跨机扩展策略，一个都不能少。

Janus 是服务器加插件。装好就有一个监听 HTTP/WebSocket 的服务进程，功能由插件划分：videoroom 做多方会议，audiobridge 做纯音频桥接，streaming 做单向推流，sip 做与传统语音系统的网关，textroom 做文本通道。它配置驱动，改配置文件就能跑起来一个能用的多方会议，开箱能力明显更多，录制、网关这类周边功能不用自己造。代价是定制要按它的方式来：业务规则写不进框架时，要么改插件逻辑，要么自己写 C 插件，门槛和调试成本都不低；房间编排与横向扩展的模式也受框架约束。

所以分水岭只有一句话：你要不要自己掌控房间编排与横向扩展策略。要掌控——比如业务上有复杂的分层策略、有跨机房调度、要把房间调度和自己的用户体系深度绑定——那么 mediasoup 这类库形态更合适，前提是你的后端工程能力撑得住。想快速有一套能跑的多方会议或音视频网关、接受框架给定的扩展方式，那么 Janus 这类服务器形态起步更快。

关于能力对比要说清楚：两者都支持 simulcast 与 SVC 方向的能力，也都支持 TURN 相关集成、录制等周边功能，但"支持到什么程度"取决于你使用的具体版本、编译选项和浏览器与编解码器组合。本文不列版本号与默认参数，落地时请以各自官方仓库的当前文档为准，并在你自己的浏览器矩阵里逐项验证。

多机扩展这一关：按房间分片还是服务器级联

单台机器上的房间是有状态的：某个房间的所有 Producer 与 Consumer 都在同一个进程、同一台机器的内存里，跨机器拿不到对方的媒体流。这就是 SFU 横向扩展比无状态 Web 服务难的根本原因。工程上有两条路。

按房间分片：房间创建时用一致性哈希或调度服务把它固定分配到一台机器，这个房间的所有人连同一台。优点是简单、延迟最优、房间内流量不出本机、故障域清晰；缺点是单个房间的人数上限就等于单机容量，遇到超大房间会形成单机热点，加机器解决不了这个房间的容量问题，机器宕机时该机器上所有房间一起掉线。容量规划必须按"可能出现的最大房间"来算，而不是按平均房间大小。

服务器级联：允许一个房间跨多台机器，服务器之间互相转发（本机把收到的流转给另一台，由另一台再发给它名下的接收端）。优点是突破单机上限，超大房间可以摊到多台。代价同样明确：跨机多一跳，延迟增加一个机房间 RTT；同一份流在机间又传一遍，出向带宽翻倍；如果跨机房级联，还要承担机房之间链路的质量波动与额外成本；故障排查时，一个"某个人画面卡"的问题要横跨两台机器的日志。

实践取向通常是混合的：先用分片把绝大多数中小房间解决掉，只对真正会突破单机容量的超大房间做级联。更划算的其实是在产品层做容量阀门——限制单个房间的人数、限制同时开摄像头的人数、把大班课拆成分组讨论再合并，这些产品手段比架构扩容便宜得多，且立刻生效。

无论选哪条路，都要有一个中心的位置服务：负责房间创建时选机器、客户端接入时引导到正确节点、机器上下线时摘除与迁移、以及跨机级联时的路由决策。这个服务本身的可用性和一致性，决定了整个集群的上限。

延迟拆开看：从采集到渲染，抖动缓冲的两难

用户说的"卡"和"慢"是两件事，但都表现为体验差。把端到端延迟拆开，才能定位问题出在哪一段。

链路大致是：采集（摄像头与麦克风的采集和预处理，本身就有几十毫秒量级）→ 编码（编码器、分辨率、帧率决定，开启 simulcast 后还要叠加多路编码的排队）→ 上行网络（半个 RTT 加上行排队）→ SFU 转发（查表、复制、加密、发送排队）→ 下行网络（半个 RTT 加下行排队）→ 抖动缓冲→ 解码→ 渲染。

这里面最不可压缩的一项是网络 RTT。它取决于用户到机房的物理距离和路由质量，任何编码器优化都救不回来——这也是为什么机房节点位置比 CPU 型号更影响体验。

抖动缓冲（jitter buffer）是延迟与流畅的直接交换。包到达的时间本来就不均匀，抖动缓冲把不均匀的输入整理成均匀的输出。缓冲调大，能吸收更大的网络抖动，画面更稳，代价是端到端延迟增加；缓冲调小，延迟低，但抖动一来缓冲就见底，立刻表现为卡顿与声音断续。没有两全的设置，只有按场景取舍：连麦互动要求低延迟，缓冲要压小；大班课单向讲授更怕卡顿，缓冲可以放大。

UDP 上没有 TCP 那种"丢了自动重传直到成功"的保证。WebRTC 提供了 NACK 重传与前向纠错一类机制来缓解，但重传要等至少一个 RTT，超过重传窗口就放弃；如果丢的是关键帧数据，画面会花屏并一直持续到下一个关键帧到达，所以弱网下要靠关键帧请求（PLI/FIR）快速恢复。丢包率高又不做保护时，表现就是花屏、马赛克、声音断续。

SFU 侧决定体验上限的是这几件事：转发排队是否在 PPS 或 CPU 打满时变长、带宽估计是否及时触发降层、带宽不足时是否优先保音频（音频中断比画质下降更影响沟通）、以及是否对丢包率高的下游及时止损。

排查顺序建议这样走：先区分是"所有人卡"还是"某一个人卡"。所有人卡，问题大概率在服务器出口带宽、PPS、网卡中断或机房链路；某一个人卡，问题大概率在这个客户端的上行与最后一公里，去查它的候选类型（是不是走了 relay）、上行码率、丢包与 RTT。

在租用服务器上的资源画像与节点选择

SFU 吃的是网络吞吐与 PPS，不是 GPU，一般也不需要独立显卡。它的流量特征是"小包高频"：视频 RTP 包通常控制在 MTU 以下，音频包更小但更密集。这类特征对网卡中断与 CPU 软中断敏感——大房间下，PPS 可能先于带宽成为瓶颈，表现为带宽没打满但 CPU 软中断飙高、转发排队变长。

给一套判断逻辑而不是一张配置表：

• 第一步算带宽：峰值并发人数按上面那条公式算出向 Mbps，再留 30% 到 50% 余量，得出的数字决定你要多大端口。这一步没算清楚，后面全是空谈。
• 第二步核 PPS：按每路码率与包大小估算每秒包数，确认网卡与中断处理能力跟得上；必要时关注多队列网卡与中断绑核这类系统层调优。
• 第三步估 CPU：按"每包加解密加转发开销 × PPS"估算核心数。纯转发场景通常比转码型业务低一个数量级；如果你还做了录制转码、混流或截图，这部分要单独算，它会把 CPU 需求拉回 MCU 量级。
• 第四步看内存与磁盘：内存主要是会话状态与重传缓冲，通常不是瓶颈；磁盘只在做录制、写日志或落转码产物时才重要，且是持续流式写入，要关注写入带宽与容量规划。
• 第五步定节点：按用户地理分布选节点，用户就近接入；跨地区用户多时直接上多节点分片，而不是让所有人跨半个地球连一台机器。

带宽计费口径要在签约前谈死：给的是端口速率还是月流量包，出向是否单独计价，超出之后是限速还是按量计费，峰值是否有突发允许。SFU 是持续出向业务，这类条款的差别在账单上会被放大。

在比选多地区节点与大带宽机型时，可以借助一万网络这类深耕 IDC 19 年的服务方做节点与机型比选——其官网明示的 BGP 多线加 CN2 GIA 回国方向、5–20G 免费 DDoS 防护、7×24 中文工单与平均 5 分钟响应，对"节点分散、出向带宽吃紧、出问题要立刻有人处理"的实时音视频业务比较实用；具体机型、带宽档位与价格以官网实时价为准，其余未明示项需实时询价。

还有一个容易被忽略的点：防护策略对 UDP 的处理方式要提前问清。实时媒体全走 UDP，防护是清洗还是直接黑洞、清洗对 UDP 有没有特殊策略与阈值、误判会不会打断正在进行的通话，这些问题要在合同阶段问，不要等一次小攻击把整场上课打断了再问。

上线前的验收项目：从防火墙到弱网表现

部署完成不等于可以上线。按下面这些项目逐项验收，能挡掉绝大多数线上事故（以下为典型部署思路下的验收清单，并非特指某一真实客户）。

• 网络与端口：媒体 UDP 端口区间已在安全组与系统防火墙双向放行；信令端口放行；TURN 的 UDP 与 TCP/TLS 443 端口放行；确认没有被机房侧的默认策略拦掉。
• 带宽口径：明确端口速率与计费方式，确认峰值时段出向不会触发限速；确认监控能采到出向带宽而不是只看入向。
• 中继命中率：在客户端统计里能看到候选类型分布，知道有多少比例的用户走了 relay，据此决定 TURN 的容量投入。
• 弱网表现：在可控环境里注入延迟、抖动与丢包条件，观察画面与音频的退化曲线，确认降层与关键帧恢复机制真的生效。
• 监控项：出向带宽、PPS、软中断、房间数、房间人数、丢包率、RTT、抖动、重传率、TURN 命中率、首帧时间。
• 故障演练：单机宕机后调度服务能否快速摘除并让新房间落到其他机器；TURN 节点宕机后用户能否自动切换到备用节点。
• 容量阀门：单房间人数上限、同时开摄像头人数上限、单机器房间数上限，都要在服务端强制，而不是只靠前端限制。

本篇 FAQ：部署前最常被问到的八个问题

一个 8 人房间在服务器上要多少带宽？

用公式算：出向约等于每路上行码率乘（N-1）乘参与人数。按每路上行 1 Mbps 量级估算，8 人房出向约 56 Mbps、入向约 8 Mbps。若每路按 2 Mbps 量级算，出向就翻倍到百 Mbps 量级。这是按公式做的量级演算，真实值取决于你的分辨率、帧率、编码器与画面复杂度，务必用你自己业务的码率设定重算一遍。

UDP 端口范围开多大才够？

按"并发房间数 × 每房间人数 × 每通道端口占用系数 + 余量"估算，不要拍脑袋给一两百个就上线。端口是本地资源，开大不花钱；开小的后果是并发一上来就建连失败，而报错信息往往指向别处，排查成本很高。

客户端在严格防火墙后面连不上，是不是必须上 TURN？

如果网络只放行 TCP 80/443、UDP 全封，或者客户端处于对称型 NAT 之后，直连基本没有可能，TURN 是唯一解，不是优化项。此时媒体全部经服务器中转，带宽与机房出口位置变成核心变量，预算要按"全部流量走中继"重算。

TURN 和 SFU 能不能装在一台机器上？

起步阶段可以，省一跳、省跨机带宽、运维简单。但两者出向带宽会叠加在同一张网卡和同一个端口上限上，故障域也重合。规模上来、尤其是中继命中率明显偏高时，就应该把 TURN 拆出来单独部署、按用户地理位置多点就近接入。

开了 simulcast 之后发送端为什么更卡？

因为发送端要同时编码并上传多路不同分辨率的同一画面，上行码率与编码 CPU 都增加了。上行本来就紧张的客户端会先撑不住。正确做法是按发送端实际上行能力动态决定开几层、各层给多少码率，上行一掉就关高层，而不是全局统一开启。

服务器 CPU 不高但画面卡，先查什么？

先分清是所有人卡还是某一个人卡。所有人卡，按这个顺序查：出向带宽是否接近端口上限、PPS 是否过高导致软中断飙高、网卡有没有丢包、抖动缓冲设置是否偏小。某一个人卡，去查该客户端的 ICE 候选类型是否走了 relay、它的上行码率与丢包率、以及最后一公里的 RTT。

房间一多就要加机器，横向扩展怎么做？

两条路：按房间分片，一个房间固定落一台机器，简单且延迟最优，但单房间容量受单机上限约束；服务器级联，一个房间跨多台，突破单机上限，代价是多一跳延迟、带宽翻倍和排查复杂。通常先用分片覆盖中小房间，只对超大房间做级联，同时在产品层设置人数与摄像头数的容量阀门。

跨地区用户延迟高，加机器有没有用？

加机器本身不解决 RTT，加在正确位置才有用。网络往返是延迟构成里最不可压缩的一项，用户离机房远，怎么优化编码器都补不回来。正确做法是按用户分布部署多节点就近接入，让调度服务把用户引导到最近节点；只有在就近节点已经到位、单机容量成为瓶颈时，加机器才直接有效。

本篇「WebRTC SFU」上线清单：从第一路通话到多机扩展的十步

• 第一步：确认业务属于多方实时通信（会议、课堂、连麦、协作），而不是呼叫中心转码或单向直播分发，据此选定 SFU 拓扑。
• 第二步：用出向带宽公式估算峰值容量，确定端口速率与计费口径，明确出向是否单独计价、超出后限速还是计费。
• 第三步：在安全组与系统防火墙放行媒体 UDP 区间、信令端口、TURN 的 UDP 与 TCP/TLS 443 端口。
• 第四步：部署 STUN 与 TURN，先在客户端统计里看清直连与中继的比例，再决定 TURN 的容量投入。
• 第五步：按并发房间数、人数与每通道端口占用估算 UDP 端口区间，留出充足余量。
• 第六步：在 mediasoup 与 Janus 之间做选型，判断依据是是否要自己掌控房间编排与横向扩展策略。
• 第七步：实现 simulcast 或 SVC 的层选择策略，并与拥塞控制联动，按发送端上行能力动态决定层数。
• 第八步：建立监控与告警：出向带宽、PPS、软中断、房间数、丢包率、RTT、抖动、重传率、TURN 命中率、首帧时间。
• 第九步：在可控环境注入延迟、抖动与丢包条件做弱网验收，调整抖动缓冲大小，确认降层与关键帧恢复生效。
• 第十步：设计横向扩展路径——先按房间分片并配置调度服务，再为超大房间准备级联方案，同时把人数与摄像头数限制做成服务端强制的容量阀门。

数据来源：本篇 SFU 架构与部署结论的出处与口径说明

本文关于 Mesh、MCU、SFU 三种拓扑的行为差异、ICE 候选类型（host、srflx、relay）与 TURN 中继机制、SRTP 与 DTLS 的作用、simulcast 与 SVC 的分层思路、以及 mediasoup 的库形态与 Janus 的服务器加插件形态，均来源于 WebRTC 相关公开标准文档与两个开源项目的官方公开文档口径；文中未引用任何具体版本号、默认参数与性能基准数字，落地时请以各自官方仓库的当前文档为准，并在自己的浏览器与编解码器矩阵中逐项验证。

文中所有带宽演算均为公开公式下的量级示例（出向约等于每路上行码率乘（N-1）乘参与人数），不是在任何真实环境里量出来的数据，也不构成对任何真实客户环境的结论。一路视频码率按"几百 kbps 到 2 Mbps 量级"这一区间表述，具体数值随分辨率、帧率、编码器与画面复杂度变化。本文未引用任何基准对比结论、性能排名或客户案例数据。

服务器租用相关的机型、带宽档位、节点与服务承诺，以一万网络官网 https://www.idc10000.net/ 对应页面的明示内容为准；官网未明示的规格与价格需实时询价，价格主要受 CPU、内存、存储、带宽、IP 和线路影响。具体以签约时最新报价与合同为准。