#1 楼
ACK的原因是NACK根本不够。假设我向您发送了X段的数据流（为简单起见，假设为10）。第3段的NACK，但没有意识到应该有第6-10段，并且不对这些段进行NACK。 。ACK可确保段已到达目的地。
如果您希望应用程序处理数据顺序和重新传输，则可以简单地选择像UDP这样的协议（例如，像TFTP一样）。
评论
好答案。但是我们不能仅将第一个数据包指定为特殊数据包-它会包含它要发送的段数。
–哈里
15年6月24日在22:51
仍然留下发送者不知道是否接收到数据的问题。在此过程中没有ACK的情况下，如果发送方没有听到任何回音，则即使整个数据流丢失了，也仅需假设已接收到所有数据。 ACK确保已接收到数据。
– YLearn♦
15年6月24日在23:04
#2 楼
归结为丢失概率分布和流量模式。以典型的无线链接为例，其丢失率稳定在10％至30％。如果确认每个接收到的帧（例如802.11abg），您将快速检测到丢失帧的时间，因此不会浪费时间等待超时。
如果您要去NAK，您将取决于流量模式：
-如果您发送单个请求数据包并期望得到答案，而该请求丢失，那么您将必须超时，如果您没有得到答案，则该超时将到期。 br />-如果您只是将数据包流发送给几乎是静音的收件人，那么仅当收件人接收到下一个数据包时才接收NAK是可以接受的。但这意味着接收方必须对数据包进行重新排序，并且发送方必须跟踪其已发送的大量消息积压。（猜测802.11n选择哪种解决方案？两者。接收方发送一个接收到的帧的可变长度位图）
现在使用一个典型的Internet网络：您的数据包丢失率接近0％，直到发生一些不良情况，而您的数据包丢失率接近100％在一段时间内遵循某种指数分布规律，从200毫秒的中断到一分半钟。已被切断：您将不会在很长的一段时间内收到ACK或NACK，并且在链接恢复之前，接收方通常不会发送任何内容。并保留其积压，直到恢复链接。如果改用NACK，则接收者最终可能会告诉您，很长时间以来，它一直没有收到从发送者的积压清单中掉落的数据包，并且连接基本上是不可恢复的。
#3 楼
ACK在滑动窗口协议中很有用，它们使发送器A知道发送的数据已被远程B接收。发送器A随后可以继续发送下一个数据-直到其发送窗口已满（发送到远程但尚未发送的数据）为止确认）。ACK比NAK更重要。在B未收到A发送的数据包/块，并且B通过某种方式检测到数据包/块丢失的情况下，NAK仅允许更快的恢复。
设计仅支持ACK且不使用NAK的可靠传输和流控制协议是完全可行的，而无需NAK（在发射机未收到ACK的情况下，由发射机进行重发，无论如何都需要重发机制） ）。
#4 楼
我想在这里添加的最重要的一点是，在TCP中，我们不会为每个接收到的包发送ACK。 br />如果我错了，请纠正我。评论
在一定程度上这是正确的。例如，仅设置了ACK或RST标志的段不需要ACK。另外，如果使用了延迟的ACK，则每个段可能都没有ACK，但是通常这要求为每个其他段发送ACK。然而，许多TCP连接不会使用延迟的ACK，并且会为每个承载数据的段发送ACK。
– YLearn♦
17年8月24日在19:57
评论
您能否给我们更多关于您所谈论内容的背景信息？您是在一般性地询问还是在询问TCP，还是？与TCP，UDP或任何其他特定区域无关的常规联网问题。