为什么序言不被认为是以太网报头的一部分？

Question

1. 如果我在以太网帧中搜索数据的起始位置，我会得到一个共同的答案，即TCP报头( 20字节)+ IP报头( 20字节)+以太网报头( SA + DA + Type)，即14字节。因此，简单地说，这个问题的答案是52-54字节--数据开始于以太网帧，但我们不应该在其中增加8个字节的前导吗？
2. 此外，我还搜索了以太网帧大小为1514的以太网帧。为什么我们在这里忽略序言和儿童权利委员会？

Answer 1

补充jonathanjo的回答：

以太网在两层中都有组件1(因为它可以在不同的媒体上运行)和2层(因为在不同的媒体上帧是相同的)。

序言、SoF划界器和包间间隙实际上在第1层(唤醒接收器等)，而帧(包括报头、有效负载和FCS)位于第2层。

以太网帧中的数据是以太网帧的有效负载。您的问题1假设每一层-3协议都是IPv4，而每一层-4协议都是TCP，这是错误的假设。以太网不知道或不关心它所携带的第三层协议(IPv4、IPX、IPv6、AppleTalk等)，因此帧的数据就是有效负载。例如，IPv4数据包报头为20至60辛特，而IPv6数据包报头始终为40辛特。以太网不知道这一点，它只知道它有一个有效负载字段，而不是该字段中的内容。

以太网帧头通常是14位数，除非你有一个有标记的帧，那么它是18位数。MTU是最大有效载荷大小。以太网的最小帧大小也是64辛特，包括现场总线，因此有效负载可以从42 (带标签)或46 (无标签)八进制，到最大有效负载大小为1500兆字节。这意味着以太网帧(报头和有效负载)从60辛特到1514 (无标签)或1518 (带标签)八进制。

如果数据从何处开始，您指的是应用程序数据，这将真正取决于所有协议。UDP报头只有8个八进制，UDP有效负载可能是应用程序数据，也可能是应用程序层协议的数据报，其本身的报头可能不被算作应用程序数据。在您的TCP示例中，您可能正在运行web浏览器到web服务器。您认为HTTP (应用层协议)还是HTML作为数据(HTML是HTTP的数据)？当您引用数据时，它相对于您所引用的协议。

Answer 2

序言实际上是7个八进制，然后是一个框架八进制，即开始帧分隔符(SFD)。他们只是标记一个帧即将到来，并服务于同步目的，他们不是框架的一部分。就像帧间的间隙，不算框架的一部分。前导和SFD从不进入内存，因此没有任何内存偏移，其中包括8。

以太网帧有时被描述为1514 octets，因为硬件通常计算/检查FCS，而CPU从未看到它或将其放入内存中:只有src、dest、type、有效负载。但是，该框架被定义为包括FCS，明确地，根据标准。基本帧被定义为具有至少1500位字节的最大客户端数据字段长度，这加上14 +4 FCS = 1520。

PS。不要忘记可选的802.1q标记，这是另一个用于分组的4位字节，还有其他一些特殊类型。

编辑标准主要谈到框架，框架被定义为包括FCS (感谢Richard的评论)。它还提到了从前导开始到扩展位结束的数据包(为了确保良好的冲突检测，有时在FCS之后需要这些数据包)。这个包是硬件在有线上传输的所有比特。(“数据包”的这种用法可能令人困惑，正如我们通常所说的以太网帧内的IP数据包。)

这只是一个定义的问题，最后，我们可以找到它们，谢天谢地。如果你不知道，这个标准是免费的。它的核心是4000页长(!)，但是像定义这样的大多数东西都很容易读懂，而且绝对清楚。强烈建议至少查看第3.1.1节的数据包格式。http://www.ieee802.org/3/

Answer 3

除了已经存在的问题外，好的答案还包括：

前言是物理层的基本功能。请注意，当您将数据序列化到单个位或符号流时，您需要提供某种形式的同步--首先是位/符号，然后是单词。

前导线上产生的符号图案(实际上只有01010.与10BASE-x曼彻斯特代码)允许接收器调整其符号时钟，以准确的速度发射机。即使线路上没有变化，它也会知道它刚刚收到了多少符号。(所有物理层也为中间同步提供了手段，因此它是一个连续的过程。)

序言后面的SOF模式标志着第一个单词(或八进制/字节)的开始。接收机激活其缓冲器并将解码比特时钟到其中，反序列化来自解码器的比特并将其逐字发送到缓冲器。一次是一个字节还是一个32位的单词并不重要，但重要的是字节边界是正确的。

因此，前导和SOF必然是物理传输机制的一部分，因此属于物理层。从第二层的角度来看，帧不需要开始标记--它只是从第一个八进制开始。