短视频直播SDK的直播连麦延迟优化方案
如果你经常看直播，肯定遇到过这种情况：主播连麦的时候，你这边说完话，对面隔了快一秒钟才回应，那种尴尬的语气延迟让人浑身不自在。放在以前，大家可能觉得忍忍就过去了，但现在不一样了，用户对体验的要求越来越高，稍微有点卡顿就划走了。这篇文章想聊聊，作为开发者或者技术负责人，到底怎么把连麦延迟压到最低，让用户感觉对面的人就在身边一样。
连麦延迟到底是怎样影响体验的？
在深入技术方案之前，我们得先搞清楚一个基本问题：多少延迟算高，多少算低？这事儿不能光看数字，得结合实际使用场景来说。
简单做个对比例子你就明白了。打电话的时候，对方说完你立刻就能接话，这个响应时间大概在100到200毫秒之间，我们人类基本感知不到延迟。但如果你跟朋友视频通话，中间有半秒钟的延迟，对话就会变得特别别扭，常常出现"你说完了吗？""我先说了啊"这种尴尬情况。连麦直播其实也是一样的道理，甚至因为场景更复杂，要求反而更高。
业内通常把延迟分成几个档次。300毫秒以内是理想状态，对话流畅自然，几乎感觉不到任何延迟；300到800毫秒属于可接受范围，偶尔会有一丝微妙的不对劲，但整体还能正常互动；800毫秒以上就开始难受了，双方很容易出现抢话或者长时间沉默；要是超过1.5秒，那这连麦基本没法看了。对短视频直播平台来说，绝大多数用户可接受的连麦延迟上限在500毫秒左右，再高就会有明显的体验问题。
值得注意的是，延迟和卡顿经常被混为一谈，但其实它们是两种不同的体验杀手。延迟是说句话要等多久，卡顿则是画面会不会卡住不动。前者让人感觉不自然，后者让人看不下去。作为技术优化人员，两个问题都得解决，但底层逻辑不太一样。
延迟都是从哪些环节来的？
想要优化延迟，第一步得搞清楚它到底是怎么产生的。这就像修水管，你得先找到哪里在漏水，不然再怎么折腾也是白费功夫。直播连麦的技术链路其实挺长的，每个环节都会贡献一点延迟，积少成多就变得很明显了。
我们可以用一个具体的例子来拆解。假设你在手机上打开直播APP，点击连麦按钮，从你说话到对方听到，这个数据要走过这样一段旅程：首先手机麦克风采集声音，这个过程大概需要10到40毫秒，然后把模拟信号转成数字信号，又要花个20毫秒左右，接着做音频预处理、回声消除、噪音抑制，这一套下来又是30到50毫秒。完了之后编码器开始干活，把原始的PCM数据压缩成适合网络传输的格式，编码延迟在10到100毫秒不等，取决于你用的编码器有多复杂。
真正的大头在网络传输这部分。数据包从你的手机出发，要经过基站、核心网络、互联网骨干链路，再到对方城市的服务器，然后反向走一遍到对方手机。这一路走下来，网络往返延迟（也就是RTT）轻轻松松就能到100到300毫秒甚至更高，而且这还是网络状况好的情况下。如果赶上网络拥塞，延迟翻倍都不奇怪。到对方手机之后，解码器要把数据恢复成原始信号，这个过程和编码是对称的，又要花个20到100毫秒，最后通过扬声器播放出来，这一路折腾下来，300毫秒的体验延迟是打底，500毫秒算是常态。
视频的情况比音频更复杂一些，因为视频的数据量要大得多。一路720P、30帧的视频，每秒产生的原始数据量大约是600多兆字节，就算编码压缩完之后也有1到4兆每秒。这个数据量在网络传输的时候，延迟贡献比音频只多不少。而且视频还有帧组装、渲染这些环节，哪个处理不及时都会造成延迟积压。
编解码环节的延迟来源
编解码是个挺有意思的优化点，因为它直接影响数据量大小，而数据量又直接决定传输速度。这里存在一个天然的矛盾：编码越复杂，压缩率越高，文件越小，传得越快，但处理时间也更长；编码简单处理快，但文件大，网络传输时间长。
以音频编码为例，常见的Opus编码器在高质量模式下延迟大约是20到60毫秒，而那种超低延迟模式可以压到5毫秒左右，但代价是同等码率下音质会有所下降。视频编码的情况更复杂一些，H.264的编码延迟通常在30到100毫秒，H.265会更高一些，因为它要做的计算更复杂。如果用的是硬件编码器，延迟会比软件编码器低很多，因为专用芯片处理这些计算天然就比CPU快。
这里有个关键点是所谓的"帧依赖"。很多视频编码器为了追求更高的压缩率，会让某一帧参考前面几帧的数据，这就导致后一帧必须等前一帧编码完成才能开始。如果用B帧（双向参考帧），延迟会进一步增加。所以在延迟敏感的场景下，有时候会禁用B帧或者减少参考帧数量，虽然码率会高一些，但延迟确实能降下来。
网络传输环节的延迟陷阱
如果说编解码是"算"出来的延迟，那网络传输就是"等"出来的延迟。这部分最让人头疼，因为它很大程度上不受开发者控制，用户的网络环境什么样都有可能。
首先，物理距离就是一道硬坎。数据在光纤里传输的速度大约是每毫秒200公里，北京到上海的光纤传输延迟本身就接近20毫秒，要是主播和观众一个在国内一个在海外，延迟轻轻松松就能到100到300毫秒。这个是物理定律决定的，谁也没法突破，只能尽量减少中间的路由节点。
然后是网络拥塞的问题。这个在移动网络环境下尤其明显。如果你所在的区域同时有很多人在用网络，基站负载一高，数据包就会排队等待，延迟飙升。有时候你明明测速看着带宽挺大，但延迟就是降不下来，这就是拥塞的典型表现。而且拥塞一旦发生，还会引发连锁反应——延迟高了之后，发送端以为网络有问题，可能会重传数据，重传又加剧了网络负担，形成恶性循环。
还有一类容易被忽视的问题是跨运营商传输。国内有移动、联通、电信三大运营商，它们之间的互联带宽有限，跨运营商的网络延迟往往比同运营商高出不少。如果你的服务器只接了电信线路，那联通或移动的用户访问时就要经过额外的转接，延迟自然就上去了。
从客户端出发的延迟优化策略
搞清楚了延迟的来源，接下来就可以对症下药了。我们先从客户端能做的事情说起，因为这部分的主动权最大，也最容易见效。
采集与预处理环节的优化
采集这个环节看似简单，其实有不少讲究。很多开发者直接用系统自带的采集API就完事了，但稍微深入研究一下就能发现一些优化空间。比如采集周期（buffer size）这个参数，有些设备的默认值是20毫秒，这个听起来不大，但积少成多也很可观。如果你的场景对延迟特别敏感，可以尝试把采集周期调到10毫秒甚至更短。当然这会增加CPU的占用，但在大多数现代设备上这点开销完全可以接受。
预处理环节的回声消除（AEC）是个技术难点。早期的回声消除算法计算量大、延迟高，效果还不一定好。但这些年技术进步很大，新一代的AI回声消除方案可以在保持低计算量的同时实现很好的消除效果，延迟也能控制在10毫秒以内。如果你们团队还在用老旧的回声消除方案，不妨评估一下换新的，成本可能比想象中低很多。
传输策略的智能化调整
传输层是延迟优化的核心战场，这块的策略设计直接影响最终的体验。传统的做法是固定码率、固定分辨率往下发，这种方式实现简单，但遇到网络波动就抓瞎。现在的做法通常是自适应——根据当前网络状况动态调整码率和分辨率。
具体来说，在连麦开始之前或者过程中，客户端需要持续探测可用带宽。这个探测不能太激进，不然会影响正常的数据传输；也不能太保守，不然无法充分利用网络资源。比较成熟的做法是用一种叫"带宽探测帧"的技术，定期发送一些探测包，根据丢包率和往返延迟来估算当前带宽，然后在码率、帧率、分辨率这几个维度上做权衡。
这里有个重要的原则要牢记：宁可降码率，也不要出现卡顿。对于用户来说，画面稍微模糊一点可以接受，但频繁卡顿是绝对忍不了的。所以自适应策略的优先级应该是先保证流畅，再追求清晰度，最后考虑帧率。
弱网环境下的特殊处理
中国有大量用户在弱网环境下使用网络，3G网络、偏远地区、地下场所，这些场景的带宽可能只有几十Kbps，延迟还特别不稳定。针对这种情况，普通的自适应策略往往不够用，需要一些特殊的处理手段。
首先是音频优先策略。当网络特别差的时候，保证音频流畅是第一位的，因为相比画面，用户对声音卡顿更敏感。可以的做法是在带宽不足时大幅降低视频码率，甚至临时关闭视频，只传音频，等网络恢复了再恢复视频传输。这个切换过程要尽量平滑，不能让用户察觉到明显的变化。
然后是前向纠错（FEC）和重传机制的配合使用。FEC是在发送数据的时候多发一些冗余包，这样即使丢了一些包，接收端也能通过冗余数据恢复出来，不需要重传。这种方式会增加一些带宽开销，但能有效降低延迟，因为不需要等重传。重传虽然更省带宽，但会产生额外的RTT延迟，在弱网环境下RTT本来就大，重传的代价就更明显了。
从服务端出发的延迟优化策略
客户端做得再好，如果服务端架构不合理，延迟也压不下去。这就像你从家到机场一路畅通，但机场本身效率低下，最后还是赶不上飞机。下面说说服务端常见的优化手段。
全球部署与智能路由
如果你服务的用户分布在全球多个地区，服务端节点的地理分布就至关重要了。理论上，用户的数据包应该走最短的路径到达服务器，延迟才能最低。但在实际网络中，最短物理距离不一定等于最优网络路径，因为不同运营商、不同链路之间的互联互通状况差别很大。
解决这个问题需要智能路由系统。系统在用户接入的时候，不仅要考虑物理距离，还要查表看这个用户走哪条路到哪个节点延迟最低。这个路由表需要持续更新，因为网络状况是不断变化的。有条件的话，可以考虑和专业的CDN服务商合作，利用它们在全球各地部署的边缘节点来做接入点，把用户的连接距离进一步缩短。
服务端架构的简化
有些直播系统的服务端架构比较复杂，用户的音视频数据要经过多层转发才能到达对端。每一层转发都会增加延迟，有些是处理延迟，有些是排队延迟，积少成多就很可观了。
理想情况下，应该尽量减少转发层级。在多人连麦场景下，可以采用SFU（Selective Forwarding Unit）架构，而不是传统的MCU（Multipoint Control Unit）。SFU只是简单地转发数据，不做转码和混流处理，延迟要比MCU低很多。对于一对一的连麦场景，甚至可以考虑端到端的P2P连接，不经过服务器转发当然是最快的。
还有一个思路是利用边缘计算的概念，把更多的处理逻辑放到离用户更近的地方完成。比如某些转码、合流的工作，与其放在中心机房做，不如放在用户就近的边缘节点做，虽然单个边缘节点的处理能力不如中心机房，但胜在延迟低、覆盖广。
传输协议的优化选择
传输层协议的选择对延迟影响很大。传统的RTMP协议延迟通常在2到3秒，根本不适合连麦场景。后来出现的webrtc协议把延迟降到了几百毫秒的水平，目前已经成为连麦场景的事实标准。
但webrtc本身也在演进。最新的QUIC协议在WebRTC的基础上又做了进一步优化，它基于UDP而不是TCP，没有TCP的队头阻塞问题，在网络不稳定的时候表现更好。而且QUIC支持0-RTT握手，连接建立的速度也更快。如果你的技术栈允许，可以考虑在合适的场景下使用基于QUIC的传输方案。
行业实践与效果评估
说了这么多技术方案，我们来看看实际应用中的效果是怎样的。以下数据来自声网在实时音视频领域的实践经验，我们看看不同场景下延迟优化能做到什么程度。
| 场景 | 常规延迟 | 优化后延迟 | 优化手段 |
| 1V1视频社交 | 400-600ms | 最佳可做到小于600ms | 端到端优化、全球智能路由 |
| 秀场连麦 | 500-800ms | 300-500ms | 边缘节点部署、协议优化 |
| 多人连屏 | 600-1000ms | 400-700ms | SFU架构、自适应码率 |
这些数据告诉我们，经过系统性的优化，延迟下降的空间大概在20%到40%之间。具体能优化多少，取决于原来的基础有多差，以及投入了多少资源去做优化。如果原来用的是老旧的技术栈，优化空间可能更大；如果原来已经做得很好了，那进一步优化的边际收益就会递减。
衡量优化效果不能只看延迟数值本身，还要看用户体验的变化。比如卡顿率、首帧时间、音频中断次数这些指标都要综合考虑。有些优化手段可能表面上把延迟降下来了，但代价是卡顿率上升了，这种拆东墙补西墙的做法并不可取。真正的优化要追求的是整体体验的提升，而不是某一个指标的局部最优。
不同场景下的侧重点
虽然我们一直在说延迟优化，但实际做的时候不能一刀切。不同的业务场景，对延迟的敏感程度不一样，优化策略也应该有所区别。
对于1V1视频社交这种场景，用户的核心诉求就是流畅自然的对话，延迟是决定体验的关键因素。在这个场景下，应该把延迟优化放在最高优先级，甚至可以为了低延迟牺牲一些画质。前面提到的各项优化手段，在这个场景下都值得投入。
对于秀场直播的连麦场景，情况稍微复杂一点。一方面主播和连麦嘉宾之间的互动需要较低的延迟，另一方面还要考虑观众的观看体验。所以优化策略要兼顾端到端延迟和系统整体的稳定性。如果条件允许，可以考虑为主播端和观众端分别设计不同的传输策略。
对于多人连麦场景，最大的挑战是在保证低延迟的同时处理多路音视频的混合与分发。这时候服务端架构的选择就特别重要，SFU相比MCU的优势会更加明显。同时，端到端的延迟优化也不能放松，毕竟每个参与者都希望自己能顺畅地和其他人互动。
写在最后
直播连麦的延迟优化是个系统工程，没有哪种技术方案能独自解决所有问题。从客户端的采集编码到服务端的分发传输，每个环节都有可以优化的空间，更重要的是这些优化要形成合力，而不是各自为政。
在实际落地的时候，建议先做好全链路的延迟监测，明确每个环节贡献了多少延迟，然后再针对性地去优化。盲目地调参数、改配置，最后很可能顾此失彼。还有就是测试环节要做好真实环境的验证，实验室的网速和网络测速的结果可能和用户的实际体验差距很大。
随着技术的不断进步，我们有理由期待未来的连麦体验会越来越好。5G网络的普及、编解码算法的进化、AI技术在音视频领域的深度应用，这些都是值得期待的发展方向。对于从事音视频开发的团队来说，保持对新技术的敏感度，持续迭代优化方案，才能在激烈的市场竞争中保持领先。
