高トラブルシューティングTCP再送信レート
非常に高い割合のTCP再送信。36サンプル（32ビットWindows7で実行されているWireshark1.10.8で取得））の合計が少し多いネットワークの問題のトラブルシューティングを試みています。それぞれ2〜53分の範囲の7時間は、総入力帯域幅の43〜61パーセントを占める再送信を示しています。
私を混乱させているのは、私が知る限り、この種の問題の理由は2つしかないということです。パケットをドロップする不安定なリンクと輻輳です。私はこれらを除外したと思います。私たちの状況を説明させてください。問題を解決するために、私よりも知識のある人々から他の問い合わせの方向について聞いてみたいと思います。
問題のネットワークは海上の船に乗っています。衛星リンクを使用してインターネットと通信します。残念ながら、このタイプのリンクの帯域幅コストは莫大であるため、1Mbpsダウン/ 512kbpsアップ接続で立ち往生しています。衛星リンクであるため、ping時間は約650msです。現在、約300人が搭乗しており、全員がそのパイプを共有しています。
ネットワークは2つのVLANで構成されています（1つは船のコンピューター用、もう1つはゲスト用）。両方のVLANは、インターネットへのパイプを制御するSonicWall TZ 215（SonicOS Enhanced 5.8.1.2-6oを実行）にパイプされます。両方のVLANには、有線クライアントと無線クライアントがあります。有線ネットワークは、一連のCisco2900ギガビットスイッチによって実行されます。ワイヤレスネットワークは、多数のCisco APによって提供されます（海上での鉄鋼船での信号伝搬はひどいものです）。
混雑の問題だと最初に思ったので、これに対するさまざまな解決策を追求しました（ビデオチャットやストリーミングなどの高帯域幅サービスのブロック、本社に大きなパイプの代金を支払うようにバグを報告するなど）。悲しいことに、私たちはより大きなパイプを手に入れませんでした。他のことは少し役に立ちましたが、本当の違いを生むには十分ではありませんでした。
しかし、今週末、私は正方形に戻されました。船長は、訓練中にインターネットへのゲストアクセスを無効にするように私に頼んだ。その機会を利用して、ネットワークが混雑しているときにWiresharkでネットワークをキャプチャしましたそうではありませんでした。驚いたことに、その10分間のサンプルでは、TCP再送信率は他のすべてのキャプチャとほぼ同じでした-58％でした。このサンプルの期間中、平均帯域幅使用量は98kbpsであったため、間違いなくない混雑していた。
これは、考えられる原因としてパケット損失だけを残します。これをテストするために、12時間のpingを実行しました。最後に、プログラムは1％未満のパケット損失を報告しました。
どちらの葉...何？知りません。追加のアイデアがあれば幸いです。
ネットワークの前にすべてを確認してください。のように：衛星リンクは不安定です。その側の物理的なレベルの何かである可能性があります-悪いキャリブレーション、何でも。
シャーロックホームズアプローチによると、それが残っている唯一のものです。パケットは失われるため、失われます。
損失を検出する良い方法の1つは、パケットのUDPストリームを使用することです（主にQoSテストのためにこれを行うさまざまなツールがあります）。サイズ、頻度、遅延を変えることができます。実際に損失があるかどうかが表示されます。