IPレベルでフラグメンテーションが行われた理由がTCP/UDPではない理由を探しています。なぜTCPでフラグメント化が行われたのですかなぜTCP/UDPでないのですか
私のフレームが次のようになっているとします。| MAC | IP | TCP | Payload | FCS。 PathMTUはここで発生します。なぜ断片化が実装されているのですか？@ IPレベルは私の質問です。なぜ@ TCP/UDPレベル/コードが実装されていないのですか？
ありがとうございます。
これは、TCP/IPスタックとISO/OSIモデルの複数のレイヤが対象とするものです。 TCP/UDPはトランスポートプロトコルであり、断片化を気にする必要はありません。問題はありません。 IPレベルはネットワークを扱い、フラグメントのサイズはネットワークのプロパティに依存するため、フラグメント化を処理します。問題を解決するための最善の条件を持っているレイヤーは、それを解決します。
一部のTCP実装では、フラグメンテーションも回避するために、MTUとそのサイズを決定します。これにより、受信したTCPセグメントが確認応答され、再送信されないため、損失の多い状態での信頼性が向上します。失われたTCPセグメントだけが再送されます。対照的に、IPデータグラムフラグメントが失われた場合、有用な情報は受信されない。
UDPをフラグメント化するよりもTCPをフラグメント化する方が意味がありません。 TCPは信頼性の高いセグメンテーション/再アセンブリ/再送メカニズムを提供するので、より小さいTCPセグメントを送信し、断片化の必要性を完全に回避することができます（これはd3jonesの話です）。
しかし、UDPでは、フラグメンテーションがまだ理にかなっています。 MTUよりも長い単一のUDPセグメントを送信できます。 IP層は、それを正しく見えなく分断するでしょう。アプリケーション開発者は、アプリケーションレイヤプロトコルをコーディングするために、MTUまたはネットワークに関する何かを決定する必要はありません。
フラグメンテーションが上位層（TCP、UDPなど）で実行された場合、フラグメンテーション/リアセンブリが重複して実装されます（プロトコルごとに1回）。 （イーサネット、ATMなど）でフラグメンテーションが実行された場合、各ホップで断片化/再アセンブリを実行する必要があり（非常に高価になる可能性があります）、重複して実装されます。したがって、IP層は断片化のための最も効率的なものです。
レイヤ4（TCP/UDP）は、エンドポイント（送信側/受信側）でのみ表示されます。 レイヤ3（IP）はホップごとの画像になります。
今各ホップ間のリンクは、異なる帯域幅のものとすることができるMTUは、リンクのプロパティですが、このリンクプロパティ（MTU）に基づいて断片化が常にルータ（ホップ）
上のIP層で行わしたがって、各ホップでパケットを宛先に転送する方法を決定する必要があります。 MTUはリンクにプッシュできるデータの最大量であり、送信するパケットのサイズよりも小さい場合は、リンクに対応するためにそれを小さなチャンクに分割する必要があります。一つの断片が失われた場合の断片化と再アセンブリとして
は、送信者がパケット全体を送信するために起因するフラグメントヘッダ 3の添加 1.小さなCPUの増加とメモリオーバーヘッド 2パケットあたりのオーバーヘッドのような多くの欠点を有しています
上記の問題を解決するには、 1. Path MTU Discoveryを使用できます。 2.レイヤ4では、TCP MSSクランプを使用できます。
私のフレームが次のようになっているとします。| MAC | IP | TCP | Payload | FCS。PathMTUはここで発生します。なぜ断片化が実装されているのですか？@ IPレベルは私の質問です。なぜ@ TCP/UDPレベル/コードが実装されていないのですか？ – mahesh
@mahesh - この –
@Brian Agnewを反映させるために質問を編集したい場合は、私が編集したい方法で質問を編集することができます。 :)。前もって感謝します。 – mahesh