NACK与ACK？何时使用另一种？

我个人甚至都不觉得需要ACK。如果我们只为丢失的数据包发送NACK（n），而不是为每个收到的数据包发送ACK，则速度更快。那么什么时候/在哪种情况下会使用ACK而不是NACK？

ACK的原因是，NACK根本不够。假设我向您发送了X段的数据流（为简单起见，假设为10）。

您的连接状况很差，仅接收第1、2、4和5段。您的计算机发送第3段的NACK，但没有意识到应该有第6-10段，并且不对这些段进行NACK。

因此，我重新发送了第3段，但随后我的计算机错误地认为数据已成功发送。

ACK可确保该段已到达目的地。

如果您希望应用程序处理数据的顺序和重传，则可以选择使用UDP之类的协议（例如，TFTP那样）。

归结为损失概率分布和流量模式。

以一条典型的无线链路为例，它具有稳定的10-30％的丢失率。如果确认每个接收到的帧（如802.11abg），您将快速检测到丢失帧的时间，因此您不会浪费时间等待超时。

如果您改为使用NAK，则将依赖于流量模式：-如果发送单个请求数据包并期望得到答案，并且该请求丢失，那么如果您没有收到请求，则必须超时回答。-如果您只是向几乎静音的收件人发送数据包流，那么仅当收件人接收到下一个数据包时才接收NAK是可以接受的。但这意味着收件人必须对数据包重新排序，并且发送方必须跟踪已发送的大量积压消息。

（猜测802.11n选择哪种解决方案？两者都有。接收器发送已接收到的帧的可变长度位图）

现在以一个典型的Internet网络为例：您有接近0％的数据包丢失，直到发生一些不良情况为止，并且在遵循一定的指数分布规律的一定时间内，您有接近100％的数据包丢失，从200ms中断到一分钟零半。

在无损网络中，唤醒每个数据包似乎毫无意义，除非您考虑断开链路的情况：在可能延长的时间内将不会收到ACK或NACK，并且接收者通常在链路断开之前不会发送任何内容恢复。

如果使用ACK，发件人将停止发送并保留其积压，直到恢复链接为止。如果改用NACK，则接收者最终可能会告诉您，很长一段时间以来，它一直没有收到从发送者积压中丢失的数据包，并且该连接基本上是不可恢复的。

ACK在滑动窗口协议中很有用，它们使发送器A知道发送的数据已被远程B接收。发送器A随后可以继续发送下一个数据-直到其发送窗口已满（发送到远程但尚未发送的数据）为止确认）。

ACK比NAK更重要。如果B未收到A发送的数据包/块，并且B通过某种方式检测到数据包/块丢失，则NAK仅允许更快的恢复。

设计仅支持使用ACK进行可靠传输和流控制而不使用NAK的协议是完全可行的（在任何情况下，如果传输器未收到ACK，则由传输器进行重传）。

我想在这里添加的最重要的一点是，在TCP中，我们不会为每个接收到的数据包发送ACK。

但是，仅针对最后接收的包发送ACK。

如果我错了，请纠正我。