IP フラグの「Don't Fragment」[DF] ビットがどこで使用されているか知りたいです。フラグメンテーションは上位層には見えず、それらも気にしません。
私も例を探しています。
よろしくお願いします。
IP フラグの「Don't Fragment」[DF] ビットがどこで使用されているか知りたいです。フラグメンテーションは上位層には見えず、それらも気にしません。
私も例を探しています。
よろしくお願いします。
断片化は、常にすべての上位層から見えないわけではありません。一部の初期の (そしておそらく現在の) マイクロコントローラー TCP/IP スタックは、フラグメンテーション処理などの完全な機能を実装していませんでした。そのような状況でフラグを使用すると、パケットが、相手側が処理できなかった多くのフラグメントではなく、元の形式で到着することが保証されます。
さらに、UDP を使用する場合、すべてのフラグメントが宛先に到着する必要はないため、フラグメント化を防止するということは、メッセージが到着するか到着しないかのどちらかであり、UDP データグラムの一部だけが宛先に到達する可能性はありません。 . TCP/IP スタックが未組み立ての IP パケットを保持し、欠落したフラグメントを待っていた時間を思い出せませんが、DF フラグを使用することで、その間に不要なリソースが拘束されることはありませんでした。
最後に、ネットワーク インフラストラクチャの動作をテストするために使用できます。たとえば、最大転送単位よりも大きなパケットを取得したときに何が起こるかなどです (DF は、そのパケットが断片化されて穴を「圧迫」するのを防ぎます)。
@Pax の回答に加えて(またはおそらく彼が言及したテストの一部として)、DP フラグはpath MTU discoveryでも使用されます。これは、特定のリンクについて、フラグメント化せずに送信できる最大のパケットを把握しようとする場合です。
より高いレベルのプロトコルが理論的にはそのメカニズムから分離されていても、フラグメンテーションを回避することはしばしば役に立ちますが、それでも結果を「感じる」ことができます。ネットワークソケットへの単一のアプリケーションレベルwrite()
が大きすぎるためにフラグメント化され、フラグメントの 1 つがネットワークで失われると、IP パケット全体が失われます。もちろん、これはスループットに影響します。
このため、多くの場合、最大伝送単位、つまりフラグメント化せずに宛先に送信できる最大のパケットを知ることが望まれます。DF ビットを設定し、ネットワークが ( ICMPを介して) 障害を報告するまで、より大きなパケットを連続して送信するだけで、パス MTU ディスカバリーを使用してこのサイズを検出します。
CでDFを設定する標準的な方法がないことに注意してください。Linuxでは、このコードは機能します。
result = setsockopt(mysocket, IPPROTO_IP,
IP_MTU_DISCOVER, IP_PMTUDISC_DO, sizeof(int));
しかし、FreeBSD6では動作しません
また、Path MTUディスカバリーは、実際のインターネットでは非常に信頼性がありません。壊れたファイアウォールとミドルボックスが多すぎると、ICMPの「パケットが大きすぎます」というメッセージが除外されます(面接中にネットワーク管理者候補をテストする良い方法です。pingを停止するように依頼すると、ICMPが完全にブロックされる可能性があります)。 RFC 2923:「パスMTUディスカバリーに関するTCPの問題」
これが、IETFがパスMTUディスカバリーに依存せずに、MTUをテストする新しい方法を提案する理由です。RFC4821:「パケット化レイヤーパスMTUディスカバリー」