NACK机制介绍

NACK（Negative Acknowledgment），即否定确认，是一种在数据通信和消息处理中用于保障可靠性的反馈机制。与表示“成功接收”的ACK（Acknowledgment）不同，NACK的核心思想是“只有当出现问题时才进行反馈”，例如数据包丢失或消息处理失败。

这种机制在不同的技术领域有着广泛的应用，主要可以分为两大类场景：消息队列和实时网络传输。

📨 在消息队列中的应用

在RabbitMQ等消息队列系统中，NACK是消费者（Consumer）向消息代理（Broker）发送的一个信号，明确表示消息消费失败。

当消费者在处理消息时遇到异常（如数据库连接失败、业务逻辑校验不通过等），它会发送一个NACK。收到NACK后，消息代理会根据预设的策略来处理这条失败的消息，主要有以下两种方式：

1. 重新入队（requeue = true）
   • 消息会被重新放回队列，等待再次被消费。
   • 适用场景：适用于处理临时性故障，例如网络瞬时抖动或服务短暂不可用。
   • 潜在风险：如果失败原因是持久性的（如消息数据本身有误），可能会导致消息被无限重试，消耗系统资源。
2. 进入死信队列（requeue = false）
   • 消息不会被重新投递，而是被发送到一个专门的“死信队列”（Dead Letter Queue, DLQ）中。
   • 适用场景：适用于处理无法通过重试解决的永久性错误，例如消息格式错误或业务上不允许的操作。这可以避免阻塞主队列，方便后续人工介入排查。

ACK与NACK对比

表格

 

维度	ACK (确认)	NACK (否定确认)
含义	消息已成功处理	消息处理失败
消息结果	从队列中永久删除	重新入队或进入死信队列
使用时机	业务逻辑成功执行后	业务逻辑执行异常后

🌐 在实时网络传输中的应用

在WebRTC等音视频直播场景中，NACK是实现低延迟、高可靠传输的关键技术之一。由于实时媒体流通常基于UDP协议（本身不保证可靠性），NACK机制被用来请求重传丢失的数据包。

其工作流程如下：

1. 发送与检测：发送方为每个媒体数据包分配一个序列号并发送。接收方通过监测序列号的连续性来发现丢包（例如，收到了序列号N和N+2，但没收到N+1）。
2. 发送NACK：一旦检测到丢包，接收方会立即向发送方发送一个NACK报文，其中包含了丢失数据包的序列号。
3. 触发重传：发送方收到NACK后，会从缓冲区中找到对应的数据包并重新发送给接收方。

NACK vs. TCP的ACK

与TCP协议中“每包必确认”的ACK机制相比，NACK在实时传输中具有显著优势：

• 减少反馈开销：在网络状况良好时，几乎没有反馈报文，节省了带宽。
• 降低传输延迟：接收方无需等待确认即可处理后续数据，发送方也只在收到NACK时才重传，避免了TCP因等待ACK而引入的延迟，更适合对实时性要求极高的音视频应用。

⚙️ 其他应用场景

NACK机制也存在于其他技术领域，例如在I2C这类硬件通信总线中。在I2C协议里，接收设备在成功接收一个字节后会拉低SDA线发送一个ACK位。如果接收方不拉低SDA线（即发送NACK），则表示它不希望再接收更多数据，这通常用于主机读取从机数据时，在接收完指定数量的字节后，发送NACK来通知从机停止发送。