为重新传输的数据包发送 TCP DUP ACK

Question

我有一个运行 Ubuntu 14.0.4 的客户端，我发现与此客户端节点的 TCP 连接存在问题。来自客户端的 TCP 确认被丢弃，服务器将数据包重新传输到客户端。客户端现在在收到重新传输时向服务器发送 DUP ACK。我的假设是 DUP ACK 被发送仅有的当收到一个乱序的数据包时，而不是当你重新发送一个已经收到的数据包时

这是屏幕截图：

有人知道为什么 TCP 会这样做吗？

Answer 1

重复 ACK 可以通过几种方式生成，通常是由于数据包丢失造成的：

• 发送段时，如果发送方未在配置的时间间隔内收到 ACK（200 毫秒很常见，但这通常是可配置的），它会重新传输该段，复制该段包含的 ACK。
• 接收时，收到意外的段号；导致接收方重新确认其预期的序列号。这通知发送方可能需要重新传输。接下来发生的事情取决于选择性确认，这超出了本回答的范围。
• 接收时，获取一个已经被ACK的段。

第一点和第三点是相关的。如果发送方未收到 ACK 的原因是 ACK 被小精灵吃掉，则基于计时器的重新传输将在重新传输时重新确认一个段。接收方已经确认了该段，将再次重复确认该段并等待下一个段。如果小精灵没有吃掉该重复确认，则发送方将继续传输。

就您而言，数据包的计时表明这里没有基于计时器的 dup-ACK 发挥作用。最大 RTT 为 14 毫秒。这表明发送方错误地重新传输，从而触发了 Dup-ACK。我见过这种行为是由于网络驱动程序存在缺陷，甚至在 TCP 卸载引擎的情况下是 NIC 固件造成的。不过，最近并不是所有情况都是如此。