做在线教育与视频会议，WebRTC 媒体服务器怎么部署：SFU 的 CPU、带宽与延迟账

从一场百人公开课说起：为什么 P2P 撑不住、必须上媒体服务器

做在线教育、企业视频会议、直播连麦和远程医疗问诊这类业务时，很多人最初版本会用 WebRTC 的 P2P 直连模式。几个人开个小房间，浏览器之间直接建连，确实能跑通，开发也省事。但一旦房间人数上到两位数，或者产品对"进房快不快、卡不卡、中途掉线能不能无感重连"提出了硬性要求，P2P 的 mesh 拓扑就立刻露馅：每个终端都要和房间里其他所有人分别建一条连接，上行带宽随着人数近似平方级膨胀，手机很快发热、画面掉帧、进房超时连连。更糟的是，一旦某个参与者的网络抖动，会直接拖慢与他相连的每一个人。

这正是媒体服务器存在的意义。它把所有终端的流先收上来，由服务端统一做调度、路由和转发，终端只跟服务器建一条连接。本文不堆概念，而是以一个后端工程师排容量的视角，把 SFU 架构下"单机并发能扛多少路、CPU 和带宽怎么估算、延迟和丢包怎么治、裸机和云怎么选、怎么跨机房扩容"这套账一步步算清楚。你会看到，RTC 后端的成本模型跟普通 Web 服务完全不同——它不是算 QPS，而是算 PPS（每秒包数）和 Gbps（出向带宽）。

SFU 与 MCU 的本质区别：转发还是合流

媒体服务器主要有两类架构。其中一类是 SFU（Selective Forwarding Unit，选择性转发单元）。它的工作非常"懒"：收到每个终端发来的音视频包后，只做解封装、按需路由、再封装发出去，全程不解码、不重新编码。它就像一个智能交换机，知道 A 的流该发给谁、不该发给谁，但从来不去"看懂"画面里的内容。第二类是 MCU（Multipoint Control Unit，多点控制单元）。它会把房间里所有人的流都解码出来，在服务端混音、合画——比如拼成九宫格或演讲者大窗——然后重新编码成一路再下发给每个终端。MCU 对终端最友好：弱网手机只收一路流，不用处理多路解码；但代价是服务端要承担全部转码算力，CPU 开销通常是 SFU 的几十倍量级。

为什么现在主流的 RTC 产品几乎都选 SFU？核心原因是服务端转码太贵且不灵活。在教育场景里，老师推的是 1080p，学生可能只想要 360p 的小窗，MCU 必须先把所有人拉到同一分辨率再合成，算力被严重浪费；而 SFU 配合 Simulcast（联播，同一路内容推多个清晰度）或 SVC（可分层编码），可以让每个订阅者只拿自己消费得起的清晰度，服务端几乎不碰编解码。除非你的终端全部是老旧得只能收一路合成流的 SIP 硬件终端，否则 SFU 是更经济的默认选项。换句话说，选 SFU 还是 MCU，本质上是"把算力花在服务端转码"还是"把带宽花在终端多收几路流"的取舍，而当下终端的解码能力普遍够强，所以天平倒向了 SFU。

带宽账怎么算：上行 × N 的转发公式

SFU 不转码，所以服务端的"带宽账"非常透明，可以直接套公式。假设一个房间有 N 个人，每个人上行码率稳定为 r（比如以 1.5 Mbps 视频加一小段音频为例，真实值取决于你设的编码参数，这里只是为了计算方便），那么：每个人的上行都进服务器，服务端入向总带宽 = N × r；服务器要把每个人的流转发给另外 N-1 个人，因此服务端出向总带宽 = N × (N-1) × r。两端加起来，单个房间的服务端带宽 ≈ 2 × N × (N-1) × r，当 N 较大时约等于 2 × N² × r。

从单个用户的视角看更有意义：他上传 r，同时下载 (N-1) × r，所以他这一路"进出合计"的带宽就是 r × N。这就是"上行 × N 的转发公式"的直觉来源——房间里每增加一个参会者，每个人的下行就多背一路流。这也是为什么百人大会必须做订阅控制（只订阅当前发言人加几路小窗预览），否则单用户的下行带宽会直接撑爆他的网卡和你的服务器上行。

