ACK、NACK、 REX在面试或者网络通信的时候，我们可能经常听到和遇到。今天就来详细介绍一下ACK、NACK、 REX。

认识ACK、NACK、 REX

ACK：Acknowledgement，它是一种正向反馈，接收方收到数据后回复消息告知发送方。
NACK：Negative Acknowledgement，则是一种负向反馈，接收方只有在没有收到数据的时候才通知发送方。
REX：Retransmission，重传，当发送方得知数据丢失后，重新发送一份数据。

那么ACK、NACK、 REX又能为我们解决什么问题了，下面一一介绍ACK、NACK、 REX在网络通信中担任的角色以及所能解决的问题。

使用ACK、NACK、 REX解决常见问题
1：判断接收方数据包是否已经丢失:
编号，为每一个 packet 都打上一个序列号（Seq number），接收端发现序列号跳变/缺失，则可以判断数据包丢失了。
这就是为什么 TCP 协议的包头（packet header）里面要定义一个序列号字段的原因（如图红色标记）：

本文福利，免费领取C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，编解码，推拉流，srs）↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

扩展一下，我们再看看 UDP 协议的包头（packet header）的定义：

可以看到，UDP header 没有用任何字段来标识序列号（Seq number），由此可见，UDP 是一个完全不关心是否丢包的传输协议。

2:判断发送方数据包是否已经丢失

有几种常见的方案，这里先简单介绍如下

1.停等协议
发送方每次只发送一个包，同时启动一个定时器。如果定时器超时依然没有收到这个包的 ACK，则认为丢包，重传这个包。如果收到 ACK，则重置定时器并发送下一个包。当也会存在问题，比如：丢包的判断和传输效率非常低。

接收方通常采用积累确认模式，即不必对每一个包逐个发送 ACK，而是在连续收到几个包后，对顺序到达的最后一个包序号发送 ACK，表示：这个包及之前的所有包都已正确收到了。

注意：

积累确认模式的缺点：乱序比较严重的网络下，效率非常低，部分已经送到但没有按照顺序送达的包也必须重传。改进方案：选择性重传（注：KCP/SRT 协议有实现）：对于顺序的包，发送积累确认；跳跃的包，发送 ACK；发送端只重传真正丢失的数据包。

2.连续 ARQ 协议 & 滑窗协议
发送方维持着一个一定大小的发送窗口，位于发送窗口内的所有包可以连续发送出去，中途不需要依次等待对方的 ACK 确认。

积累确认模式的缺点：乱序比较严重的网络下，效率非常低，部分已经送到但没有按照顺序送达的包也必须重传。

改进方案：选择性重传（注：KCP/SRT 协议有实现）：对于顺序的包，发送积累确认；跳跃的包，发送 ACK；发送端只重传真正丢失的数据包。

3.快速重传
使用 ACK 机制的传输协议，通常在发送端等到某个数据包的 ACK 超时后，才会重传数据包，不够及时。快速重传：如果接收端接收到了序号跳跃的数据包，则立即给发送方发送最后一个连续的数据包的 ACK（重复确认）。如果发送端收到连续 3 个重复确认，则认为该 ACK 的下一个数据包丢失了，并立即重传该丢失的数据包。

4.NACK
接收方定时把所有未收到的包序号通过反馈报文通知到发送方进行重传。带来的改进：减少的反馈包的频率和带宽占用，同时也能比较及时地通知发送方进行丢包重传。

3. 重传超时的计算规则？

RTO：重传超时时间（Retransmission Timeout），它是发送端用来判断数据包丢失和执行重传的最重要的一个参数。

很明显，它应该是一个随网络传输的 RTT（往返时间）而变化的值，理想情况下，RTO 的值不小于 RTT 即可（从数据包发送到对方的 ACK 到达的最短时间），实际情况下，RTT 变化是非常频繁的，每一次传输的 RTT 可能都不一样，如果粗暴地设置 RTO = RTT 则一定会导致重传过度频繁。

因此 TCP 协议采用的 RTO 计算方法是：

基于多次 RTT 测量，给出一个平滑后的 RTT 预估值：SRTT（Smoothed Round Trip Time）
RTO = SRTT + 某种系数（防止抖动的阈值）
进一步，系统级别设置 RTO 的下限为 100ms 或 200ms，防止异常值
更进一步，对于重传包的 RTO，加上一个退避算法，比如，每重传一次，则 RTO = 2 RTO 这样的方式来减少对一个包进行频繁的重传
`注意：`关于重传包 RTO 的退避策略，KCP 经过实验证明，RTO 的退避系数使用 1.5 倍的效果比 2 倍的效果更好。