TCP 段数据部分的最小大小

Question

我的问题有两个部分：

1. 我知道以太网帧的“数据”部分可以是 46~1500 字节。考虑到 20 字节的 IP 标头 + 20 字节的 TCP 标头，TCP 段的最小“数据”大小应为(46-20-20) = 6 bytes. 考虑到 8 字节的 UDP 标头，UDP 段的最小“数据”大小应为(46-8-20) = 18 bytes. 那么，谁能解释一下为什么应用程序数据大小的下限会变成6字节或18字节这样的高值？不是一个小值，比如 1 个字节？我相信我错过了一些东西。

2. 我发现了一些解释^{[1] [2]}，即 IP 数据包的最小大小应为 64 字节。我认为上述链接中的解释是正确的。在这种情况下，为什么不是以太网帧的最小“数据”大小(64-20-20) = 24 bytes？

任何人都可以更清楚地解释这一点吗？

Answer 1

以太网的最小帧大小规定为 64 字节（也如您的参考资料中所述）。

DMAC + SMAC + EtherType + Payload + CRC  
 6   +  6   +     2     +    46   +  4  = 64

在第 4 层（TCP 或 UDP），“长度”覆盖第 4 层标头，并在 IP 标头中进行跟踪。
这意味着，对于 UDP 的最小预期是 8 个字节（对于它的标头）。并且，对于 TCP，它是 20 字节（最小 TCP 标头）。

你似乎缺少的部分现在开始。
虽然要求以太网数据长度至少为 46 个字节，但 IP 长度不必为46-20字节。它可以比这少得多。

所以，如果我们有一个没有数据的 8 字节 UDP 数据包，它的 IP 长度将是20+8但以太网有效负载长度仍然是46字节。18字节孔会发生什么？它被填充以在有线64字节上制作以太网帧（出于您已经知道的原因）。

[Eth: DMAC + SMAC + EtherType + [IP: Hdr + [UDP: Hdr + 0data ]] + PAD + CRC ]

底线：application data size根据此64字节以太网要求，您所指的没有最低期望。在PAD将弥补任何差异。