一个常被忽略的细节是音频也要算进去。语音单路虽然只有几十 kbps，但在全订阅场景下，音频的转发路数和视频完全一样多，N 较大时音频的总带宽也相当可观，排容量时千万别只盯着视频。另外，如果你开了 Simulcast，一个人上行就不止一路，r 要乘以层数，公式里的 r 要相应放大。把这些变量都代入，你才能在采购前大致知道一台机器能喂饱多少并发。

CPU 到底花在哪：不转码时主要耗在加解密与转发

既然不做转码，SFU 的 CPU 到底花在哪？主要有四块。首要的是 SRTP 加解密：WebRTC 媒体默认走加密的 SRTP，服务端每收每发都要做加解密运算，这在不转码的 SFU 里是 CPU 占用的绝对大头。第二是数据包的拷贝与路由：需要解析 RTP 头、按 SSRC 做 demux、为每个订阅者维护独立的发送队列和 pacing（平滑发送）节奏。第三是 RTCP 与抗丢包机制的处理，包括 NACK（丢包重传请求）、PLI（关键帧请求）、TWCC（收发端带宽探测）这些反馈报文的解析与响应——这些控制面报文虽小，但频率极高。第四是开启 Simulcast/SVC 时的分层重组与按需选层逻辑。

经验上，不做转码的纯转发 SFU，单路流的 CPU 占用很低。典型实现下，一个现代服务器物理核能稳定转发数百路 1–2 Mbps 量级的流（具体数字随实现、是否开 FEC、是否开联播而浮动，不能给死值，排容量要做自己的压测）。真正让 CPU 飙升的只有两种情形：一是你不小心开了服务端转码，那就等于退回 MCU 的坑；二是单进程事件循环被某一路异常流量或大量 NACK 风暴拖死，导致雪崩。所以给 RTC 后端排容量时，CPU 往往不是首要约束，带宽和中断（PPS）通常先到顶。这也是为什么很多人用 32 核机器跑媒体，CPU 才用了 20% 就已经网卡打满——瓶颈在网，不在算。

网络与内核：UDP 收发的瓶颈与调优

RTC 媒体走 UDP（准确说是 SRTP over UDP），而 Linux 默认的 UDP 缓冲区非常小，高并发下极易出现内核丢包，表现出来就是"偶发卡顿、说不清原因"。所以内核和网卡调优不是可选项，而是必做项。内核层面要抬高 net.core.rmem_max / wmem_max 以及对应的 default 值，让每个 socket 的收发缓冲能吃到几 MB 级别；调大 net.ipv4.udp_mem，让系统为 UDP 协议预留足够内存；适当放宽 udp_rmem_min / udp_wmem_min，避免小包被缓冲下限卡住。

网卡层面，要开启多队列 RSS（Receive Side Scaling），把收包中断打散到多个 CPU，配合 irqbalance 或手工把中断亲和到指定核，避免所有包都挤在同一个核上把单核跑满。打开网卡的 checksum offload、GRO/LRO 等硬件卸载，把协议栈负担甩给网卡。多 worker 进程部署时，用 SO_REUSEPORT 让内核把 UDP socket 均匀分发给各个 worker，避免单 socket 单线程成为瓶颈。更进一步，对延迟敏感的部署可以做 CPU 绑核、NUMA 亲和，让内存和网卡 DMA 落在同一个 NUMA 节点上，减少跨节点内存访问带来的额外延迟。

还有一条工程经验必须强调：媒体端口不要开太宽的范围，TURN / relay 的兜底链路一定要准备好。因为相当比例的终端身处对称型 NAT，直连走不通只能走中继，而中继会吃掉额外的服务器带宽和 CPU——这部分容量也要提前预留，否则高峰期中继一开，你以为够用的带宽瞬间被偷走一大块。监控上也要单独盯 relay 的流量占比。

小规模配置：单节点如何选机型

先说单节点小规模。十到几十人的房间、并发总路数在几百路以内，一台中端服务器就能扛住。CPU 选型上，选主频较高、单核性能好的型号，因为 SFU 转发链路里仍有一部分单连接串行逻辑，主频比核数更关键；内存 32–64 GB 通常足够，瓶颈不在内存而在带宽；网卡至少要双口万兆（10 Gbps），并且要跟机房确认上联能真给到万兆，而不是共享抢占下的"标称万兆"。

