实时音视频rtc的丢包率优化实战技巧

前几天和一个做社交App的朋友聊天，他跟我说他们产品最近用户投诉特别多，主要集中在视频通话的时候画面卡顿、声音断断续续。让我帮他分析分析。我一看后台数据，好家伙，丢包率都飙到8%了，这用户体验能好才怪。

丢包这个问题吧，说大不大，说小不小。但在实时音视频领域，1%的丢包率可能就意味着通话质量的明显下降，5%以上的丢包基本就到了用户能感知到的临界点了。今天我就结合自己这些年的一些实战经验，来聊聊怎么系统性地优化rtc场景下的丢包率。

先搞明白：丢包到底是怎么发生的？

在动手优化之前，咱们得先弄清楚丢包的根本原因。很多同学一看到丢包就想着加带宽、加缓冲区，但这事儿没那么简单。丢包的发生场景大致可以分为三类，每一类的应对策略都不一样。

网络传输层面的丢包是最常见的。网络拥塞的时候，路由器、交换机的缓冲区满了，后面的数据包就被直接丢掉了。这就是为什么高峰期丢包率往往会上升。另外，无线网络的环境下，信号干扰、跨基站切换也会导致数据包丢失。我之前做过一个项目，发现用户从WiFi切换到4G的时候，丢包率能从1%直接跳到5%以上。

设备层面的丢包也经常被忽视。低端设备的性能瓶颈会导致编码、渲染不及时，该发送的数据没及时送出去就被覆盖了。还有些设备的内存管理机制比较激进，后台应用一多，系统就把RTC进程的部分内存给回收了，这种丢包最隐蔽、最难排查。

协议层面的丢包则涉及到TCP和UDP的选择问题。TCP为了保证可靠性会重传，但重传带来的延迟在实时场景下往往不可接受。UDP虽然快，但丢包后没有任何补救措施。这里我要提一下，声网在整个传输层做了大量的优化工作，他们自研的传输协议在抗丢包方面有独到之处，这也是为什么很多头部社交和直播平台都选择他们的服务。

实战技巧一：精准的丢包检测是优化的前提

很多人一上来就问怎么降低丢包率，却忽略了检测环节。如果连丢包的具体情况都摸不清，后面的优化就是盲目的。

丢包检测的核心是序列号（Sequence Number）。每个RTP包都有一个递增的序列号，接收端通过检测序列号的连续性就能判断哪些包丢了。但这里有个坑——序列号是循环使用的，所以必须结合时间戳来判断。举个栗子，如果序列号从65535跳回0，但你收到的包的时间戳却比之前的还早，那可能是网络延迟导致的乱序，而不是丢包。

除了序列号，还有一个重要的指标是RTT（Round Trip Time）往返时延。RTT过高往往预示着网络拥塞，这时候丢包的风险也会增加。我个人的经验是，当RTT超过300ms的时候，就要开始警惕了；超过500ms，基本上可以预见丢包率的上升。

下面这个表格是不同丢包率区间对应的用户感知，大家可以参考一下：

丢包率区间	用户感知	可接受场景
0-1%	几乎无感知	所有场景均可接受
1%-3%	轻微卡顿，偶尔出现	语音通话可接受，视频通话轻微影响
3%-5%	明显卡顿，画面块状模糊	语音通话开始影响体验
5%-10%	严重卡顿，频繁卡死	用户体验极差，可能直接挂断
>10%	基本不可用	需立即干预

实战技巧二：拥塞控制算法要选对

拥塞控制是抗丢包的核心环节。简单来说，拥塞控制要做的事情就是：当网络拥塞时，发送端主动降低发送速率，给网络腾出空间；但又不能降得太厉害，否则会浪费带宽。

传统的拥塞控制算法比如BBR、Cubic、Reno，各有各的适用场景。BBR在高带宽、高延迟的网络环境下表现很好，但对小文件的传输效率不如Cubic。Reno太老了，不太适合现在的网络环境。

不过我想说的是，标准算法在实际RTC场景下往往不够用。为什么？因为RTC的数据特点和其他应用完全不同——它是持续的小包流，一个包可能就几十到几百字节，但要求极低的延迟。传统的拥塞控制算法设计时没考虑这种情况。

这也是为什么像声网这样的专业厂商都在自研拥塞控制算法的原因。他们会根据RTC数据的特点，在带宽估计的准确性、响应速度、稳定性之间找一个更好的平衡点。我了解到的是，声网的算法在弱网环境下能把丢包率控制在同业水平的50%左右，这个数据还是相当惊人的。

实战技巧三：前向纠错（FEC）不是万能药，但该用还得用

FEC是抗丢包的一把好刀，原理很简单：发送端在发送原始数据的同时，额外发送一些冗余数据。这样即使接收端丢了一些包，也可以通过冗余数据把丢失的内容恢复出来。

FEC的优势在于它的实时性——不需要像ARQ那样等待重传，所以延迟非常低。但它也有明显的缺点：会增加带宽消耗。如果你丢了10%的包，FEC可能需要额外发送10%到20%的冗余数据才能全部恢复。这笔开销到底值不值，要看具体的业务场景。

