3

SO_REUSEADDRオプションが設定されたUDPソケットの興味深い動作に直面しました...

IP / UDPを介して1472バイトを送信すると、すべてが1つのフレームで取得されます。

しかし、1473の断片化は、そのオプションがある場合とない場合で異なります。なぜそれが起こるのか誰かが手がかりを持っていますか（私はDebian 2.6.32-5-amd64を使用しています）？

SO_REUSEADDR有効：

フレーム＃1

Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: **1476**
    Identification: 0x214d (8525)
    Flags: 0x01 (More Fragments)
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..1. .... = More fragments: Set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xd53f [correct]
        [Good: True]
        [Bad: False]
    Source: 173.59.3.22 (173.59.3.22)
    Destination: 173.70.1.5 (173.70.1.5)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol (**8** bytes)
    Source port: icl-twobase1 (25000)
    Destination port: 5000 (5000)
    Length: **1481**
    Checksum: 0x3cac [unchecked, not all data available]
        [Good Checksum: False]
        [Bad Checksum: False]
Data (**1448** bytes)

フレーム＃2

Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)br/>
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: **45**
    Identification: 0x214d (8525)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 1456
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xfa20 [correct]
        [Good: True]
        [Bad: False]
    Source: 173.59.3.22 (173.59.3.22)
    Destination: 173.70.1.5 (173.70.1.5)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
Data (**25** bytes)

SO_REUSEADDR無効：

フレーム＃1

Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: **1500**
    Identification: 0x214a (8522)
    Flags: 0x01 (More Fragments)
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..1. .... = More fragments: Set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xd52a [correct]
        [Good: True]
        [Bad: False]
    Source: 173.59.3.22 (173.59.3.22)
    Destination: 173.70.1.5 (173.70.1.5)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]

User Datagram Protocol (**8** bytes)
    Source port: icl-twobase1 (25000)
    Destination port: 5000 (5000)
    Length: **1481**
    Checksum: 0x3cac [unchecked, not all data available]
        [Good Checksum: False]
        [Bad Checksum: False]
Data (**1472** bytes)

フレーム＃2

Internet Protocol Version 4, Src: 173.59.3.22 (173.59.3.22), Dst: 173.70.1.5 (173.70.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: **21**
    Identification: 0x214a (8522)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 1480
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xfa38 [correct]
        [Good: True]
        [Bad: False]
    Source: 173.59.3.22 (173.59.3.22)
    Destination: 173.70.1.5 (173.70.1.5)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
Data (**1** byte)
4

1 に答える 1

1

答えはNOです-SO_REUSEADDRはフラグメンテーションに影響しません...


手がかりはMTUディスカバリーとIPヘッダーのフラグをフラグメント化しないことです。
MTU Discovery = ONで1472バイトを送信する場合：
Do n't Frag Flag ON =>で送信される1500バイトICMPを取得します：

インターネット制御メッセージプロトコル
タイプ：3（宛先に到達できません）
コード：4（フラグメンテーションが必要）
 チェックサム：0x90db [正しい]
ネクストホップのMTU：1480

その後、送信者は1480 MTUに合うようにすべてのパケットのフラグメンテーションを実行し、その受信者のroute \ arpキャッシュ情報は保持されます（ルートの場合は5分、arpの場合は30秒-デフォルトはシステムで構成されています）。

そのため、1473バイト（2フレームで1456 + 25バイト）の断片化が予期せず見られました（その実験ではSO_REUSEADDRがオンでした）...

次に同じ1473バイト（SO_REUSEADDRがオフ）を送信しようとしたときに、route \ arpキャッシュが受信者に関する情報を解放し、異なる紛らわしい断片化（2フレームで1480 + 1バイト）が見られました。

混乱してすみません...
しかし、それは私がそのような行動を掘り下げて、私が観察したことを明確にするために私にとってかなり認知的でした。ここには奇跡はありません。

于 2013-03-28T07:44:47.103 に答える