这类场景里最常见的错误，是用云上 2 核 4 G 的小实例去跑媒体，结果上行被云厂商限速、出向带宽按量计费把成本拉爆，还没扛住几个人就崩了。小规模起步可以用裸机，也可以选高 IO、高网络性能的云机型，但无论如何都要确认网络出口是独享而非超售。另外，小规模也容易忽视前面的内核调优——觉得"机器小不用调"，结果 PPS 一上来照样丢包。调优和机型同样重要。

大规模配置：千路以上怎么堆资源

并发到千路以上，或者同时开大量中等房间时，要分两层想：单节点容量上限和横向扩展。单节点方面，CPU 建议上多路（双路）服务器，核数 32 起步且主频不能拉胯；内存 128 GB 往上；网卡直接上 25 Gbps 或双万兆绑定，并且要求机房提供稳定的大带宽上联。带宽上，按前面的公式推算：假设单路视频 1.5 Mbps、千人同时在线且非全订阅（比如平均每人下行只看 5 路），服务端出向就是 1000 × 5 × 1.5 ≈ 7.5 Gbps 这个量级，单张万兆卡勉强、双万兆或 25 G 才从容。注意这里的"平均只看 5 路"正是订阅控制的价值——如果不做控制、全订阅，千人房间的出向会逼近 1.5 Tbps 这个离谱的量级，任何单机都扛不住。

所以大规模部署的核心结论很明确：千万不要指望单节点无限堆。当单节点的带宽或 CPU 触顶，就要走横向扩展——把用户按地理分布或房间分片调度到不同节点，节点之间用级联（cascade）互通，而不是把所有人塞进一台机器。容量规划的本质，是"用订阅控制把单用户下行压住、用级联把总量分摊到多节点"，这两招缺一不可。

裸机还是云：两种交付形态的成本与抖动账

排容量时绕不开一个问题：媒体服务器放裸机还是云？裸机的最大优势是可预测。物理核独占，没有"邻居抢资源"的 steal time；网卡是直通的，sustained 高带宽下抖动小；适合长期稳定跑媒体转发。缺点也明显：采购和上架周期长，硬件故障要自己换，弹性差，临时扩容慢。

云的优势是弹性：RTC 流量常有波峰波谷（比如晚上上课高峰、白天低谷），云可以按需扩缩，上线快。但云有两类隐性成本要算清。一是虚拟网卡和宿主机调度带来的开销，媒体这种高 PPS 负载对虚拟网络栈并不友好，同样配置下裸机往往能扛更多路。二是出向带宽按量计费，而 RTC 下行带宽巨大，云上的流量费可能比机器本身还贵。三是突发时可能被限流或调度到拥挤的宿主，导致偶尔的抖动。工程上的折中方案是：用裸机做常驻的高容量转发节点，把云当弹性缓冲和故障兜底；或者核心中继节点用裸机、边缘接入用云。最终选哪种，取决于你的流量曲线是否可预测、以及对抖动容忍度的高低。

扩容与级联：跨机房、跨地区的 cascade 架构

单节点到顶之后，靠级联（cascade）做横向扩展。思路并不复杂：每个 SFU 节点服务本机房或本地区的一批用户，节点之间建立 server-to-server 的转发通道。当 A 机房的用户要看 B 机房的某一路流，B 节点只把那一路流发一次给 A 节点，A 节点再在本地机房内部分发给本地订阅者——跨机房链路只走一份拷贝，不会按订阅人数翻倍。这正是级联相比"每个节点各自拉全量流"省带宽的地方。

跨机房、跨地区的 cascade 要算两笔账。一笔是互联带宽，等于"本节点需要订阅的远程流总码率"，要和机房之间的上联匹配，否则级联链路本身成为瓶颈。另一笔是延迟，跨机房会多一跳网络往返，物理距离越远这一跳越明显，所以级联路由必须基于地理就近，把用户调度到最近的接入节点，尽量让同一个房间的用户落在同一或相邻机房。常见做法是配合 GeoDNS、Anycast 或自建调度服务做就近接入，再用节点间级联补齐跨区订阅。容灾也可以借级联实现：某节点挂了，调度层把用户引流到相邻节点，跨区流通过级联补齐；但级联本身引入了节点间依赖，链路质量监控和优雅降级（比如某路跨区流丢了就降级为不订阅）必须提前做好，否则一个节点抖动会顺着级联传染给整张网。

