sockets - SO_REUSEADDR 选项影响碎片？

Question

我遇到过设置了 SO_REUSEADDR 选项的 UDP 套接字的有趣行为...

如果我通过 IP/UDP 发送 1472 字节，我会在一帧中得到所有数据——这是预期的......

但是 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)

Answer 1

答案是NO - SO_REUSEADDR 不影响碎片...


线索是 IP header 中的 MTU Discovery 和 Don't Fragment Flag。
如果在 MTU Discovery = ON 的情况下发送 1472 字节:
发送了 1500 个字节，同时 Don't Frag Flag ON => 我收到 ICMP:

互联网控制消息协议(protocol)
类型:3(目标无法到达)
代码:4(需要分片)
校验和:0x90db [正确]
下一跳MTU:1480

之后，发送方对所有数据包进行分段以适应 1480 MTU，同时为该接收方保留路由\arp 缓存信息(路由 5 分钟，arp 30 秒 - 我的系统上配置的默认值)。

这就是为什么我意外地看到了 1473 字节的碎片(两帧中有 1456 + 25 字节)(SO_REUSEADDR 在该实验中处于打开状态)...

下次我尝试发送相同的 1473 字节(SO_REUSEADDR 已关闭)时，route\arp 缓存释放了有关接收器的信息，我看到了不同的令人困惑的碎片(两个帧中的 1480 + 1 字节)。

对大家造成的困惑深表歉意...
然而，对我来说，深入研究这种行为并澄清我观察到的事情是非常有认知的。这里没有奇迹。