是什么导致重复的ACK记录？

19

我们正在审查来自几台客户端计算机的Wireshark捕获，这些计算机显示了多个重复的ACK记录，这些记录随后触发了重传和乱序数据包。

这些显示在以下屏幕截图中。.26是客户端，.252是服务器。

在此处输入图片说明

是什么导致重复的ACK记录？

更多背景，如果有帮助的话：

我们正在调查一个特定客户端站点上的网络吞吐量问题。从用户界面的角度来看，人们意识到的问题是，尽管没有充分利用1gbps的WAN连接，数据仍在缓慢传输。

几乎所有客户端计算机都存在相同的问题，并在超过20台计算机上进行了测试。我们确实找到了两台没有问题的机器。我们正在确定其配置有何不同。我们确实注意到，在两台没有问题的机器中，我们最多只能看到一个重复的ACK记录。有问题的计算机通常具有三个重复的ACK记录。一个显着的区别是，运行良好的计算机全部属于网络运营团队的成员，而其他所有计算机则用于“正规”员工。这些机器应该是标准机器，但是网络管理员可以在其本地系统上进行更改，这是我们正在研究的另一方面。

我们尝试更改服务器上的TcpMaxDupAcks设置，但我们真正需要的值为5，有效范围仅为1-3。

服务器是Windows Server2003。客户端都是企业管理的Windows XP。所有客户端（包括两个正常运行的客户端）均已安装Symantec Anti-Virus。

这是数百个出现此问题的唯一客户端站点。

pathping 即使有问题的机器也显示出56ms的RTT和一致的0/100数据包丢失。

谢谢，

山姆

windows-server-2003 windows-xp tcp wireshark

— 山姆
source

两个端点之间是哪种路由交换硬件？

— SpacemanSpiff

@SpacemanSpiff，有一台Cisco ASR 1006路由器。

— 山姆

IT人员和客户是否在同一交换设备上？您能否将他们的一台机器带到IT领域，然后看问题就解决了？

— SpacemanSpiff

Answers:

25

注意：我假设此捕获是在客户端计算机上进行的。

关于TCP排序的简要概述：TCP在两个应用程序之间可靠地传递字节流。在这种情况下，“可靠”意味着，TCP保证永远不会将乱序的数据传递给侦听应用程序。

通过使用序列号，可以有序地实现可靠的传递。每个流中的每个数据包都分配有一个32位序列号（请记住，TCP实际上是两个独立的数据流，A-> B和B-> A）。如果A向B发送ACK，则ACK字段中的值是A期望从B看到的下一个序列号。

从上面看来，似乎丢失了从服务器发送到客户端的至少一个TCP段。客户端依次尝试按顺序重复这三个重复的ACK，以触发快速重传。当TCP发送方收到同一数据段的3个重复确认（即，同一段的4个ACK，不是最近发送的数据）时，可以合理地假定紧接被确认段之后的段丢失了在网络中，并导致立即重新传输。

在这种情况下，重新传输通过，并被Wireshark识别为乱序。

如joeqwerty所述，数据包丢失通常是由拥塞引起的。这也可能是由于接口卡损坏，电缆松动等导致的CRC或链接上的其他错误的结果。我会查看路径中每个链接的统计信息，以查看是否被充分利用和/或遇到大量错误。

如果看不到任何明显的候选对象，请在路径上的多个点执行并发数据包捕获，以尝试找出发生丢失的位置。

此处使用哪种WAN连接？是专线吗？MPLS VPN链接？通过公共Internet的IPsec VPN？还有吗

— 穆拉里·苏里亚（Murali Suriar）
source

感谢您的意见。没错，数据包捕获来自客户端。如果我理解您的意思，重复的ACK并不是客户端做错了什么，而是实际上是来自客户端的触发，它没有收到其他记录（在ACK之后的记录）。那是对的吗？我可以在客户端PC上调查哪些事情会导致这种情况？如果这不是客户端PC问题，为什么会在某些客户端而不是其他客户端上始终显示它？

— 山姆

WAN是位于美国东海岸和美国中西部三个站点之间的“两点对点电路”。

— 山姆

没错 DUPACK是丢包的征兆。至于为什么该问题会在某些客户而不是其他客户上发生，您需要弄清楚受影响客户的共同点。他们都在同一个办公室吗？通过通用的网络基础设施？（交换机还是链接？）。值得做的一件事是在每台受影响的计算机上使用mtr（或pathping在Windows上）并查看服务器路径上是否存在任何常见的跃点，这些跃点似乎正在经历数据包丢失。您是否具有可用于查看交换机端口数据的网络监视系统？