成本分析：把账算到每一路流

把账算到每一路流，结论往往反直觉。RTC 的成本大头通常不在机器本身，而是两样东西：带宽（尤其是出向下行带宽）和运维人力。裸机的机器费相对固定，但大带宽上联的单价随量级和机房位置差异很大；云上则是"机器便宜、流量贵"。所以做预算时，先按前面的转发公式算出峰值出向带宽，再去比不同交付方式的带宽单价，常常会发现：看着便宜的云方案，在千路级别的下行车流量面前，可能比裸机还烧钱。换句话说，媒体服务器的成本模型是"带宽驱动"而非"算力驱动"，这是和普通 Web 服务最不一样的地方。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型/带宽/报价以官网实时或咨询确认为准。对媒体服务器这类"带宽敏感、要稳定上下行"的负载来说，选一个有稳定大带宽上联和 BGP 多线的机房，往往比单纯比机器单价更重要——因为抖动和超售带来的隐性损失，远大于那点机器差价。

联播与分层：Simulcast / SVC 的配置逻辑

要让 SFU 在不转码的前提下适配不同终端，关键武器是 Simulcast（联播）和 SVC（可分层视频编码）。Simulcast 的做法是：上行端把同一路画面编码成多个不同清晰度的流（比如 180p / 360p / 720p 三层）同时推给服务器，服务器根据每个订阅者的网络状况和窗口大小，只挑合适的那一层下发给它。这样弱网手机收 360p、宽带大屏收 720p，服务端完全不用重新编码，只是"选层转发"。缺点是上行要推多路，发送端码率和耗电更高，所以层数一般控制在 2–3 层，再多在弱网手机上反而搬起石头砸自己脚。

SVC 则更优雅：编码时把一路画面打成基础层加多个增强层，丢掉了增强层画面还能看（只是模糊），订阅者按能力"剥"到自己需要的层数。相比 Simulcast，SVC 上行只推一路、带宽更省，但对编码器和终端的兼容性要求更高，WebRTC 里 SVC 的落地成熟度因浏览器而异。工程上的务实选择是：优先用 Simulcast 跑通，等上层对 SVC 支持稳定了再迁移。无论哪种，配置逻辑都围绕一个原则——"服务端只转发、不重编码"，把清晰度决策下放到订阅侧，这也是 SFU 比 MCU 省算力的根本。

部署上线流程：从压测到灰度

媒体服务器不是上线就能跑的，建议按一套固定流程走。首要一步是基准压测：用媒体压测工具模拟 N 路上行、各订阅层，跑出单节点的 PPS 上限、出向带宽上限和 CPU 占用曲线，而不是拍脑袋定容量。第二步是内核与网卡调优落地：把前面那一套 rmem/wmem、udp_mem、RSS 多队列、中断亲和、SO_REUSEPORT 写成开机固化脚本，避免重启后参数丢失。第三步是接入调度与就近路由：把用户按地区引导到对应节点，TURN 中继作为兜底链路一并部署并压测其容量。第四步是监控埋点：PPS、带宽、重传率、NACK、jitter、rtt、relay 占比全部接入时序数据库和告警。第五步才是灰度上线：先放小比例真实流量，观察晚高峰指标，再逐步放量。很多团队跳过压测直接上生产，结果晚高峰一压就暴露，代价远大于前期那几天投入。

故障场景与定位：卡顿到底出在哪一层

RTC 的"卡顿"是个笼统投诉，定位要分层。最外层是接入层：用户根本进不了房，多半是 ICE/DTLS 握手失败，检查 NAT 类型、TURN 是否可用、证书是否正确。第二层是网络层：能进房但偶发卡，先看服务器 PPS 和内核丢包计数（netstat -su 里的 packet receive errors），如果是它涨了，说明是 UDP 缓冲或网卡中断没调好。第三层是带宽层：整体卡、下行打满，检查是否忘了做订阅控制、是否 relay 占比异常高。第四层是应用层：某个房间集体异常，往往是该房间的 NACK 风暴或某个异常终端在疯狂重传，需要按房间维度隔离定位。第五层是依赖层：级联场景下某条跨机房链路抖动，顺着级联把影响范围圈出来。把这套分层定位法沉淀成 runbook，半夜告警时才能不抓瞎。

