我们正在检查一些客户端机器的 Wireshark 捕获，这些机器显示多个重复的 ACK 记录，然后触发重新传输和无序数据包。
这些显示在下面的屏幕截图中。.26 是客户端，.252 是服务器。
什么原因导致重复的 ACK 记录？
更多背景信息（如果有帮助）：
我们正在调查某个特定客户站点的网络吞吐量问题。从用户界面角度来看，问题在于尽管 1gbps WAN 连接利用率较低，但数据传输速度仍然很慢。
几乎所有客户端机器都有同样的问题，我们在 20 多台机器上进行了测试。我们确实发现了两台没有问题的机器。我们正在确定它们的配置有什么不同。我们确实注意到，在没有问题的两台机器中，我们最多只看到一个重复的 ACK 记录。有问题的机器通常有三个重复的 ACK 记录。一个显著的区别是，运行良好的机器都属于网络运营团队的成员，而其他所有机器都是“普通”员工的。这些机器应该是标准的，但网络管理员可能已经在他们的本地系统上进行了更改，这是我们正在研究的另一个方面。
我们尝试改变TcpMaxDupAcks服务器上设置，但我们真正需要的值是5，有效范围只有1-3。
服务器是 Windows Server 2003。客户端都是企业管理的 Windows XP。所有客户端（包括两个正在运行的客户端）都安装了 Symantec 防病毒软件。
在数百个客户站点中，这是唯一一个出现此问题的客户站点。
pathping即使是有问题的机器，也显示 RTT 为 56ms，并且数据包丢失率为 0/100。
谢谢，
山姆
答案1
注意：我假设此捕获是在客户端机器上进行的。
关于 TCP 排序的简要总结：TCP 在两个应用程序之间可靠地传送字节流。在这种情况下，“可靠”意味着，除其他事项外，TCP 保证永远不会向侦听应用程序传送无序数据。
通过使用序列号来实现按顺序、可靠的传输。每个流中的每个数据包都分配有一个 32 位序列号（请记住，TCP 实际上是两个独立的数据流，A->B 和 B->A）。如果 A 向 B 发送 ACK，则 ACK 字段中的值是 A 期望从 B 看到的下一个序列号。
从上图可以看出，服务器向客户端发送的 TCP 段至少丢失了一个。这三个重复的 ACK 是客户端试图触发快速重传当 TCP 发送方收到针对同一段数据的 3 个重复确认（即针对同一段数据的 4 个 ACK，该段并非最近发送的数据）时，它可以合理地认为被确认的段之后的段在网络中丢失了，因此立即进行重新传输。
在这种情况下，重新传输获得通过，并被 Wireshark 识别为无序。
正如所提到的乔奎蒂，数据包丢失通常是由拥塞引起的。也可能是由于 CRC 或链路上的其他错误（由于接口卡损坏、电缆松动等）造成的。我会查看路径上每个链路的统计数据，看看是否有任何链路使用率很高和/或出现大量错误。
如果您看不到任何明显的候选，请在路径上的多个点执行并发数据包捕获，以尝试隔离发生丢失的位置。
这里使用的是哪种 WAN 连接？是专用线路吗？MPLS VPN 链接？公共互联网上的 IPsec VPN？还是其他？
答案2
在隔离问题所在时，请将数据包转储视为症状之一... 打个比方，如果有人因胸痛走进医生办公室，医生不会花三个小时调查疼痛的性质。他花大约两分钟的时间，然后知道 95% 的原因是胃灼热或心绞痛... 同样，如果您看到重复的 ACK，请不要立即对跟踪进行彻底检查。
连接建立后，TCP 性能缓慢并不总是因为传输网络问题；有时是由于服务器 CPU 或磁盘限制……偶尔是因为客户端 PC 上的一些问题。我花了数周时间深入研究 wireshark 跟踪，最后还是放弃了，并很快找到了问题所在地铁或者查看其他主机指标，例如 CPU 和磁盘 I/O。
您的首要任务是证明这是网络问题还是主机级问题。专注于通过网络发送真实流量，并证明您是否正在排队/丢失/重新排序注意 1它;对于此类潜在网络问题，这始终是底线。
当吞吐量问题发生时，我会ping在客户端和服务器之间进行较长时间的采样（对我来说通常是一个小时）；您可以使用地铁或者ping 绘图仪 免费软件为此。如果你在某个跳点不断丢失数据包，并且之后所有的跳跃都会失去同样多或更多，那么您就有潜在的网络嫌疑。请记住，设备 ICMP 速率限制可能会导致某些跳数看起来丢失了数据包……这就是为什么您要从该跳数开始寻找趋势，然后寻找后续的趋势。
注意 1如果您重新排序流量，这将很快显示在专家信息wireshark 提供的字段
答案3
通过看到很多[重组 PDU 的 TCP 段]没有 ACK - 我认为这些 ACK 可能显示为[TCP 重复确认...]由于选择性确认（又名 SACK）行为。
例子：
客户端发送数据部分（...，0,1,2,3,4,5,6，...）
服务器确认（0），然后收到（2,4,3），然后是（5），然后是（6），但从未收到（1）
在上述情况下，服务器可以合法地选择首先确认 (2-4) 范围，然后确认 (2-5) 范围，然后确认 (2-6) 范围。在形成“(AB) 范围确认”数据包时，服务器必须在 TCP 标头中指定最后确认的部分 (0)。Wireshark 将范围确认 (SACK) 标记为[TCP 重复确认...]因为所有这些范围确认在 TCP 标头中都有相同的最后确认部分值（在您的情况下为 Ack=872619）。
答案4
在我看来，重复 ACK 和缓慢的网络性能相结合，听起来像是网络拥塞问题。查看网络上广播流量的量和速率。确保查看物理层和网络层广播以及多播。