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