右上角是大盘的数据，可以发现 FEC 整体会有明显攀升，这里就是常态 FEC 的一个效果。另外对于在这里的分组长度的确定，分组要兼顾整个系统延迟，以及你的系统规格要兼顾怎样的边界和指标，如果不通过大数据运营，你永远不知道分组多少是合适的。通过前面讲的大数据 ABTest 运营方式把数据放在真实用户的全网进行验证，找到合适分组、冗余倍率公式、控制相关的策略。下面这两张图就可以看到最终的结果，看似还是很不错的，FEC 恢复率从 95% 恢复到高的接近 99%。
网络是有突发丢包的，可能时不时的来一下，或者丢包前后有一些持续的小丢包。FEC 控制策略上的拖尾时间窗口的方式，可以 Cover 住这一类连续丢包。
如何做音频 ARQ 抗抖动处理
ARQ 也是一个比较成熟的技术，我们在做的过程中也是踩过一些坑的，所以今天也非常愿意跟大家分享。
如果这块做不好的话，实际上会有副作用，宁可不要这功能。在 QQ 时代，一个典型例子是应用层有个逻辑，在基于 RTT 小于多少毫秒的基础情况下，给音频数据包进行重传，主观上认为只要是把丢包重新传回来，这个效果肯定是好的，至于底层的 TRAE 音频引擎怎么处理，实际上不太关心。但这个是不够的，这就是今天讲的红箭头 5 和 6 比较细节的地方，重传算法主要关注的是对于缺失的数据包重传间隔以及最大重传次数，但是数据包重传回来的时候，这个包怎么合理利用它。同时，播放器则是按照时间轴不停播放的，数据没有来，是否还不停地要呢？这块有一个正反馈和负反馈的过程。
另外如果仅仅是重传数据包，没有记录或者管理数据包从第一次到最后重传了多少次，这个包重传成功总共消耗了多少时间，这个环节是非常有价值的，包括许多开源算法包括 WebRtc 这一块的逻辑也是没有做的。通过对重传数据包所消耗的时间管理，可以精细化的去控制接下来我们会讲的 Jitter Buffer 之前的配合，比如我们有了这个重传消耗时长，我们就可以知道让 Jitter Buffer 未来的一段时间等待多久，另外对于已经解码成功的数据随着时间轴实时的在播放，如果时间轴播放到了某些缺失的数据包应该出现的地方，某些数据包再重传回来也不要了，这时候也要及时去更新重传列表，这也是重传效率的问题。
怎么样去精细化升级算法，做了两方面的工作。一般重传两个关键因素，一个是重传次数，再一个是重传间隔。重传间隔首先不能小于 RTT，一般都是 1 点几倍率的 RTT 时间间隔要一次包，在一个 RTT 时间去等它，如果不来再去要。然后还会考虑一个基于：“截断二进制指数退避“的算法概念。比如说 20%，理论上重传几次就够了，30%、40%、50% 甚至 80% 重传几次，如果超过这个次数的上限，再结合比如说带宽预测状态或者 RTT 值的情况，及时中止这种行为，这种行为可以避免系统本身因为算法本身不合理造成的流量雪崩。
音频的抗抖动处理
接下来就是抗抖动。抖动怎么理解呢？有些网络情况下不太容易发生，在网络拥塞 Congestion Control 那块，我们在介绍 GCC1 和 GCC 算法的时候解释了 Jitter 的计算方法，以及它出现的一些原因。在使用 Wifi 网络的情况下经常有五六百毫秒抖动非常正常，所以如果对抗网络抖动也是一个非常关键的功能。从 GIPS 开源之前，NetEQ（Net equalizer）就被作为引擎内部的王牌特性，被用来对抗各种情况网络抗延时控制，以及抗击抖动的最佳算法实践。它开源以后，大家基于此的技术进行追踪、优化都是受益匪浅的。
看左上角这个网络真实来包的情况，右下角则是期望通过抗抖处理送给解码器均匀的数据包，理想的包是这样顺序且均匀间隔的数据包，但现实总是不美好的，来的包总是非常不均匀，甚至几百毫秒没有数据，然后接下来突发几秒数据一起到来。这个 Jitter Buffer 的作用就是，尽量去维持合适的数据包水位，这个水位也最终会影响到整个系统的端到端延时，水位太低或者太高都是不行的，太高的话我们及时把这个降下来，太低我们要及时把它调整到认为合理的一个位置。合理的水位可以对抗网络突发，播放端则因为 Jitter Buffer 能够保持合理水位，拥有稳定持续的数据源用来播放，这对于用户最终听到完整和高质量的声音都是非常有帮助的。
