什么导致重复的ACKlogging？

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

关于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层广播以及多播。