在这种情况下导致问题(可能是数据包丢失)的原因是什么

在这种情况下导致问题(可能是数据包丢失)的原因是什么

我正在尝试诊断与网络相关的问题 - 请在提出答案之前了解这些要点(如果需要更多信息,请原谅,我会添加人们询问的任何内容)。

  • 我们有一个仅服务器的网络(5 个应用服务器、4 个数据库服务器、几个其他服务器),该网络似乎存在服务器之间数据包丢失的情况
  • 我可以看到这种情况发生在 wireshare 上 - 有很多 TCP 重传、TCP_Out-of-Order、TCP DupACK 并且我认为还有一些 TCP_ZeroWindow 数据包。
  • IP 协议上似乎有很多错误校验和
  • 我认为由于数据包丢失导致的额外重试,网络适配器的负载非常稳定且很高(90-100%)
  • 随着该网络上的外部请求增加(到应用服务器),网络性能会下降
  • 应用服务器在外部请求使用时会产生自己的流量
  • 外部请求通过核心路由器发出,网络位于其自己的网段上
  • 这种高负载在 1-2 天后“神奇地”消失了,我说神奇是因为我们在负载下降时只监控适配器,wireshark 中仍然显示数据包丢失,尽管数量较少。
  • 没有任何迹象表明服务器已被入侵。
  • 不幸的是,我们无法物理访问任何硬件
  • 我们不能中断当前服务

鉴于上述情况,确定导致数据包丢失的原因的最佳方法是什么(我们预计它是一个托管交换机)。

是否有任何软件可以为我们提供导致问题的原因的经验证据?

提前致谢

答案1

根据我的经验,Wireshark 在使用硬件 TCP-Offload 的接口上可能会返回不可靠的结果。重复数据包就是这种情况的症状之一。

也就是说,如果您使用跨度/镜像端口来获取捕获,则线路上的重复确认将是一个严重的问题。

重复 ACK、无序和重传都表明某个节点上的 TCP 堆栈行为不正常。关联哪些网络节点容易抛出错误将有助于隔离哪些主机需要进一步调查。跨度/镜像端口捕获和该特定节点上的 wireshark 会话之间的网络捕获的任何差异都应有助于突出显示可能发生的问题。如果您发现这些问题,请调查更新网络驱动程序,因为这些通常是解决此类问题最简单的方法(Broadcom 在这方面臭名昭著)。其次,更新 NIC 的固件也可以有所帮助。

如果一切看起来都很正常,那么您可能只会看到 TCP 在处理过多流量时出现的正常剧烈波动。

TCP 零窗口也是 TCP/IP 堆栈不健康的标志,尽管根据我的经验,当两个不同的 TCP/IP 堆栈无法协同工作时,有时会发生这种情况。例如,Windows 2008 和 Linux 领域中某些较旧的 TCP/IP 堆栈可能会发生这种情况。

相关内容