在这种情况下导致此问题的原因（可能是丢包）

我试图诊断一个networking相关的问题 – 请在提出答案之前理解这些要点（如果需要更多的信息，我会添加任何人提出的问题）。

我们有一台服务器专用networking（5台应用服务器，4台数据库服务器，其他几台服务器），这些服务器之间似乎正在遭受数据包丢失
我可以看到这发生在wireshare上 – 有很多TCP重传，TCP_Out-of-Order，TCP DupACK，我也想到了一些TCP_ZeroWindow包。
在IP协议上似乎有很多错误的校验和
我认为networking适配器有一个非常稳定和高（90-100％）的负载，由于这个数据包丢失造成额外的重试
随着该networking上的外部请求（对应用服务器）的增加，networking性能下降
应用程序服务器在由外部请求使用时会生成自己的stream量
外部请求通过核心路由器，networking位于自己的网段上
这个高负载在1-2天后“神奇地”消失了，我神奇地说，就像我们在负载下降的时候只在适配器上进行监视一样，尽pipe数量较less，但仍然存在包丢失。
没有指向受损的服务器。
不幸的是，我们没有物理访问任何硬件
我们不能破坏当前的服务

鉴于上述情况，确定造成数据包丢失的最佳方法是什么（我们期望它是一个pipe理型交换机）。

是否有任何软件可以为我们提供经validation据，certificate导致问题的原因？

提前致谢

根据我的经验，Wireshark可以在使用硬件TCP-Offload的接口上返回不可靠的结果。重复数据包是其中的一个症状。

这就是说，如果你使用span /镜像端口来抓取你的捕获重复的电线是一个重大的问题。

重复的ACK，乱序和重发是某些TCP堆栈在行为上不正确的信号。关联哪些networking节点容易引发错误将有助于隔离哪些主机需要进一步调查。跨度/镜像端口捕获和特定节点上的wireshark会话之间的networking捕获的任何差异都有助于突出显示可能发生的问题。如果您看到一些问题，请调查更新networking驱动程序，因为这些问题通常是解决这类问题的最简单的解决scheme（Broadcom对此很可惜）。其次，更新网卡的固件也可以提供帮助。

如果所有的东西都看起来很健康的话，那么只要有太多的stream量可以处理，你就可以看到TCP正常地大肆渲染。

TCP零窗口也是一个不健康的TCP / IP协议栈的标志，尽pipe根据我的经验，当两个不同的TCP / IP协议栈不能相互协调时，有时会出现这种情况。例如Windows 2008和Linux空间中某些较旧的TCP / IP堆栈可能会发生这种情况。