过去两年，聊聊语音聊天网的语音聊天并发峰值从3万路增长到17万路，音频传输链路承受的压力远超预期。传统的WebRTC Mesh方案在超过6人时就开始出现明显抖动，而SFU级联又带来了额外的转发延迟。这篇文章复盘我们在高并发场景下踩过的坑和最终落地的方案。

问题出在哪：抖动缓冲与丢包重传的博弈

实时音频对延迟极度敏感，端到端超过200ms用户就能感知到「抢话」。但在高并发聊天室中，网络抖动是常态。我们早期采用固定60ms的Jitter Buffer，弱网下丢包率一高就频繁触发NACK重传，反而加剧了拥塞。后来改为自适应抖动缓冲，根据RTT和丢包率动态调整窗口，端到端延迟平均降低了23%。

我们的传输方案：分层编码 + 选择性转发

核心思路是让SFU只做「聪明转发」，不做转码。具体做法：

• Opus分层编码：每个发言人推送2层音频流（窄带/宽带），SFU根据订阅端网络状况选择性转发
• 动态订阅策略：仅转发当前活跃的3-5路音频，其余静音流直接丢弃
• FEC与NACK混合：对关键帧启用FEC冗余，非关键帧走NACK快速重传

这套组合拳下来，单台8核SFU节点能稳定承载约1.2万路语音聊天转发，CPU占用控制在65%以下。

实践中的两个建议

一是别迷信纯UDP，在部分企业防火墙下TCP回退是必要的；二是监控要细到每个房间的MOS分，我们自研的探针每5秒采样一次，低于3.5分自动触发路由切换。

音频传输没有银弹，只有在延迟、丢包和成本之间找平衡。聊聊语音聊天网目前正在测试基于QUIC的0-RTT重连方案，目标是把断线恢复时间压到100ms以内。欢迎同行交流。