![什么原因导致重复的 ACK 记录?](https://linux22.com/image/548315/%E4%BB%80%E4%B9%88%E5%8E%9F%E5%9B%A0%E5%AF%BC%E8%87%B4%E9%87%8D%E5%A4%8D%E7%9A%84%20ACK%20%E8%AE%B0%E5%BD%95%EF%BC%9F.png)
我们正在检查一些客户端机器的 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 和缓慢的网络性能相结合,听起来像是网络拥塞问题。查看网络上广播流量的量和速率。确保查看物理层和网络层广播以及多播。