监控指标体系：盯住真正相关的数字

前面反复提监控，这里把指标讲具体。服务端侧至少要看：入向/出向带宽（按网卡、按节点）、PPS（收发包速率，这是比带宽更敏感的预警指标）、CPU 各核利用率与 steal time（云上尤其要看 steal）、内核 UDP 丢包计数、每个 worker 的排队延迟。需要特别提醒的是，PPS 往往在带宽打满之前就先触顶，因为它是包数量的函数而不是字节量的函数，小包密集时尤其明显，所以把 PPS 当作首要预警线比盯 Gbps 更稳妥。媒体质量侧要看：端到端 rtt、jitter、重传率（retransmission rate）、NACK 请求频率、PLI/关键帧请求次数、各订阅层的实际下发音清晰度分布。业务侧要看：进房成功率、首帧时间、卡顿率（单位时间内卡顿时长占比）、relay 流量占比。这些指标要能下钻到"某个房间、某个用户、某条流"，否则出了问题只能看个总量干着急。告警阈值建议围绕 PPS 接近网卡上限的 70%、重传率超过某个比例、relay 占比突增来设，而不是等 CPU 满了才叫。

避坑指南：那些上线后才暴露的问题

上线后才暴露的问题，往往比选型更磨人。其一，高估了单节点能力，没做订阅控制，百人大房每个人都全订阅，网卡直接打满，表现是整个房间集体卡顿。第二，只调了应用层，忘了内核 UDP 缓冲和网卡多队列，PPS 一高就丢包，表现就是"偶发卡顿、说不清原因"，查日志还一切正常。第三，把 TURN 中继容量忘了算，遇到对称 NAT 用户比例高的地区，中继带宽偷偷吃掉一大块，峰值直接被打穿。第四，云上没确认出向带宽是否独享，结果被超售限速，白天正常、晚高峰就掉链子。第五，监控只盯 CPU 和内存，没盯 PPS、重传率、NACK 风暴和 jitter，出问题无从定位，只能靠用户投诉才发现。

如果团队没有专职运维去盯内核参数、网卡中断和 BGP 路由，借助像一万网络这样提供自营节点、机柜托管与 BGP 多线接入的 IDC 服务商，把媒体服务器放在上下行有保障的机房里，再配合上文的容量公式做规划，通常比自己在云上裸跑更省心，也更容易把每一路流的成本算明白。这里的核心建议是：把"基础设施稳定性"当作容量的一部分来规划，而不是等出了问题再补。

常见问题解答

Q1：SFU 和 MCU 到底怎么选？
默认选 SFU。除非你的终端全部是只能收一路合成流的旧硬件（如部分 SIP 终端），否则 MCU 的服务端转码算力成本在千路级别会失控。SFU 配合 Simulcast/SVC 能在服务端不转码的前提下，给不同终端下发不同清晰度。

Q2：百人大会 SFU 扛得住吗？带宽怎么算？
扛得住，但必须做订阅控制。按公式，服务端出向 = N × (N-1) × r；百人全订阅会逼近约 15 Gbps（以 1.5 Mbps/路估算），单节点压力大。实际做法是只订阅发言人加几路小窗，把单用户下行压到 5–10 路，总量立刻降一个数量级。

Q3：不做转码 CPU 是不是就完全不是瓶颈？
不是完全，但优先级低于带宽和 PPS。不转码时 CPU 主要花在 SRTP 加解密、包路由拷贝、RTCP/NACK 处理上。CPU 真正崩掉通常是因为开了转码，或单 worker 被 NACK 风暴拖死。排容量时先算带宽和中断。

Q4：为什么 UDP 要专门调内核参数？
Linux 默认 UDP 缓冲很小，高 PPS 下内核会丢包，表现为偶发卡顿。要抬高 rmem/wmem、调 udp_mem，并开网卡多队列 RSS、中断亲和、checksum/GRO 卸载和 SO_REUSEPORT，才能吃满万兆卡。

Q5：裸机和云哪个更适合媒体服务器？
长期稳定高带宽负载优先裸机（可预测、无超售、无虚拟网栈开销）；流量波峰波谷大、要快速弹性再用云。常见折中是裸机做常驻转发、云做弹性缓冲与兜底。

