2

IP メッセージを送信するときに、be とパケットの宛先の間のネットワーク パスの各ホップが、次のホップの MTU が送信したパケットのサイズよりも大きいかどうかを確認することを理解しています。その場合、パケットはフラグメント化され、2 つのパケットは別々にネクスト ホップに送信され、宛先で (場合によっては、最初に検出された NAT ルーターで) 再構成されます。私が理解している限り、これはかなり悪いことかもしれませんが、その理由はよくわかりません。

  • 接続が多くのパケットをドロップする傾向がある場合、単一のフラグメントを失うと、パケット全体を再送信する必要があることを理解しています (これは実際に私が自分で見つけた唯一のことです)
  • 私のパケットがフラグメント化される代わりにドロップされる可能性はありますか?
  • パケット フラグメントはどのように識別されますか? それらが正しく再組み立てされることを 100% 確信できますか? たとえば、同じ長さの 2 つの IP パケットをほぼ同時に同じ宛先に送信した場合、AAA、BBB が ABA、BAB に再構成されたように、2 つのフラグメントが交換される可能性はどれくらいありますか?

原則として、パケットがドロップされず、フラグメントが正しく再構成されている場合、実際にパケット フラグメント化を使用することは、ローカル帯域幅を節約し、1 つの大きなパケットだけではなく、ますます多くのヘッダーを送信する必要がないように思えます。

ありがとうございました

4

2 に答える 2

7

IP フラグメンテーションは、いくつかの問題を引き起こす可能性があります。

1) アプリケーション層の損失が増加する

前述のとおり、単一のフラグメントがドロップされると、レイヤー 4 パケット全体が失われます。したがって、ランダムなパケット損失率が小さいネットワークの場合、アプリケーション層の損失率は、各レイヤー 4 パケットのフラグメント数にほぼ等しい係数で増加します。

2) すべてのネットワークがフラグメント化されたパケットを処理するわけではありません

Google の Compute Engine などの一部のシステムは、断片化されたパケットを再構築しません。

3) 断片化は再注文を引き起こす可能性があります

ルーターがトラフィックを並列パスに分割する場合、同じフローからのパケットを 1 つのパスに保持しようとする場合があります。最初のフラグメントのみが UDP/TCP ポート番号などのレイヤ 4 情報を持っているため、後続のフラグメントは別のパスにルーティングされ、レイヤ 4 パケットの組み立てが遅れ、再順序付けが発生する可能性があります。

4) フラグメンテーションは、デバッグが困難な紛らわしい動作を引き起こす可能性があります

たとえば、2 つの UDP ストリーム A と B を 1 つの送信元から Linux を実行している宛先に送信すると、宛先はストリームの 1 つからのパケットを破棄する可能性があります。これは、同じソースから 64 を超える他のフラグメントを受信した場合、デフォルトで Linux がフラグメント キューを「タイムアウト」にするためです。ストリーム A のデータ レートがストリーム B よりもはるかに高い場合、ストリーム A からの 64 個のフラグメントがストリーム B からのフラグメントの間に到着し、B フラグメントがドロップされる可能性があります。

したがって、IP フラグメンテーションはユーザー ヘッダーを最小限に抑えることでオーバーヘッドを削減できますが、必要以上に多くの問題を引き起こす可能性があります。

于 2015-05-28T16:45:53.357 に答える
4

私の知る限り、パケットがフラグメント化されずにドロップされる唯一のケースは (とにかくドロップされる場合を除いて)、「フラグメント化しない」とマークされたパケットです。これらのパケットは、断片化されるのではなく破棄されます。

フラグメント化されたパケットには、ヘッダーに識別子、フラグメント オフセット、およびその他のフラグメント フィールドが含まれており、それらを組み合わせると、宛先ホストはすべてのフラグメントを受信したときに確実にパケットを再構成できます。最初のフラグメントのオフセットは 0 で、最後のフラグメントの more Fragments フラグは 0 に設定されています。2 つのパケットのヘッダーが変更されてフラグメント オフセットが交換された場合、正しくないパケットを再構成する可能性はありますが (ほとんどありませんが)、それらのチェックサムは引き続き有効です。これが起こる可能性は本質的にゼロです。IP は、データ ペイロードの完全性を保証するメカニズムを提供せず、ヘッダー内の制御情報の完全性のみを提供することに注意してください。

各フラグメントには元のデータグラムのヘッダーの [ほとんど] のコピーがあるため、パケットのフラグメント化は必然的に帯域幅を浪費します。パケットはフラグメントあたり 8 バイトまでしかフラグメント化できないため、60 + 65536 バイトの最大サイズのパケットを 60 * 8192 + 65536 バイトにフラグメント化することができ、最悪の場合、ペイロードが約 750% 増加します。私が思いつく唯一の例は、他のチャネルが空いていることを知った上で、ある種の周波数分割多重方式を使用してフラグメントを並列に送信するためにパケットをフラグメント化した場合です。その時点で、パケットを送信するだけでなく、その状況を検出してパケットを分割するために保存されるよりも多くの作業が必要になるようです。

IP でのパケット フラグメンテーションの仕組みに関する基本的な詳細はすべて、IETF RFC 791に記載されています。詳しい情報が必要な場合は、こちらを参照してください。

于 2015-02-12T19:00:32.680 に答える