在实时音视频领域，数据传输强调实时性，通常选择UDP协议可靠性就会降低。数据包发生丢包，就会引起解码失败，导致接收端发生卡顿影响用户体验。

抗丢包技术综述

实时音视频类应用需要保证数据传输的可靠性，需要应用自身实现抗丢包、抗抖动、抗拥塞算法。本文重点介绍抗丢包技术，下图为业界主要的抗丢包技术。

从图中可以看出，网络层弱网优化主要的技术包括前向纠错FEC、ARQ。FEC 恢复延时低，但会带来带宽消耗的增长。ARQ 恢复延时较大，带宽消耗下。在低延时场景下，可以充分利用ARQ 进行丢包恢复。

ARQ算法介绍

ARQ 是通过重传关键数据包来纠错的信道保护算法，包括三种形式：

1.Stop-and-waitARQ，发送端发送数据包后就停止并等待接收端的确认消息。

2.Go-Back-NARQ，发送端不需等待接收端的确认，直到收到接收端的重传请求。发送端除了重传被要求重传的数据包以外，还会把该数据包时间戳后面一批数据包全部重传一遍。

3.SelectiveRepeat ARQ，发送端不需等待接收端的确认；接收端只会有选择性地对关键的数据包发送非确认响应（NACK）包，要求重传。

前两种 ARQ传输实时性较低，不适用于实时音视频场景，实时音视频中主要采用NACK选择性丢包重传。

接收方在检测到数据包s2丢失后，会向发送方请求s2，等待1倍RTT时间后才会再次发起s2的重传请求。数据包的请求次数不会无限制持续发送，会有一个上限配置，这样做也会有以下几个问题。

1. 如果丢包很高，数据包的重传请求次数已达上限还没有重传成功，数据包恢复失败。
2. 如果媒体层已经播放到s3，还继续重传请求s2，即使收到s2媒体层也不会播放，重传包晚到。
3. 如果当前发生了丢包，数据包会有延时，媒体层的buff没有适配继续匀速播放，重传利用率还是会下降。
4. 当丢包率达到60%+，如果连续丢了8个，根据收到下一个seq传触发重传，就需要等到 320ms才能开始发送重传请求，会带来很大的延时。

NACK （SelectiveRepeat ARQ ）在实时音视频的实践

实时音视频领域，ARQ需要与媒体层进行联动，ARQ需要知道媒体层当前解码seq，媒体层需要知道当前的重传延时。 业界的优化思路主要包括如下策略。

重传与引擎联动 ，引擎同步当前解码seq、重传队列根据解码seq删除过期的待恢复seq。
主动重传，增加数据包达到预估，如果下一个数据超过一定时间还没有到来，就主动发起重传NACK请求。
重传恢复延时反馈引擎，网络层重传队列预估数据包重传回来需要的时间，将这个时间同步到引擎，用于调节jitterbuf水位，增加重传利用率。