什么导致重复的ACKlogging?

我们正在审查Wireshark从几个显示多个重复ACKlogging的客户端机器捕获,然后触发重传和乱序数据包。

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

在这里输入图像描述

什么导致重复的ACKlogging?

更多的背景,如果有帮助:

我们正在调查一个特定客户端的networking吞吐量问题。 从用户界面的angular度来看,问题是数据传输缓慢,尽pipe1Gbps广域网连接利用率不足。

几乎所有的客户机都有相同的问题,在20多台机器上进行testing。 我们确实find了两台没有问题的机器。 我们正在识别configuration中的不同之处。 我们注意到,在没有问题的两台机器中,我们只看到了最多一个重复的ACKlogging。 有问题的机器通常有三个重复的ACKlogging。 一个显着的区别是,工作正常的机器都属于networking运营团队的成员,其他所有的机器都是“正规”的员工。 机器应该是标准的,但是networkingpipe理员可以在本地系统上做出改变,这是我们正在研究的另一个方面。

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

服务器是Windows Server 2003.客户端都是企业pipe理的Windows XP。 所有客户端(包括两个正在运行的客户端)都安装了Symantec防病毒软件。

这是展示此问题的数百个客户端中的唯一一个。

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

谢谢,

山姆

注意:我假设这个捕获是在客户机上进行的。

关于TCPsorting的简要总结:TCP在两个应用程序之间可靠地传送字节stream。 在这种情况下,“可靠”意味着除了别的以外,TCP保证永远不会将乱序数据传送给侦听应用程序。

按顺序,可靠的交付是通过使用序号来实现的。 每个数据包中的每个数据包都分配了一个32位的序列号(请记住,TCP实际上是两个独立的数据stream,A→B和B→A)。 如果A向B发送ACK,则ACK字段中的值是下一个序列号A期望从B看到的值。

从上面看,至less有一个从服务器发送到客户端的TCP段丢失了。 三个重复的ACK依次是客户端尝试触发快速重传 。 当一个TCP发送方收到同一段数据的3个重复确认(即同一个段的4个ACK,这个数据不是最近发送的数据段)时,可以合理地假定该段之后紧接着的段被丢失在networking中,并导致立即重新传输。

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

正如joeqwerty所提到的,丢包最常见的原因是拥塞。 这也可能是CRC或链接上的其他错误的结果,由于接口卡不良,电缆松动等原因,我会查看path上每条链路的统计数据,看是否有高度利用率和/或正在经历大量的错误。

如果您看不到任何明显的候选项,请在path上的多个点执行并发数据包捕获,以尝试隔离丢失发生的位置。

这里使用的是什么样的WAN连接? 这是专线吗? MPLS VPN链路? 通过公共互联网的IPsec VPN? 别的东西?

当你把问题隔离在哪里的时候,把数据包转储看作是其中一个症状……比方说,如果有人走进医生的办公室,胸部疼痛,医生不会花三个小时的时间来调查性质疼痛。 他花了大约两分钟的时间,然后知道95%的原因是胃灼热或心绞痛…同样,如果你看到重复的ACK,不要鼠标马上洞察杂草的痕迹。

连接build立后,TCP性能慢并不总是因为传输networking问题; 有时候是因为服务器CPU或磁盘的限制而导致的……偶尔会因为客户端PC上的某些问题而出现这种情况。 我已经追逐我的尾巴数周来挖掘wireshark痕迹的杂草,只是放弃,并与mtr相对较快地find问题,或通过查看其他主机指标,如CPU和磁盘I / O。

您的首要任务是certificate这是networking问题还是主机级问题。 专注于通过您的networking发送真实的stream量,并certificate您是否在排队/丢失/重新sorting注意1 ; 永远是这样一个潜在的networking问题的底线

在吞吐量问题发生的时候,我会在客户端和服务器之间进行长时间的ping取样(通常是一个小时) 您可以使用mtr或ping绘图仪免费为此。 如果你一直在丢包,而所有的跳都是松散的 ,那么你就有一个潜在的networking疑犯。 请记住,设备的ICMP速率限制可能会导致一些跳跃出现,他们松散的数据包…这就是为什么你要寻找从该跳开始,以及那些后续的趋势。


注1如果您重新订购stream量,那么在wireshark提供的专家信息字段中会显示相当快

通过看到很多没有ACK的[重新组合PDU的TCP段] – 我会说,由于select性确认(aka SACK)行为,这些ACK可能显示为[TCP Dup ACK …]

例:

  • 客户端发送数据部分(…,0,1,2,3,4,5,6,…)

  • 服务器acked(0),然后收到(2,4,3),然后(5),然后(6),从来没有得到(1)

在上述场景中 – 服务器可以先合理selectack(2-4)范围,然后是(2-5)范围,然后是(2-6)范围。 在形成“(AB)范围ack”分组时,服务器必须指定TCP报头中的最后一个部分(0)。 Wireshark将范围确认(SACKs)标记为[TCP Dup ACK …],因为所有这些范围确认在TCP头部(Ack = 872619,在你的情况下)中具有相同的最后一个部分值。

重复的ACK与networking性能的缓慢结合听起来像是一个networking拥塞问题。 查看networking上广播stream量的数量和速率。 请务必查看物理层和networking层广播以及多播。