なぜパケットロスが発生すると、速いホームサーバーの接続速度が遅くなるのですか？

パケット損失は、リンク速度がインターフェースがビットを送信できる速さを測るのに対し、有用スループットは正しく届くアプリケーションデータの量とパケット消失時のトランスポートプロトコルの反応に依存するため、通常は高速なホームサーバーのリンクを遅くします。

信頼性のあるトランスポートは欠落データを繰り返し送信し、損失が輻輳の兆候である可能性があるため通常送信速度を落とします。したがって、1GbEや10GbEのインターフェースは完全にネゴシエートされたままであっても、ファイルコピー、リモートバックアップ、ウェブセッション、メディアストリームは期待される有用性能の一部しか提供しないことがあります。

なぜリンク速度は高いままで有用スループットが低下するのか？

帯域幅は経路の名目上の伝送容量ですが、グッドプットは成功裏に届けられた有用なアプリケーションペイロードのみをカウントします。ある制御された経路品質実験では、わずかな損失率でもトランスポートフローが繰り返し中断されるため有用スループットがリンク速度の変化前に崩壊することが示されました。

再送されたバイト、重複データ、ヘッダー、および回復ギャップは、完了したファイルやアプリケーションの応答を進めることなく時間を消費します。インターフェースカウンターは、受信者が有用なデータをゆっくりと受け取っている場合でもかなりのトラフィックを示すことがあります。

スピードテストは複数の並列フロー、近隣のサーバー、または短いテスト間隔を使用することで問題を隠すこともあります。遠隔のエンドポイントへの単一の長時間転送は、繰り返される損失と往復回復によりより影響を受けやすいです。

損失後に信頼性のあるトランスポートが繰り返す作業とは？

TCPおよび信頼性のあるQUICストリームは、どのデータが受信者に届いたかを追跡します。ギャップが検出されると、失われたデータは再送されなければならず、追加の帯域幅を消費し完了を遅らせます。

送信者は重複確認応答、選択的確認応答、QUICの損失タイマー、または再送タイムアウトを通じて損失を検出することがあります。迅速な検出は停止時間を制限しますが、タイムアウトは送信者が再試行するまでにより大きな遅延をもたらすことがあります。

再送は単に欠落したパケットを置き換えるだけではありません。元のパケットはすでにリンク容量を使用しており、再送パケットも再びそれを使用します。さらに、送信者が損失を正確に特定できない場合、近接するパケットも再送されることがあります。

なぜTCPはパケット損失後に送信速度を落とすのか？

従来のTCPは損失を経路に過剰なデータが入っている証拠とみなします。損失ベースの輻輳制御は送信率を減らすため、送信者は以前の速度でのボトルネックへの供給を停止します。

輻輳ウィンドウは未確認データがどれだけ飛行中に残るかを制御します。そのウィンドウを切り詰めると、実際に失われたパケットの割合よりもはるかにスループットが低下します。なぜなら送信者は後の確認ラウンドで再びウィンドウを成長させなければならないからです。

異なるアルゴリズムは異なる反応を示します：Reno、CUBIC、BBRのバリアント、QUICの実装は同一の信号や削減を使用しません。一般的な境界は、高速物理リンクが輸送が意図的に飛行中データを制限すると、その容量を提供できないことです。

ラウンドトリップ時間はどのように損失回復を拡大するのか？

送信者は受信者に届き戻ってくるフィードバックを通じて配信を学習します。RTTが高いほど回復サイクルが長くなるのは、各ウィンドウ調整と再送確認がRTTの一部を消費するためです。

短いローカルイーサネット経路では、高速再送がほとんど目に見えないほど迅速に完了することがあります。同じ損失がVPN、リモートバックアップ、クラウドマウント、または国内横断接続で発生すると、進行が数十ミリ秒から数百ミリ秒遅れることがあります。

高帯域幅では、各ラウンドトリップ中により多くのデータが送信されている可能性があるため、そのペナルティはより驚くべきものになります。損失はそのパイプラインを空にするか縮小し、より長い経路はそれを再充填するのにより多くの時間を必要とします。

なぜ1つの欠落パケットがすでに到着したデータを遅延させるのか？

TCPはアプリケーションに順序付けられたバイトストリームを提示します。1つの欠落したセグメントが後のデータをブロックすることがあります、たとえ後のパケットがすでに受信者に届いていてもです。

後のバイトはギャップが修復されるまで受信バッファで待つことがあります。HTTP/2では複数の論理リクエストが1つのTCP接続を共有しているため、1つの輸送レベルの損失が、欠落したバイトの後ろにある独立した応答ストリームを遅延させることがあります。

QUICはストリームが独立して回復できるため、クロスストリームの輸送ヘッドオブラインブロッキングを回避しますが、損失は依然として再送能力と輻輳制御の予算を消費します。1つの停止メカニズムを取り除いても、失われたパケットが無料になるわけではありません。

なぜファイル転送、ストリーム、UDPアプリは異なる失敗をするのか？

TCPとUDPはロスを異なる方法で露呈します。ファイル転送は正確なバイトを待ちますが、ライブ通話は再生に遅すぎるデータを待つよりも、損傷またはスキップされたフレームを好むことがあります。

TCPのロスは低スループット、バッファリング、ページやファイルの完了遅延として現れます。UDPのロスは、前方誤り訂正や回復設計によって、音声の途切れ、ブロックアーティファクト、制御ジッター、テレメトリのドロップ、アプリケーションレベルの再試行として現れることがあります。

ローカルとインターネットのトラフィックは1つのボトルネックを共有することがあります。これが、パケットロスを経路とワークロードで解釈しなければならない理由です。クリーンなLANのコピーはリモート経路がクリーンであることを証明せず、高速インターフェースは信頼できるアプリケーション配信を保証しません。

よくある質問

1%のパケットロスが本当に大幅なスループット低下を引き起こすことがありますか？

はい、特に意味のあるRTTを持つ1つのTCPフローの場合にそうです。正確な影響は輻輳制御アルゴリズム、ロスパターン、RTT、ウィンドウサイズ、並列フロー、回復機能によって異なります。

パケットロスは常にネットワークの輻輳を意味しますか？

いいえ。輻輳は一般的ですが、ロスはWi-Fi干渉、損傷したケーブル、不良な光学機器、過負荷のホスト、故障したNIC、MTU問題、ソフトウェアやドライバーの制限からも発生します。

なぜ並列の速度テストは正常に見えることがあるのですか？

複数のフローは独立して回復し、それぞれのフローの性能が悪くてもリンクを満たすことがあります。単一のアプリケーション接続は同じ恩恵を受けられないかもしれません。

UDPはパケットロスのパフォーマンスコストを回避できますか？

UDPは組み込みの再送や順序通りの配信を回避しますが、アプリケーションはデータを失うか、自身で回復、隠蔽、冗長性、再試行の仕組みを追加しなければなりません。

最終的な結論

パケットロスは、伝送容量を無駄にし、信頼性のある回復を強制し、輻輳ウィンドウを縮小し、順序通りの配信を遅延させることで、高速リンクを遅いアプリケーション経路に変えてしまいます。物理インターフェースはフルスピードのままであっても、有用なデータは遅れて到着します。RTT、トランスポートプロトコル、ロスパターン、ワークロードによって、結果が低スループット、バッファリング、長いテールレイテンシ、またはリアルタイムメディアの欠落のように見えるかが決まります。