Windows でのパケット損失のテスト
パケットロスは、ネットワーク上やインターネット上の伝送でも発生する可能性があります。接続でセッション制御が使用されているかどうかに応じて、パケット損失が発生します。 再送信 これにより、送信完了時間が長くなるか、 データが欠落している 。失われたパケットを再送信すると、余分なネットワーク トラフィックが発生します。それは非効率的で、コストがかかり、時間のロスになります。
標準的なアプリケーションでは、応答時間が遅いと煩わしい場合があり、時折パケットが失われるとトラフィック量がわずかに増加します。ただし、次のような対話型アプリケーションの場合は、 VoIP 、 ビデオストリーミング 、 そして ビデオ会議 、パケットロスは破滅的なものになる可能性があります。これらのアプリケーションは、パケットが正常に配信された場合でも、大量のトラフィックを生成します。再送信すると事態はさらに悪化します。
の場合 VoIP そして ビデオ会議 、欠落部分を待ってユーザー インターフェイスへのデータの配信を延期する時間がないため、パケット損失は再送信をトリガーしません。幸いなことに、各パケットは音声またはビデオ ストリームの非常に小さなスライスを表しているため、配信されたプレゼンテーションを見逃しても 1 つのパケットのペイロードは目立たなくなります。ただし、一連のパケット損失、または頻繁な断続的なパケット損失が発生すると、 品質を損なう 音や映像のこと。音声や映像に乱れが生じたり、ハングしたり飛びついたりすることがあります。
ビデオ ストリーミング サービスでは、パケット損失への対処方法が異なります。彼らにはそのようなプレッシャーはありません リアルタイム 2 人以上の人の間でライブ通信を行う対話型アプリケーションとして。ビデオストリーミングが依存しているのは、 バッファリング 。
ビデオ再生アプリケーションは、ビデオの再生を開始する前に数分間の映像を保存します。バッファに保存されるビデオ時間の量は、接続の検出されたビット レートに基づいて計算され、予想されるパケット損失のパーセンテージが加算されます。場合によっては、ビデオ アプリケーションがネゴシエートできる場合があります。 ビデオの品質が低い 遅い接続を補うため。ただし、接続上のパケット損失率が 予想より高い 、バッファリングされたビデオが不足します。バッファにビデオが残っていない場合、ビデオ プレーヤーは十分なビデオ時間が受信されるまで一時停止する必要があります。
したがって、パケット損失により、対話型アプリケーションでは次のような問題が発生します。 質の悪い ビデオストリーミングが発生します バッファリングと一時停止 。
関連記事: 8 つのステップでパケット損失を修正する
セッション制御
ネットワーク上のデータ送信を管理するには 2 つの戦略があり、どちらも トランスポート層 プロトコル。その最初のものは、 伝送制御プロトコル (TCP) 、 これは ' 接続指向 ' システム。 TCP には、パケットが到着したことを確認し、失われたパケットの置換を要求する手順が含まれています。もう一つのシステムは、 ユーザー データグラム プロトコル (UDP) 。これではセッションが確立されないため、「」と呼ばれます。 コネクションレス型 」 UDP には、受信者が再送信を要求できるようにする方法がありません。
TCP は優れていますが、多くのオーバーヘッドが発生します。インタラクティブなアプリケーションではセッションの追加に時間を費やす余裕がないため、これらのシステムは UDP に基づく傾向があります。彼らはアプリケーションに送信制御を実装するか、単にそれを気にしないかのどちらかです。
送信に対するこれら 2 つのアプローチと、どちらを使用するかについてのアプリケーション開発者の選択 TCPまたはUDP パケット損失によって余分なトラフィックが発生する場合と発生しない場合がある理由を説明します。そのため、場合によってはサービスの品質が低下することもあれば、サービスの速度が低下することもあります。すべての場合において、 パケットロスは悪いことだ 。
パケットロスの検出
大量のデータを伝送することが予想されるビジネス ネットワークを実行している場合 音声とビデオのトラフィック 、ケーブルとネットワークデバイスに十分な容量があることを確認する必要があります。 容量 ユーザーの要求によって生成されるすべてのトラフィックを伝送します。
パケットロスを完全になくすことはできないので、計算するのが通常です 追加容量 その発生を考慮するための要件。 VoIP およびビデオ会議トラフィックの再送信は発生しませんが、パケット損失によりビデオ ストリーミング アプリケーションのトラフィック量が増加することに注意してください。
ユーザーがアクセスできるように新しいマルチメディア アプリケーションを公開する前に、ネットワーク上および特定のソースからの送信におけるパケット損失率を検出することをお勧めします。したがって、 アプリケーションを試用する それをリリースする前に。
パケットロスを確認することもできます。 オペレーティング·システム 、新しいアプリケーションを関与させずに。これは、見かけ上のパケット損失がネットワーク上で実際に発生しているかどうかを確認するのに役立つため、価値のある演習です。また、ネットワーク上に実際の問題がないにもかかわらず、新しいアプリケーションにパケット損失が発生しているように見える設定がいくつかあることを意味する場合もあります。
パケットロス検出ユーティリティ
いくつかあります ネットワーク管理システム これには、パケット損失を特定するユーティリティが含まれています。これらのシステム モニターの中には、 警告 予想よりも大きなパケット損失率を検出したとき。このような場合、ツールをそのままにしてネットワーク パフォーマンスの継続的な監視を続けることができ、他のタスクに時間を割くことができます。
これらの監視システムはすべて、次のような方法に基づいてパケット損失を検出します。 オペレーティングシステムに組み込まれている 彼らはその上を走ります。これらの検出システムには、ユーザーが直接アクセスできます。したがって、ネットワーク監視ツールを持っているかどうかに関係なく、監視者がシステム調査に使用するパケット損失データを確認できます。
システム監視ユーティリティへのアクセス
パケット損失を調査するために必要なユーティリティはすべて、その下にあるオペレーティング システムの一部です。 ウィンドウズ インターフェース。開く必要があります コマンド・プロンプト ウィンドウをクリックしてアクセスします。
をクリックしてください スタートメニューの検索バー そして入力してください cmd 。クリック コマンド・プロンプト 結果リストに表示されます。
これにより、コマンド プロンプト ウィンドウが開き、オペレーティング システムに直接アクセスできるようになります。
ネットワーク上のパケット損失の特定
の住所を知る必要があります。 デフォルトゲートウェイ ネットワーク上で。これは、有線ネットワークと無線ネットワークの両方に当てはまります。
ワイヤレス ネットワークでは、デフォルト ゲートウェイはワイヤレス アクセス ポイント (AP) です。 LAN では、デフォルト ゲートウェイはルーターです。どちらの場合も、このゲートウェイはネットワークの境界上にあります。これは、すべての接続が通過するために到達する必要があるポイントです。 インターネット 。したがって、私たちはプライベート ネットワーク上の通信範囲を調べているだけです。
私たちが使用するテストでは、コンピュータからゲートウェイへ、そしてその逆の両方向のトラフィックをチェックアウトします。往路と復路の両方をカバーしているため、送信パケットと受信パケットが経験する条件を確実にテストできます。
入力 ipconfig コマンド プロンプト ウィンドウでローカル ネットワーク上の情報を取得します。
の値を探す必要があります デフォルトゲートウェイ 。上に示した例では、そのアドレスは 192.168.0.1 です。これは、プライベート ネットワーク上のデフォルト ゲートウェイの一般的な IP アドレスです。
これで、デフォルト ネットワークとの間の接続テストを開始できるようになりました。タイプ ピン
Ping はいくつかのテストを実行し、結果を要約します。上の例では、パケット損失がなかったことがわかります。 Windows では、Ping は 4 つのテスト実行を実行します。通常、パケット損失は 25% よりはるかに小さいため、問題を特定する機会はあまりありません。コマンドの最後に -n 100 を追加して、Ping で 100 個のテストを実行します。たとえば、 Ping 192.168.0.1 -n 100 。
上記の 100 回のテストの実行例では、ネットワーク上でまだパケット損失が発生していないことが示されています。これは、ネットワークが現在のスループット需要に対応できることを示しているため、良いことです。しかし、 この状況は変わるかもしれない 新しいアプリケーションが稼働し、多くのユーザーがネットワークの容量にさらに大きな圧力をかけるようになります。
ネットワークにおけるパケット損失の主な原因の 1 つは次のとおりです。 スイッチとルーターの過負荷 。デバイスが処理できる速度よりも速い速度でパケットがスイッチに到着した場合、スイッチは最初に受信パケットをバッファリングします。そのキューがいっぱいになると、到着した新しいパケットは他の場所に行くことができないため、スイッチがバッファ内のスペースを空にするまでパケットは失われます。
インターネット上のパケットロスを特定する
ネットワークが正常に動作している場合でも、ユーザーは対話型アプリケーションやビデオ ストリーミング サービスで問題に遭遇する可能性があります。インターネット接続に問題があることが原因である可能性があります。
接続パケット損失率を確認するコマンドはまったく同じ、Ping です。ただし、今回は、予想されるデータ ソースのアドレスを入力する必要があります。 URL が指定されている場合、Ping は DNS 解決を実装するため、IP アドレスを知る必要はありません。ここでは、Google のサーバーに送信され、次のコマンドで起動された 100 個のテストの例を示します。 google.com に ping -n 100 。
この場合、パケット損失はありませんでした。
パケットロスへの対処
ネットワーク上でパケット損失が発生した場合、最も可能性の高い原因は、スイッチまたはルーターの過負荷です。さまざまなネットワーク デバイスを通過する、ネットワーク上のさまざまなエンドポイントへの ping を試行します。 どのデバイスに問題があるかを正確に確認する 。
過負荷になっているデバイスを特定したら、デバイスやそれに接続されているケーブルを交換することなく、状況を解決できます。と呼ばれる方法によるものです トラフィックシェーピング 。
トラフィック シェーピング アルゴリズムには、さまざまなアプリケーションに関連するパケットを識別し、各スイッチで一部のアプリケーション トラフィックを遅くして他のトラフィックを優先することが含まれます。これは 待ち行列戦略 これにより、一部のアプリケーションのトラフィックが常に保留され、キューに入れられ、優先トラフィックがスイッチに直接アクセスできるようになります。
何もできることがないと思われるかもしれませんが、 インターネット上のパケットロス なぜなら、そのドメインを制御できないからです。ただし、トラフィックが 絞り込まれた インターネット サービス プロバイダー (ISP) による。このシナリオでは、ISP が特定のアプリケーションのパケットを遅くしたりドロップしたりするため、一部の ISP にとってビデオ ストリーミングが特に大きなターゲットとなります。
スロットルは検出または証明することが非常に困難です。そのまま 動画トラフィックをターゲットにする 、Ping で実行するテストでは、ビデオ トラフィックが受ける処理の種類は表示されません。
もう 1 つの理由として、ネットワーク ゲートウェイ ルーターに、処理が期待されるすべてのトラフィックを処理する能力がないことが考えられます。この場合、ルーターにキューイングを実装するか、次の機能を備えたデバイスにアップグレードすることができます。 より大きな容量 。
ジッター
Ping で表示されるのはパケット損失データだけではありません。上記の例では、Ping の概要に次のことが示されていることがわかります。 最小 、 最大 、 そして 平均往復時間 テスト実行バッチ内のすべてのパケットに対して。
パケット配信時間の変動は次のように呼ばれます。 ジッター これは対話型アプリケーションにとっては悪い状態です。 VoIP とビデオ会議ではセッション制御やバッファリングが使用されないため、パケットが順序どおりに通常の速度で到着する必要があります。到着したパケットの順序を並べ替える時間がないため、後続のパケットの移動速度が速く、その前に送信されたパケットよりも前に到着した場合、VoIP アプリケーションはチェックを行わず、それらのデータ セグメントを順番に再生します。到着しました – その結果、奇妙なサウンドが発生しました。
パケット損失と同様、ストリームの各小さなスライスはほとんど目立ちにくいため、少量のジッターがサウンドやビデオの品質に検出可能な問題を引き起こすことはありません。短期間のジッターや送信時間の範囲が狭い場合は、サービス品質に大きな影響を与えません。
