パケット損失をどのように診断しますか？

これは非常に主観的であり、多くの変数に依存していることを理解していますが、特定のシステムでパケット損失を診断する必要がある場合、ほとんどの人がどのステップを踏むのか疑問に思っていますか？

私はネットワークエンジニアなので、これを自分の観点から説明します。

私にとって、パケット損失の診断は通常「うまく機能していない」ことから始まります。そこから、私は通常、通信の両端に近いキット（通常、オフィスのワークステーションとどこかにあるサーバー）を見つけ、可能な限りもう一方の端に近いping（理想的には「リモートエンドポイント」）を見つけます。ただし、pingを送信できないファイアウォールが存在する場合があるため、ルーターのLANインターフェイスに対応する必要があります）、損失を確認できるかどうかを確認します。

損失が見られる場合は、通常、「帯域幅不足」または「問題のあるリンク」がその中間にあるため、ネットワークを介してルートを見つけて、途中から開始します。

損失が表示されない場合、次の2つのステップは「pingをさらに送信する」または「より大きいpingを送信する」傾向があります。問題が何であるかがソートで示されない場合は、エンドポイント間のパス全体でQoSポリシーとインターフェース統計の調査を開始します。

それが何も見つからない場合、それはあなたの仮定に疑問を投げかける時です、あなたは実際にパケット損失に苦しんでいますか？それを見つける唯一の確実な方法は、ホストでWireShark（または同等のもの）を使用するか、ネットワークタップ経由でスニファーマシンを接続する（おそらくWireSharkなどを使用する）ことで、両端で同時にキャプチャを実行することです。次に、2つのパケットキャプチャを比較する楽しみがあります...

場合によっては、「パケット損失」と見なされるのはサーバー側の何かが著しく遅いことです（たとえば、データベースを「同じLAN上」から「20ミリ秒先」に移動し、非常に多くのクエリを使用するなど）フロントエンドとデータベースの間を行き来します）。

Linuxシステムの観点から、まずネットワークインターフェイスでのパケット損失を探しますethtool -S ethX。

ほとんどの場合、でリングバッファを増やすとethtool -G ethX rx VALUEこれが解決します。

システムにirqbalanceサービスがないために割り込みのバランスが取れていない場合があるため、chkconfig（EL）またはupdate-rc（Debuntu）を調べて、このサービスが実行されているかどうかを確認します。/proc/interruptsすべてのIRQチャネルにサービスを提供するコア0のみを表示するため、割り込みのバランスが取れていないかどうかを確認できます。

これに失敗するとnet.core.netdev_max_backlog、システムが数ギガビット以上のトラフィックを通過させている場合、増加させる必要があるかもしれませんnet.core.netdev_budget。

それがうまくいかない場合は、を使用して割り込み合体値を調整できますethtool -C。

ネットワークインターフェイスにパケットドロップがない場合netstat -sは、ソケットバッファにドロップがあるかどうかを調べて、「pruned from receive queue」や「dropped from out-of-order queue」などの統計情報で報告されます。

適切なプロトコルのデフォルトおよび最大ソケットバッファを増やすことができます（例：net.ipv4.tcp_rmemTCP用）。

アプリケーションが独自のソケットバッファサイズを設定する場合、アプリケーションの構成を変更する必要があります。アプリケーションのソケットバッファサイズがハードコーディングされている場合は、アプリケーションベンダーに苦情を申し立てます。

個人的には、NICへのプロトコルオフロード（チェックサム、セグメンテーションオフロード、大量受信オフロード）が嫌いです。を使用してこれらの設定をethtool -Kいじってみると、一見の価値があります。

modinfo <drivername>一部の機能を変更する必要がある場合があるため、NIC（）のモジュールオプションを確認してください。私が遭遇した1つの例を挙げると、1つの大きなTCPストリームを処理するシステムでIntelのFlow Directorを使用すると、おそらくそのストリームの効率が損なわれるため、FDirをオフにします。

それを超えて、この特定のシステムを特定のワークロードに合わせて手動で調整することになりますが、これはあなたの質問の範囲を超えていると思います。

まず、wireshark（Windows）およびtcpdump（Linux端末）などのパケットキャプチャツールを使用します。

また、ファイアウォール構成（ホストファイアウォールとネットワークファイアウォール）も確認します。

隔離してから排除します。

問題のあるパスの最小サブセットを見つけます。これを行うには、さまざまな組み合わせをテストするか、ユーザーレポートを抽出します。赤道の時間を考慮することを忘れないでください。特定のネットワークへのすべてのトラフィックでのパケット損失だけの場合もあれば、ワイヤレスクライアントのみが問題になっている場合もあります。さまざまなトラフィックタイプを考慮してください（pingのレート制限）。最も信頼性が高く、簡単に再現できる方法を見つけてください。

次に、潜在的な原因を排除します。リンク上のトラフィックを（一時的に）減らし、スペクトルから干渉源を取り除き、特定のクライアントを切断します。最終的には、問題の原因を見つけることができます。

パケットダンプを確認したり、推測したりすることでショートカットを作成できる場合があります（常にbittorrentです）。また、教授のserverfaultがすばらしいことを伝えてください。

大きなpingを送信しない限り、pingでパケット損失が表示されない場合があります。ネットワークでパケット損失がありましたが、pingパケットサイズを増やすまで見えませんでした。

Windowsの場合：

ping -n 30 -l <largevalue> <target>

以下のためにlargevalue私は40960（40Kパケット）を使用しました

targetの最初のいくつかのIPアドレスを使用したためtracert google.com

（これは私のルーターとケーブルモデムでした）。チェーンのさらに下のデバイスの1つは、大きなパケットではひどいパケット損失（> 60％）でしたが、小さなパケットでは0％でした。再起動して修正しましたが、ケーブルまたは交換が必要な内部的なものである可能性もあります。