— Murali Suriar

4

当您隔离问题所在时，可以将数据包转储视为症状之一...作为类比，如果有人因胸痛而走进医生办公室，医生将不会花费三小时来研究疼痛。他花了大约两分钟的时间，然后知道95％的原因是胃灼热或心绞痛...同样，如果您看到重复的ACK，请不要马上在痕迹的杂草上钻洞。

建立连接后，TCP性能下降并不总是由于传输网络问题引起的；有时是由于服务器CPU或磁盘限制而引起的，有时是由于客户端PC上的某些问题引起的。数周来，我一直追着我的尾巴，挖出Wireshark痕迹的杂草，只是为了放弃并通过mtr或通过查看其他主机指标（例如CPU和磁盘I / O）来相对较快地发现问题。

您的首要任务是证明这是网络问题还是主机级问题。专注于通过网络发送实际流量，并证明您是否正在排队/丢失/重新订购^{Note 1}。始终是此类潜在网络问题的底线。

我会做一个ping采样的时间在客户端和服务器，而能力的问题正在发生的事情之间长时间（通常为我一个小时）; 您可以为此使用mtr或ping绘图仪免费软件。如果您始终在某个跃点上丢失数据包，而之后所有跃点都失去了更多或更多的跃迁，那么您就有潜在的网络可疑之处。请记住，设备ICMP速率限制会导致某些跃点出现，从而导致数据包丢失……这就是为什么您要查找从该跃点开始的趋势，以及随后的趋势。

^注意1如果您要重新排序流量，它将在wireshark提供的专家信息字段中很快显示

— 迈克·彭宁顿
source

同意默认责怪网络不是一个好方法。在整个堆栈中进行检测始终是一种好习惯。但是，在这种情况下，DUPACK，乱序和重传的段似乎确实表明了两个端点之间的某种网络丢失。

— Murali Suriar

@Murali Suriar，让我们谈谈您的断言（这很有可能是对的）……那么接下来呢？您必须找出为什么丢包的原因。我们IT人员神秘地爱上了wireshark我们喜欢看显微镜太长时间的观点。我要说的是，快速浏览一下pcap，之后您最好花一些时间来测试数据包丢失，CPU周期和磁盘I / O，而不是深入研究TCP的历史。有时间可以这样做，但通常不在此分析阶段。

— Mike Pennington

@Mike同意，这就是为什么我建议为该路径查找设备的错误/使用信息的原因。除了可及性之外，我不是基于ICMP的诊断的忠实拥护者。如您所说，速率限制和错误配置的ACL /防火墙会使它不可靠。尽管在企业网络中（听起来像这样），MTR通常可以为您指明正确的方向。MTR的另一个问题是，它通常仅指向一个问题。完全有可能沿路径存在多个故障，只有修复第一个故障才能找到。

— Murali Suriar

我们不同意，带有TTL步进的ICMP并不是万能药，并且可能存在多个故障。但是，尽管存在防火墙和负载平衡器的所有缺陷，但ICMP是我们拥有的最好的远程诊断工具，除非您可以在有问题的特定应用程序端口上运行主机级的检测TCP / UDP会话...即使这样，您也只能说，此套接字正在重传很多...但是为什么呢？在70％的时间内，我退出工作mtr还是很困难，并且在过去15年中，我一直以相同的方式解决问题。一旦我专注于特定设备，我们就可以看看投递计数器

— Mike Pennington

1

@Sam：关于解决网络问题的一点：每个网络都有“问题”。关键是确定这些问题是否导致性能和/或连接性问题。您会在每个网络上发现重复的ACK，TCP重传，广播，错误协议等。您应该关注重复ACK的数量以及发送重复ACK所涉及的主机，以确定这是否确实是更大问题的征兆，或者仅仅是网络的自然运行。如果我看到1000个数据包中有5个重复的ACK，我不会再考虑了。

— joeqwerty

3

通过看到很多没有ACK 的[重组PDU的TCP段] -我说由于选择确认（aka SACK）行为，这些ACK可能显示为[TCP Dup ACK ...]。

例：

客户端发送数据部分（...，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 Dup ACK ...]，因为所有这些范围确认在TCP标头中具有相同的最后确认部分值（在您的情况下为Ack = 872619）。

— 杜布罗夫
source

1

对我来说，重复的ACK和缓慢的网络性能听起来像是网络拥塞问题。查看网络上广播流量的数量和速率。确保查看物理层和网络层的广播以及多播。

— 乔伊维蒂
source

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.

Licensed under cc by-sa 3.0 with attribution required.