Last Updated: 2023-09-20 10:16:17 Wednesday
-- TOC --
从共享Media（传输媒介）的LAN开始，不管传输技术和媒介如何变化，Ethernet一直保持着几乎相同的Frame结构，保持着简单，低价，可靠和对新技术的开放，这就是它巨大成功的原因。
Ethernet II Frame Structure (802.3 Frame). 与最早的Frame结构相比，就是增加了SFD（Start Frame Delimiter），复用了Length字段表示Type/Length。最小帧长为64 byte。
Preamble and Start Frame Delimiter Fields
The Preamble (7 bytes) and Start Frame Delimiter (SFD) (1 byte) fields are used for synchronization between the sending and receiving devices. These first eight bytes of the frame are used to get the attention of the receiving nodes. Essentially, the first few bytes tell the receivers to get ready to receive a new frame.
Destination MAC Address Field
Source MAC Address Field
Length/Type Field
The Length/Type field (2 bytes) defines the exact length of the frame's data field. This is used later as part of the FCS to ensure that the message was received properly. Either a length or a type may be entered here. However, only one or the other may be used in a given implementation. If the purpose of the field is to designate a type, the Type field describes which protocol is implemented. The field labelled Length/Type was only listed as Length in the early IEEE versions and only as Type in the DIX version. These two uses of the field were officially combined in a later IEEE version because both uses were common. The Ethernet II Type field is incorporated into the current 802.3 frame definition. Ethernet II is the Ethernet frame format that is used in TCP/IP networks. When a node receives a frame, it must examine the Length/Type field to determine which higher-layer protocol is present. If the two-octet value is equal to or greater than 0x0600 hexadecimal or 1536 decimal, then the contents of the Data Field are decoded according to the protocol indicated. (0x0800 is IPv4, 0x86dd is IPv6)
有可能出现payload小于46字节的情况，此时ethernet就要在payload内做padding，而length不能包括padding，否则就无法将content和padding区分开来。
Data and Pad Fields
The Data and Pad fields (46 - 1500 bytes) contains the encapsulated data from a higher layer, which is a generic Layer 3 PDU, or more commonly, an IPv4 packet. All frames must be at least 64 bytes long. If a small packet is encapsulated, the Pad is used to increase the size of the frame to this minimum size.
Frame Check Sequence Field
The Frame Check Sequence (FCS) field (4 bytes) is used to detect errors in a frame. It uses a cyclic redundancy check (CRC). The sending device includes the results of a CRC in the FCS field of the frame. The receiving device receives the frame and generates a CRC to look for errors. If the calculations match, no error occurred. Calculations that do not match are an indication that the data has changed; therefore, the frame is dropped. A change in the data could be the result of a disruption of the electrical signals that represent the bits.
MTU：Maximum Transmission Unit，表示Payload的最大值，只对于发送而言，接收是相对的。
MTU指的是2层Frame的payload的最大值，一般是1500Bytes。
最小payload是46bytes，所以最小Frame是64bytes。
EthernetII的Frame封装，不算Preamble和SFD，是18bytes， 即1518Bytes。
对于带VLAN tag的Frame是1522Bytes。
Linux系统下，修改接口的MTU，可以使用ifconfig命令。
Jumbo Frame这是一种厂商标准的超长帧格式，专门为千兆以太网而设计，目前还没有获得IEEE标准委员会的认可。以太网标准的最大帧长度为1518字节，而Jumbo Frame的长度各厂商有所不同，从9000字节～64000字节不等。采用Jumbo Frame能够令千兆以太网性能充分发挥，使数据传输效率提高50%～100%。在网络存储的应用环境中，Jumbo Frame更具有非同寻常的意义。
Jumbo Frame需要在相互通讯的2个通讯端口(交换机端口或网卡端口)上同时支持，而且与以前的以太网产品不兼容，因此主要会应用于千兆主干的端口之间以及服务器端口接入到网络主干的链路。交换机把Jumbo Frame格式的数据转发向不兼容Jumbo Frame的端口时应进行帧格式的转换，即把Jumbo Frame帧格式的数据转换成标准以太网的帧格式，从而保证其正常工作。相反，从不兼容Jumbo Frame的端口向支持Jumbo Frame的端口转发数据时，交换机可以把多个标准以太网帧合并成超长Jumbo Frame帧，从而提高传输效率。由于Jumbo Frame没有成为国际标准，目前只有部分厂商支持这种帧格式。不过随着以太网向千兆、万兆的发展，必然要诞生一种超长帧格式，因而Jumbo Frame从厂商标准转变为国际标准的可能性非常大。
通常人们都认为Jumbo Frame（巨型帧）是一个相对简单的技术，应该被广泛的应用在局域网中，但是情况并非如此。
应该说Jumbo帧在一些领域里是非常有用的，它是有意设计为加速大文件传输服务的。以太网标准定义的最大帧长度为1518字节，这样一个大的文件就需要被切碎成为若干块，放到多个以太网帧中。而每个数据块传输的时候都会引入帧头和尾的开销。倘若能够用一个大的帧完成文件的传输，则会减少很多帧的开销，提高网络的利用率和传输速率。通常人们认为，这一技术最大的应用瓶颈是在于至今没有标准化。
但是，有些人不这么看，许多人提出了超长帧的以下缺点：它们可能会成为融合网络的障碍。如果人们在网络上传送语音或其他对延迟敏感的内容，不需要有妨碍这些对延迟敏感数据的超长帧传输。有人举例说，超长帧会造成延迟，一旦一个‘大家伙’在线路上传送，它会较长时间占用线路，阻止其他人使用线路，从而造成延迟。
另一位读者提到超长帧可以在一条与其他网络隔离的网络中使用，因此它们不会妨碍其他传输流。存储区域网也许就是这样的一个例子。
但是首先，使用超长帧可能不再是一种优势。来自大学的两位用户说，为了了解超长帧是否能实际提高性能，他们测试了超长帧。一位用户谈道：“经过全面的测试后，我们得到的结论是：在使用现代的PC和千兆网卡时，性能提高得很少。超长帧在过去年代里的主要优势是减小高中断率对计算机的影响。但是，3GHz CPU具有处理千兆流量的充足能力，网卡和驱动程序不再需要为每一个数据包都中断一次。我们认为超长帧理论上看是一个不错的想法，但是在实际中它在千兆位时用处不大。10G以太网可能是另一个问题。
另一位用户谈道：“我们发现降低性能的原因不是协议处理开销，而是CPU与网卡缓冲区之间数据移动所产生的延迟和影响。由于DMA（直接存储器存取）尺寸越大，CPU花在设置DMA和其他东西的时间就越少，时延也减少了。随着CPU速度的增加，协议处理开销就变得越来越无足轻重。我们的结论是，如果标准的商品化网卡允许超长DMA传输，你就可以获得更大的性能增益。同时，你不必修改MTU（最大传输单元）大小，打破标准。”
最后，一位来自厂商的人提到了使用巨型帧的几个缺点。首先，帧越长意味着如果丢失一帧数据，则是一次更为严重的网络事件，而重新传送丢失的数据包成为更为耗费时间的工作。其次，网络中的每种东西都必须支持超长帧，超长帧才能使用。第三，Internet连接（WAN口）不支持超长帧：一个长度超过Internet连接所支持长度的帧将在发送前被分段，从而大大降低了Internet连接的性能和可靠性。这导致需要每一个工作站都必须知道哪个数据包传送到本地网络，哪个数据包传送到Internet。为了检测线路上的最大数据包长度，IP执行MTU路由发现算法，但是，这不是标准化的作法，并且，由于拒绝服务攻击，许多防火墙不允许与这种算法有关的ICMP数据包通过。因此，超长帧不能在与Internet连接的网络中使用。
国内关于Jumbo帧的讨论并不多，国内一些有识之士，对其应用持肯定态度，但对使用方法提出建议。 Fluke公司蔡昌信先生的看法非常有意思。他对Jumbo帧的看法有两点。首先是，他认为帧大小的选择，实际上体现的是数据通信过程中对链路可靠性的一种控制。如果说链路是非常干净的并且很少出现差错，那么这条链路上可以传输非常大的帧，而不必为此付出任何系统开销。但是问题是，人们是否认为他们的链路状况足够好，信任他们的链路状况。另一方面是，在一条链路上究竟有什么样的数据在传输。如果在一个链路上同时有实时应用的数据和对延迟并不敏感的数据在传输，那么Jumbo帧的使用，会极大地影响到实时应用（蔡先生在此用到了“kill”这个词）。他认为Jumbo帧对于一些比较纯粹的大文件传输是非常有用的，比如说SAN这样的应用。但是如果在一个多种应用混合传输的环境中，并且没有端到端的QoS策略、带宽分配设置，广泛的使用Jumbo帧是非常不理智的事情。
另一位来自厂商的朋友也表达了自己的意见，他认为如果想享用Jumbo帧所带来的好处，就需要一个能够端到端支持Jumbo帧的环境，否则的话在一些地方需要重新切帧，同样会引入更多的开销。
另一方面，支持Jumbo帧需要新的硬件，但是这同样是一个令人非常头痛的事情。这也导致了今天Jumbo帧现在仅仅在一些特殊环境使用，比如在服务器场用于数据的传输。他个人认为，从长远的角度看Jumbo帧是有好处的，而且不仅IP存储，很多应用都会从中获益。而且，新设备中支持Jumbo帧的越来越多，端到端支持是有希望的。他特别强调要端到端使用才有意义。另外，他还表示，在1000米的距离上，我们计算传输9K字节长的帧的时间，在高速网络上，并不像一些人担心的那样，会引入巨大的延迟。
本文链接：https://cs.pynote.net/net/eth/202112272/
-- EOF --
-- MORE --