2。1。0以太网以太网帧格式与IP报文分片

　　一、以太网数据帧信息简介
　　以太网有两种类型的数据帧，一种是Ethernet_II另一种是IEEE802.3。
　　两者并没有明确的规定两种类型的使用场景，通常都是由协议/应用程序的开发者定义的。
　　通过观察发现：应用程序产生的包大多为Ethernet_II部分网络协议工作时产生的包为IEEE802.3（如：STP产生的BPDU）
　　DMAC字段（目标的MAC地址）
　　SMAC字段（发送者的MAC地址）
　　Type字段（描述Data中的封装的报文类型）常见类型：ARP[0x0806]、IP[0x0800]、VLAN[0x8100]
　　Data字段（用户数据，其中还包含IP报头、TCP/UDP报头）其中的封装可以看作以下的抽象描述：  【          Data数据            】 【     IP报头【Data数据】        】 【  IP报头【TCP报头【用户数据】】 】
　　FCS字段（以太网校验字段，校验方法为循环冗余检验）二、以太网数据帧长度以太网数据帧及封装
　　以太网帧最短帧长度为64Byte（字节）、最长1518Byte，当超过1518Byte之后的数据帧就需要进行一个分片处理。
　　以太网帧所占用的长度为：DMAC+SMAC+Type+FCS=18Byte。
　　已知最短帧长为64Byte，减去以太网18Byte之后就说明Date字段封装内容最短需要有46Byte。
　　46Byte中还包含着IP报头与TCP或UDP报头：46Byte减去IP报头的20Byte=26Byte当内部封装TCP时：26Byte减去TCP报头20Byte=6Byte当内部封装UDP时：26Byte减去UDP报头8Byte=18Byte
　　得出的结果大小，也就是实际用户数据的最小长度。三、数据填充如果不满足最短帧长会怎样？
　　 以太网帧中的Data字段会自行填充0，直到满足最短帧长。
　　疑惑：理论上说以太网帧不满足最小帧长，Data字段会填充0，但在终端所发送的包中并没有体现出来。
　　 以下是抓包用户发送的ICMP数据包结果，可以看了总帧长为45Byte（并没有将FCS字段长度计算在内），用户实际长度为3Byte，完全不符合最小帧长度的要求。
　　网络设备这边，则是能够正常的进行填充，实现数据帧满足最小帧长要求
　　 网络设备这边可以看到帧长度为60Byte（加上FCS字段4byte就满足了最小64Byte帧长了）如何计算填充多少字节？64Byte-18Byte(以太网帧长度)-20Byte(IP报头)-8Byte(ICMP属于UDP报文占8Byte)-3Byte(实际发送长度)  =64-18-20-8-3   =15Byte
　　四、数据分片
　　以太网帧最短帧长度为64Byte（字节）、最长1518Byte，当超过1518Byte之后的数据帧就需要进行一个分片处理。为什么数据包需要分片呢？
　　 因为有MTU（最大传输单元）限制，网络设备限制最大传输的MTU大小为1500Byte（此处的1500Byte指的是以太网中Data字段大小限制在1500Byte内），超过MTU值的数据包就需要进行分片，将数据包分成小于/等于MTU值大小的数据分片，到了目的地再组装起来。
　　换名话讲，当以太网帧长度大于1518Byte就需要进行分片。如果数据包大小大于1518Byte，我强制不分片会怎样？
　　 会禁止发送该不正常的数据包。