パケット損失は、コンピュータネットワークを介して送信されるデータパケットのうち、1つ以上が宛先に到達できない場合に発生します。パケット損失は、通常、無線ネットワークを介したデータ伝送のエラー[1][2]、またはネットワークの混雑[3]によって引き起こされます。パケット損失は、送信されたパケットに対する失われたパケットの割合として測定されます。
伝送制御プロトコル(TCP)はパケット損失を検出し、再送信を行うことで信頼性の高いメッセージングを保証します。TCP接続におけるパケット損失は、輻輳を回避するためにも利用され、結果として接続のスループットが意図的に低下します。
ストリーミングメディアやオンラインゲームなどのリアルタイムアプリケーションでは、パケット損失がユーザーの体験品質(QoE)に影響を与える可能性があります。
インターネットプロトコル(IP)は、エンドツーエンドの原則に基づき、ベストエフォート型の配信サービスとして設計されており、ルータが実装しなければならないロジックを可能な限りシンプルに保つことを目的としています。ネットワークが自力で信頼性の高い配信保証を行うと、ストアアンドフォワード型のインフラストラクチャが必要になります。これは、各ルータがパケットを次のノードが適切に受信したことを検証するまで、パケットにかなりのストレージ領域を割り当てるというものです。信頼性の高いネットワークは、ルータの障害が発生した場合、配信保証を維持できなくなります。また、すべてのアプリケーションで信頼性が必要なわけではありません。たとえば、ライブストリーミングメディアでは、古いパケットが最終的に配信されることを保証するよりも、最新のパケットを迅速に配信することの方が重要です。アプリケーションやユーザーは、処理に時間がかかっている操作を再試行することもあります。その場合、元のパケットセットの配信負荷に加えて、別のパケットセットが追加されます。このようなネットワークでは、輻輳管理のためのコマンドアンドコントロールプロトコルも必要になる可能性があり、さらに複雑になります。
これらの問題をすべて回避するために、インターネットプロトコルでは、ルータまたはネットワークセグメントがビジーでデータをタイムリーに配信できない場合、ルータがパケットを破棄することを許可しています。これは高速かつ効率的なデータ伝送には理想的ではなく、混雑していないネットワークでは発生しないと考えられます。[ 4 ]パケットの破棄は、ネットワークが混雑していることを示す暗黙のシグナルとして機能し、送信側が消費する帯域幅を削減したり、別の経路を探したりする可能性があります。たとえば、パケット損失をフィードバックとして利用して混雑を検出するために、伝送制御プロトコル(TCP)は、過剰なパケット損失が発生すると送信側がスロットリングを行い、ボトルネックポイントへのデータフラッディングを停止するように設計されています。[ 3 ] : 282–283
IPv4ヘッダーのチェックサムまたはイーサネットフレームのチェックシーケンスによってパケットが破損していることが示された場合、パケットが破棄される可能性があります。パケット損失は、パケットドロップ攻撃によっても発生する可能性があります。
無線ネットワークは、無線周波数干渉(RFI)[ 1 ] 、距離やマルチパスフェージングによる弱すぎる無線信号、ネットワークハードウェアの故障、ネットワークドライバの故障など、転送中にパケットを破損または失う可能性のある多くの要因の影響を受けやすい。
Wi-Fiは本質的に信頼性が低く、2つの同一のWi-Fi受信機を互いに近い場所に設置しても、予想されるようなパケット損失のパターンは現れません。 [ 1 ]
セルラーネットワークでは、「高いビット誤り率(BER)、不安定なチャネル特性、およびユーザーの移動性」によってパケット損失が発生する可能性があります。[ 5 ] TCPの意図的なスロットリング動作により、無線ネットワークは理論上の潜在的な転送速度に近いパフォーマンスを発揮できません。これは、変更されていないTCPが、ドロップされたすべてのパケットをネットワークの輻輳が原因であるとみなすため、実際に輻輳していない場合でも無線ネットワークをスロットリングする可能性があるためです。 [ 5 ]
ネットワークの輻輳は、あらゆる種類のネットワークに影響を与える可能性のあるパケット損失の原因です。コンテンツが特定のルータまたはネットワークセグメントに、送信可能な速度よりも速い速度で長時間到着すると、パケットを破棄する以外に選択肢はありません。[ 3 ] : 36単一のルータまたはリンクが、完全な伝送経路またはネットワーク伝送全般の容量を制限している場合、それはボトルネックとして知られています。場合によっては、ルーティングルーチンによってパケットが意図的に破棄されるか、[ 6 ]または運用管理目的でネットワーク抑制技術によってパケットが破棄されます。[ 7 ]
パケット損失は、送信されたデータの一部が受信されずスループットとしてカウントされないため、送信者側のスループットを直接的に低下させます。また、一部のトランスポート層プロトコルはパケット損失を輻輳の兆候と解釈し、輻輳崩壊を回避するために送信レートを調整するため、間接的にもスループットを低下させます。
信頼性の高い配信が必要な場合、パケット損失は再送信に必要な追加時間のため遅延を増加させます。 [ a ]再送信がないと仮定すると、最も遅延の大きいパケットは優先的に破棄される可能性があり(使用されるキューイング方式によります)、結果として全体的な遅延が低くなります。
パケット損失は、ネットワークによって転送されるべきであったにもかかわらず転送されなかったフレームの割合として定義されるフレーム損失率として測定される。 [ 8 ]: 4
パケット損失は、サービス品質の考慮事項と密接に関連しています。許容できるパケット損失の量は、送信されるデータの種類によって異なります。たとえば、VoIPトラフィックの場合、ある評論家は「時々1つか2つのパケットが失われても、会話の品質には影響しません。パケットストリーム全体の5%から10%の損失は、品質に大きく影響します。」と述べています。[ 9 ]また、別の評論家は、ストリーミングオーディオまたはビデオの場合、1%未満のパケット損失を「良好」、1~2.5%を「許容範囲」と表現しています。[ 10 ]
パケット損失は、TCPなどの信頼性の高いプロトコルによって検出されます。信頼性の高いプロトコルはパケット損失に自動的に反応するため、ネットワーク管理者などの担当者がパケット損失を検出および診断する必要がある場合は、通常、ネットワーク機器からのステータス情報や専用ツールを使用します。
インターネット制御メッセージプロトコルはエコー機能を提供しており、常に応答を生成する特別なパケットが送信されます。ping、traceroute、MTR、PathPingなどのツールは、このプロトコルを使用してパケットがたどる経路を視覚的に表示し、各ホップでのパケット損失を測定します。[ b ]
多くのルーターにはステータスページやログがあり、所有者はそこで特定の期間にドロップされたパケットの数や割合を確認できます。
エンドツーエンドの原則に基づき、インターネットプロトコルは、パケットの回復、すなわちドロップされたパケットの再送信を、データの送受信を行うエンドポイント(送受信コンピュータ)に委ねています。データを送信するアプリケーションは、メッセージ全体を再送信すべきか部分的に再送信すべきか、メッセージを送信する必要性がなくなったかどうか、そして輻輳を考慮して消費される帯域幅をどのように制御すべきかを知っているはずなので、エンドポイントは再送信が必要かどうかを判断するのに最適な立場にあります。
TCPなどのネットワーク転送プロトコルは、エンドポイントにパケットの確実な配信を保証する簡単な方法を提供するため、個々のアプリケーションは、このロジックを独自に実装する必要がありません。パケットが失われた場合、受信側は再送信を要求するか、送信側は確認応答されていないセグメントを自動的に再送信します。[ 3 ]: 242 TCPはパケット損失から回復できますが、失われたパケットを再送信すると、受信側が再送信を待機し、追加の帯域幅が消費されるため、接続のスループットが低下します。TCPの特定のバリアントでは、送信されたパケットが失われた場合、そのパケットは、その後に既に送信されたすべてのパケットとともに再送信されます。
ユーザーデータグラムプロトコル(UDP)などのプロトコルは、パケット損失に対する回復機能を提供しません。UDPを使用するアプリケーションは、必要に応じてパケット損失を処理するための独自のメカニズムを実装する必要があります。
どのパケットを破棄するかを決定するために使用されるキューイング方式は数多くあります。ほとんどの基本的なネットワーク機器は、ボトルネックを通過するのを待つパケットに対してFIFOキューイングを使用し、パケットを受信した時点でキューが満杯の場合はパケットを破棄します。このタイプのパケット破棄はテールドロップと呼ばれます。その他の満杯キューメカニズムには、ランダム早期検出と重み付きランダム早期検出があります。パケットの破棄は、パケットが失われるか再送信が必要になるため望ましくなく、リアルタイムのスループットに影響を与える可能性があります。ただし、バッファサイズを増やすとバッファブロートが発生し、輻輳時の遅延とジッタに独自の影響を及ぼします。
サービス品質が接続の速度制限要因となっている場合(例えば、リーキーバケットアルゴリズムを使用している場合)、優先度の高い他のサービスに十分な帯域幅を確保するために、特定のサービスの速度を意図的に低下させる目的でパケットが破棄されることがあります。そのため、パケット損失は必ずしも接続の信頼性の低さや帯域幅のボトルネックを示すものではありません。
そのため、ノードのパフォーマンスは、遅延だけでなくパケット損失の確率によっても測定されることがよくあります。すべてのデータが最終的に送信元から宛先に転送されるように、損失したパケットはエンドツーエンドで再送信される場合があります。