このシナリオで問題（おそらくパケット損失）を引き起こす原因
私はネットワーク関連の問題を診断しようとしています-答えを提案する前にこれらの点を理解してください（より多くの情報が必要な場合はお詫びします、私は人々が尋ねるものを追加します）。
- サーバー間でパケット損失が発生しているように見えるサーバーのみのネットワーク（5つのアプリサーバー、4つのデータベースサーバー、他のいくつかのサーバー）があります
- 私はこれがワイヤーシェアで起こっているのを見ることができます-たくさんのTCP再送信、TCP_Out-of-Order、TCP DupACK、そして私はいくつかのTCP_ZeroWindowパケットもあると思います。
- IPプロトコルに多くの不良チェックサムがあるようです
- このパケット損失によって引き起こされる余分な再試行のために、ネットワークアダプタは非常に一定で高い（90-100％）負荷を持っていると思います
- このネットワーク上の外部リクエストが（アプリサーバーに対して）増加すると、ネットワークパフォーマンスが低下します
- アプリサーバーは、外部リクエストで使用されると独自のトラフィックを生成します
- 外部要求はコアルーターを介して送信され、ネットワークは独自のセグメント上にあります
- この高負荷は1〜2日後に「魔法のように」消えました。負荷が低下したときにアダプタでのみ監視しているので、wiresharkでパケット損失が表示されますが、量は少なくなります。
- 侵害されたサーバーを指すものはありません。
- 残念ながら、どのハードウェアにも物理的にアクセスできません
- 現在のサービスを中断することはできません
上記のことを考えると、パケット損失の原因を特定するための最良の方法は何ですか（マネージドスイッチであることが期待されます）。
問題の原因の経験的証拠を提供できるソフトウェアはありますか？
前もって感謝します
私の経験では、WiresharkはハードウェアTCPオフロードを使用しているインターフェイスで信頼できない結果を返す可能性があります。重複したパケットは、その症状の1つです。
とは言うものの、スパン/ミラーポートを使用してキャプチャを取得している場合、ワイヤ上の重複したackは重大な問題です。
重複したACK、順不同、および再送信は、TCPスタックが正しく動作していないことを示すシグナルです。エラーをスローしやすいネットワークノードを関連付けると、さらに必要なホストを特定するのに役立ちます。調査中。特定のノードでのスパン/ミラーポートキャプチャとwiresharkセッション間のネットワークキャプチャの違いは、発生している可能性のある問題を明らかにするのに役立ちます。問題が発生した場合は、ネットワークドライバの更新を調査してください。ある種の問題（Broadcomはこれについて悲しいことに悪名高い）。次に、NICのファームウェアを更新することも役立ちます。
そこにあるすべてが正常に見える場合は、処理するトラフィックが単純に多すぎる場合にTCPが行う、通常の乱暴な動きが見られる可能性があります。
TCP Zero-Windowは、異常なTCP/IPスタックの兆候でもありますが、私の経験では、2つの異なるTCP/IPスタックがうまく機能していない場合に発生することがあります。これは、Windows2008やLinuxスペースの特定の古いTCP/IPスタックで発生する可能性があります。