Q6：什么叫级联，什么时候需要？
级联是多个 SFU 节点之间建立 server-to-server 通道，跨节点只传一份流副本、本地再分发。当单节点带宽/CPU 到顶，或用户分布在多地区时就需要级联来横向扩展和就近接入。

Q7：跨地区级联延迟会不会很难看？
跨机房会多一跳网络往返，物理距离越远越明显，所以级联必须配合地理就近调度（GeoDNS/Anycast），让同房间用户尽量落同一或相邻机房，跨区只传必要的少量流，把额外延迟控制在可接受范围。

Q8：怎么监控才知道 SFU 真的工作正常？
不能只看 CPU/内存。要盯 PPS、入向/出向带宽、重传率、NACK 频率、jitter、rtt，以及 relay（TURN）流量占比。建立按房间、按节点的明细指标，才能在卡顿前发现问题。

容量规划自查清单：上线前逐项过一遍

把前面所有要点收敛成一份可勾选的清单，上线前逐项确认，能挡掉绝大多数事故。其一，算清峰值出向带宽：用 N × (N-1) × r 加上订阅控制后的实际下行路数，得出单节点和总量，再去匹配网卡与上联。其二，确认订阅控制已开启，百人房不能全订阅。其三，内核 UDP 缓冲、udp_mem、网卡 RSS 多队列、中断亲和、SO_REUSEPORT 全部固化并验证过。其四，TURN 中继容量单独压测，relay 占比有监控。其五，Simulcast/SVC 层数按终端能力设定，别盲目堆层。其六，级联互联带宽与就近调度就绪，跨区只传必要流。其七，监控覆盖 PPS、带宽、重传率、NACK、jitter、rtt、relay 占比，且能下钻到房间和流。其八，成本模型按"带宽驱动"测算，大带宽上联单价和稳定性优先于机器单价。八项都打勾，容量才谈得上可预测。

结论

把 WebRTC SFU 媒体服务器部署好，关键不是选一台配置顶满的机器，而是把三本账算清楚：带宽账（上行 × N 的转发公式，加订阅控制压下行）、CPU 账（不转码时主要耗在加解密与转发，瓶颈常在网不在算）、延迟账（内核 UDP 调优 + 级联就近调度）。小规模可以单机裸机起步，千路以上必须走多节点分片加级联，跨地区用 cascade 把总量分摊、把额外延迟压到最低。成本上牢记 RTC 是带宽驱动而非算力驱动，大带宽上联和稳定多线往往比机器单价更值得投入。按本文的公式和配置思路去压测、去调内核、去建监控，你就能把"每一路流"的成本和容量都落在可预测的范围里。

演进路径上，建议从单机单节点跑通全流程开始，把压测基线和监控体系先建起来；当单节点出向逼近网卡上限的七成，再引入第二节点做分片，而不是一开始就上复杂集群。级联和调度层可以等真正出现跨地区用户时再补，过早抽象只会增加运维负担。回过头看，SFU 部署的难点从来不是某一行配置，而是把"带宽、算力、延迟、成本"这四件事当作一个联动系统来规划，并在真实的晚高峰流量里反复校准你的假设。只有这样，产品从几十人小房扩展到万人大会时，后端才不会出现措手不及的塌方。

参考来源：

WebRTC 1.0 规范与 W3C WebRTC 标准文档（WebRTC API、RTCPeerConnection、SRTP/DTLS 媒体加密相关章节）。

IETF RFC 3550（RTP）、RFC 3711（SRTP）、RFC 4585 / RFC 5104（RTCP 反馈与 NACK/PLI 丢包恢复机制）、RFC 5766（TURN 中继）等公开标准。

janus WebRTC Server 公开文档与 GitHub 仓库（SFU 转发模型、插件架构与部署说明）。

mediasoup 官方文档与 GitHub 仓库（Worker/Router/Transport 模型、Simulcast 与 SVC 分层、横向扩展思路）。

Licode 开源项目公开文档（Erizo SFU 媒体管道与集群部署说明）。

pion / webrtc 开源实现文档与社区资料（Go 语言 WebRTC 栈、ICE/DTLS/SRTP 处理流程）。

Linux 内核网络调优公开资料（net.core.rmem_max、net.ipv4.udp_mem、RSS 多队列与 SO_REUSEPORT 等相关说明）。