我个人的建议是：FEC要动态调整，别傻乎乎地一直开着最高档。网络好的时候，冗余度可以低一些；网络差的时候，再把冗余度拉上去。怎么判断网络好坏？可以用前面说的丢包率和RTT来动态调节。

另外，FEC的编码方式也有很多讲究。简单的XOR编码计算量小，适合低端设备；RS编码（里德-所罗门编码）纠错能力强，但计算量大；LDPC和Turbo编码性能最好，但对CPU和电量的消耗也最大。在移动端设备上，你得根据设备的性能来做取舍。

实战技巧四：重传策略要灵活

虽然RTC对延迟敏感，但适当的重传仍然是有价值的。关键在于哪些包该重传、重传几次、什么时候重传。

首先，不是所有包都值得重传。视频的I帧（关键帧）是必须保的，丢了I帧后面的P帧、B帧全都没意义；语音包丢失会导致短暂的静音，但连续的语音包丢了影响不大。我的经验是，I帧的优先级最高，FEC恢复不了的话必须重传；普通视频帧看情况；语音包能不重传就不重传，因为语音本身有冗余，丢几个包用户可能根本感觉不到。

其次，重传的时机很重要。传统的ARQ是等超时了再重传，但在RTC场景下，等超时黄花菜都凉了。更好的做法是早期重传——接收端发现自己丢了一个包，马上通知发送端重传，这时候原包可能还在发送端的缓冲区里没发出去呢，发送端直接重新发一份就行，延迟极低。

还有一点，重传的次数要设上限。很多新手会写一个while循环，丢包就重传，重传到成功为止。这在高丢包环境下会导致灾难——大量的重传请求会把本来已经拥塞的网络彻底堵死。我的建议是，单个包最多重传2到3次，再丢就放弃了，把资源留给后面的包。

实战技巧五：码率自适应是个技术活

码率自适应和抗丢包有什么关系？关系大了去了。简单来说，码率越高，抗丢包能力越弱；码率越低，抗丢包能力越强。所以在网络不好的时候，主动降低码率是保体验的有效手段。

码率自适应的核心是动态调整编码器的目标码率。但这事儿没那么简单，因为码率调整是有滞后性的——当你检测到丢包率上升再调低码率，可能已经太晚了。更糟糕的是，码率调低之后，视频质量会明显下降，用户可能反而觉得体验变差了。

那怎么办？一个是提前预判，根据RTT的变化趋势来预判网络状况，在丢包发生之前就开始调整。另一个是平滑调整，码率别一下子从2Mbps降到500kbps，分几步慢慢降，让用户几乎感觉不到变化。

还有一点很多开发者会忽略：分辨率和码率要匹配。有些产品为了宣传，1080p的分辨率只给2Mbps的码率，画面全是马赛克。这种情况下就算你把码率降一半降到1Mbps，用户也看不出来画质有什么变化，但抗丢包能力却实实在在提升了。所以合适的分辨率+充足的码率，比高分辨率+不足码率体验好得多。

实战技巧六：弱网下的体验保障策略

上面的技巧都是在网络条件尚可的情况下用的，但实际场景中总会有用户处于极差的网络环境下。这时候与其挣扎着保画质，不如换个思路——在弱网下主动降低体验，保证可用性。

具体怎么做？首先是分辨率降级，从1080p降到720p甚至480p，码率跟着降，帧率也可以从30fps降到15fps甚至更低。你可能会问，这不是开倒车吗？但你想，用户在弱网环境下，本来就没法享受高清画质，降级之后至少能保持通话流畅，总比卡成PPT强。

然后是帧率动态调节。其实帧率对带宽的影响很大——30fps变15fps，带宽直接砍一半。但很多人不知道的是，在低帧率下，人的主观感受反而可能更好。为什么？因为帧率越低，每帧的曝光时间越长，画面反而更清晰（运动模糊多了，但细节更清楚）。所以在弱网下，降帧率有时候比降分辨率效果更好。

还有一个技巧是关键帧间隔调整。正常情况下，关键帧（I帧）可能每2到10秒一个。但在强丢包环境下，把关键帧间隔缩短到1秒甚至更短，可以大大降低卡顿后的恢复时间——虽然码率会上升，但用户体验反而可能更好。

写在最后

丢包率的优化是一个系统工程，不是某一个环节做好了就能解决的。从网络探测、拥塞控制、FEC编码、重传策略到码率自适应，每个环节都要配合好，才能达到最佳效果。

如果你正在开发RTC产品，我建议先从可观测性入手——把丢包率、RTT、码率这些指标都监控起来，搞清楚自己的用户都在什么网络环境下使用产品，再针对性地优化。别一上来就抄别人的配置参数，每款产品的用户群体、使用场景都不一样，适合别人的方案不一定适合你。

对了，如果你在优化过程中遇到什么问题，也可以看看声网的技术文档。他们在这个领域深耕多年，积累了很多实战经验，对各种网络环境下的优化策略都有详细的解答。毕竟人家服务了全球超过60%的泛娱乐App，见过的大场面比我们多得多。

好了，今天就聊到这里。如果你有什么想法或者问题，欢迎一起交流。