最近我一直在阅读有关巨型帧的文章，有些地方让我感到困惑。据我所知，“存储和转发”点（第 2 层桥接）之间的以太网帧大小存在下限，因为帧在到达目的地时仍需要传输以启用冲突检测。巨型帧设置不会影响此限制。
巨型帧将帧大小的上限从 1500B + 报头增加到更大的值（例如 4000B 或 9000B + 报头）。
较大的帧可以降低开销等，但单个数据包在传输过程中损坏的可能性更大，超出了纠错能力。如果数据包损坏，则需要重新传输（整个），这会增加延迟。此外，数据包的传输需要更多时间，因为（我认为）在传输到 CPU 或转发之前需要完全接收数据包。但是，延迟敏感的应用程序通常使用 UDP 和自定义数据包大小，因此它们不会使用巨型帧（只要它们不进行 MTU 发现），因此它们不会受到巨型帧的影响，因为帧会更短。
鉴于我读到巨型帧在可测量的程度上损害了延迟，我开始想知道是什么导致了这种影响？
答案1
以下是巨型帧可能影响延迟的一些方式。您已经知道其中一些：
9kB 巨型帧是最大标准以太网帧（1500 字节）的 6 倍。因此，在相同的误码率下，巨型帧出错的几率是标准以太网帧的 6 倍，并且当发生错误时，必须重新传输整个 6 倍大小的帧。
以太网帧校验序列 (FCS) 中为 CRC32 算法选择的多项式针对最大 1500 字节的帧大小进行了调整。对于较大的帧大小，它的效果较差，但巨型帧的开发人员并没有改变多项式。因此，巨型帧中的位错误更有可能在 MAC 层未被发现，而必须在稍后在更高层（在 UDP/IP 的情况下可能是应用层）检测到，这会导致在请求重传之前出现更大的延迟。
如果延迟敏感型数据包最终排队等待全尺寸帧以访问介质，并且全尺寸帧是 9kB 巨型帧而不是标准 1500 字节帧，则到达介质所需的时间是其 6 倍。
如果延迟敏感型协议使用巨型帧并试图填充它们以提高带宽效率，则在等待帧的最后字节构建之前，帧的第一个字节的传输将大大延迟，然后才能将帧发送到线路上。举一个最坏的例子，一些高效语音编解码器可以使用 2kbps 比特率，因此单个 9k 帧可能大约是 36 秒的语音。想象一下，由于这个原因，VoIP 通话中有 36 秒的延迟。当然，正如您所说，以这种方式设计延迟敏感型协议是非常愚蠢的，这似乎太明显了，不便提及。尽管如此，使用巨型帧仍然可能损害延迟。
还请注意，路径 MTU 发现是 IP 层的事情，因此它不是 TCP 特定的。因此基于 UDP 的协议可以从路径 MTU 发现中“受益”。还请注意，您不必执行 PMTUD 即可知道本地链路的 MTU，因此如果您的发送主机位于巨型帧以太网上，即使不执行 PMTUD，它的 MTU 也会设置为（最多）9000 字节。您编写问题的方式让我认为您可能没有意识到这一点。
PS 是的，帧需要完全接收后才能进行进一步处理，因为 FCS 位于末尾，并在整个帧中进行计算。此外，没有错误更正在以太网中，仅检测。
答案2
嗯，我认为，要使大型帧完整地从一端传输到另一端，路径上的每个组件都必须支持该帧大小 - 这意味着每个路由器和交换机都应该支持它，否则该帧将被丢弃。希望它能回答您的问题。