由 dawei 我们正在审查来自少数客户端计算机的Wireshark捕获,这些客户端计算机显示多个??重复的ACK记录,然后触发重新传输和无序数据包.
这些显示在以下屏幕截图中. .26是客户端,.252是服务器.
什么原因导致重复的ACK记录？
更多背景,如果它有帮助：
我们正在研究某个特定客户站点的网络吞吐量问题.从用户界面的角度来看,感知问题是尽管未充分利用的1gbps WAN连接,数据仍在缓慢传输.
几乎所有客户端计算机都有相同的问题,在20多台计算机上进行了测试.我们确实找到了两台没有问题的机器.我们正在确定其配置中的不同之处.我们注意到在没有问题的两台机器中,我们最多只能看到一条重复的ACK记录.出现此问题的计算机通常具有三个重复的ACK记录.一个值得注意的区别是,工作正常的机器都属于网络运营团队的成员,而所有其他机器都属于“常规”员工.这些机器应该是标准的,但网络管理员可以对其本地系统进行更改,这是我们正在研究的另一个方面.
我们尝试更改服务器上的TcpMaxDupAcks设置,但我们真正需要的值是5,有效范围只有1-3.
服务器是Windows Server 2003.客户端都是企业管理的Windows XP.所有客户端(包括两个工作客户端)都安装了Symantec防病毒软件.
这是数百个展示此问题的唯一客户端站点.
pathping显示56ms RTT和一致的0/100数据包丢失,即使是问题机器.
谢谢,
山姆
注意：我假设此捕获是在客户端计算机上进行的.
关于TCP排序的简短摘要：TCP可靠地在两个应用程序之间提供字节流.在这种情况下,“可靠地”意味着TCP保证永远不会将无序数据传递给监听应用程序.
有序,通过使用序列号实现可靠的交付.每个流中的每个分组被分配32比特序列号(记住TCP实际上是两个独立的数据流,A-> B和B-> A).如果A向B发送ACK,则ACK字段中的值是A期望从B看到的下一个序列号.
从上面可以看出,从服务器发送到客户端的至少一个TCP段丢失了.顺序中的三个重复ACK是客户端尝试触发fast retransmit.当TCP发送器收到同一条数据的3个重复确认时(即同一段的4个ACK,这不是最近发送的数据) ),它可以合理地假设紧接在被确认的段之后的段在网络中丢失,并且导致立即重新传输.
在这种情况下,重新传输通过,并由Wireshark识别为无序.
如joeqwerty所述,数据包丢失通常是由拥塞引起的.由于接口卡坏,电缆松动等原因,它也可能是由于链路上的CRC或其他错误造成的.我会查看路径上每条链路的统计信息,看看是否有高度利用和/或正在经历大量的错误.
如果您看不到任何明显的候选者,请在路径上的多个点执行并发数据包捕获,以尝试隔离丢失发生的位置.
这里使用什么样的WAN连接？这是专线吗？ MPLS VPN链接？ IPsec VPN通过公共互联网？别的什么？