【实验作业】
1 观察并分析通常的以太网帧
1.1 以太网帧格式
目前主要有两种格式的以太网帧：Ethernet II（DIX 2.0）和IEEE 802.3。我们接触过的IP、ARP、EAP和QICQ协议使用Ethernet II帧结构，而STP协议则使用IEEE 802.3帧结构。
Ethernet II是由Xerox与DEC、Intel（DIX）在1982年制定的以太网标准帧格式，后来被定义在RFC894中。IEEE 802.3是IEEE 802委员会在1985年公布的以太网标准封装结构（可以看出二者时间相差不多，竞争激烈），RFC1042规定了该标准（但终究二者都写进了IAB管理的RFC文档中）。
下图分别给出了Ethernet II和IEEE 802.3的帧格式：
⑴ 前导码（Preamble）：由0、1间隔代码组成，用来通知目标站作好接收准备。以太网帧则使用8个字节的0、1间隔代码作为起始符。IEEE 802.3帧的前导码占用前7个字节，第8个字节是两个连续的代码1，名称为帧首定界符（SOF），表示一帧实际开始。
⑵ 目标地址和源地址（Destination Address & Source Address）：表示发送和接收帧的工作站的地址，各占据6个字节。其中，目标地址可以是单址，也可以是多点传送或广播地址。
⑶ 类型（Type）或长度（Length）：这两个字节在Ethernet II帧中表示类型（Type），指定接收数据的高层协议类型。而在IEEE 802.3帧中表示长度（Length），说明后面数据段的长度。
⑷ 数据（Data）：在经过物理层和逻辑链路层的处理之后，包含在帧中的数据将被传递给在类型段中指定的高层协议。该数据段的长度最小应当不低于46个字节，最大应不超过1500字节。如果数据段长度过小，那么将会在数据段后自动填充（Trailer）字符。相反，如果数据段长度过大，那么将会把数据段分段后传输。在IEEE 802.3帧中该部分还包含802.2的头部信息。
⑸ 帧校验序列（FSC）：包含长度为4个字节的循环冗余校验值（CRC），由发送设备计算产生，在接收方被重新计算以确定帧在传送过程中是否被损坏。
1.2 实例分析
Ⅰ．Ethernet II帧分析
这一帧的长度是60字节，小于最小帧长64字节。对比1.1帧结构可以发现，前导码（Preamble）的8个字节已经被去除，因而实际帧长是68字节。目的地址（Destination Address）为[5c:26:0a:7e:3b:c7]，源地址（Source Address）为[f0:de:f1:ab:41:d8]。类型（Type）为[0x0800]，表示该帧封装的高层协议类型是IP协议。数据（Data）为[45 00 „„ 00 65]，因为长度低于46个字节，该数据段自动填充（Trailer）了一段字符。对比1.1帧结构可以发现，该帧没有帧校验序列（FSC），可能是抓到包时校验序列已经被底层去除（但是第5周802.1x接入实验中的EAPOE协议帧中有帧校验序列）。
Ⅱ．IEEE 802.3帧分析
这一帧的长度也是60字节，前导码的8个字节同样已经被去除，因而实际帧长也是68字节。目的地址为[01:80:c2:00:00:00]（解析为网桥间的生成树），源地址为[3c:e5:a6:f7:a9:f8]。长度（Length）为39字节，表示该帧封装的上层协议数据总长度为39字节。数据为[42 42 „„ 00 00]，因为数据长度为39字节低于46个字节，因此自动填充了一段字符。该帧同样没有帧校验序列。
2 ping同学的IP地址，分析帧，得到自己和同学的mac地址
开始做这个实验时，尝试去ping隔壁宿舍同学的IP地址[10.104.137.124]，但结果却不如人愿，无法ping到其主机，结果如下图：
同时用Wireshark抓包，得到了如下结果：
分析无法ping到的原因，本机一直广播发送ARP请求，询问哪个端口有[10.104.137.124]这台机器，但是却没有回应。这个问题作为思考题1进行分析。
后来去ping本宿舍（连接着同一交换机）的主机IP[10.104.137.106]获得了成功，结果如下图：
接受到了长度为32字节的回复数据包。同时用Wireshark抓包，通过下面一个ping的回应帧，可以得到自己和同学的MAC地址，结果如下图：
得到目标地址（因为是回应帧，因此这是自己的MAC地址）为[5c:26:0a:7e:3b:c7]，解析的制造商为Dell（对应自己的Dell笔记本）。源地址（同学的MAC地址）为[f0:de:f1:ab:41:d8]，解析的制造商为Wistron（同学是联想笔记本，而网卡是第三方纬创集团，可见国产品牌还需提高整体实力）。
3 验证用其他方法得到的mac地址是否一致
获取本机MAC地址的方法有多种，这里使用方法“运行 -> cmd -> getmac”验证MAC地址。结果如下两图，分别在自己和同学的机器上获得本机MAC地址。
结果与ping得到的MAC地址相符，自己的MAC地址为[5c:26:0a:7e:3b:c7]，同学的MAC地址为
[f0:de:f1:ab:41:d8]。
4 观察ARP请求帧中目标MAC地址的格式(以太网广播地址)
4.1 ARP原理
假设A要给B发送一个数据包，需要在帧头中填写B的MAC地址。但是这时计算机A可能只知道B的IP地址却不知道B的MAC地址，于是，在A不知道B的MAC地址的情况下，A就广播一个ARP请求包，请求包中填有B的IP，B收到请求后回应ARP应答包给A，其中含有B的MAC地址，这样A就可以开始向B发送数据包了。
4.2 ARP请求帧地址分析
用Wireshark抓包得到大量ARP帧，其中一个请求帧如下图：
目标MAC地址为[ff:ff:ff:ff:ff:ff]，表示广播发送。观察发现不只这一帧如此，所有ARP请求帧的目标MAC地址都是[ff:ff:ff:ff:ff:ff]。这一点由ARP原理很好理解，因为ARP请求帧的作用就是寻找自己不知道MAC地址的目标，因此必须采取广播的方式达到希望的目的。
5 观察最大帧长和最小帧长
5.1 理论分析
这里有必要再重现一下以太网帧的标准格式。因为单就长度而言，Ethernet II和IEEE 802.3的帧并无区别，因此这里只通过前者进行分析。Ethernet II的帧格式如下图：
理论上的最大帧长和最小帧长可以很容易地由图得到：
最大帧长：8+6+6+2+1500+4=1526字节
最小帧长：8+6+6+2+46+4=72字节
这两个结果很出乎意料，因为课本（同样是理论）告诉我们，以太网帧的最大帧长是1518字节（或是802.1Q提出的1522字节），最小帧长是64字节，这是什么原因呢？
初步推测，当数据帧到达网卡时，在物理层上网卡要去掉8字节的前导码（Preamble），所以，实际抓到的包是去掉前导码之后的数据：
最大帧长：6+6+2+1500+4=1518字节
最小帧长：6+6+2+46+4=64字节
这与课本符合的很好，那么实际是否能得到理论分析的结果呢？
5.2 实验检验
我们采用ping -l size命令来进行验证。首先，通过命令行“ping -l -1（不可能存在的size）”可以得到ping -l的测试范围为[0-65500]。，结果如下图：
不难想象，最小帧长应该是size=0时取得。用过命令行“ping -l 0 10.104.137.106（同宿舍同学的主机IP地址）”观察最短帧长，结果如下图：
上图表示ping到了size=0的帧。同时用Wireshark抓包，获得了多组ping请求/回应数据包，每组的数据和长度都相同，其中的一组ping请求/回应帧如下图：
出乎意料的是，这两帧的长度都小于理论分析的64字节。不仅如此，每一组的请求帧（左侧）都是长度为42字节（出奇的小）的出错帧（IP数据包的头校验和错误）。这个结果不禁让我们开始怀疑之前理论分析的最小帧长，难道最小帧长是左边抓到的42字节？
在分析这个问题之前，我们先用命令行“ping -l 1 10.104.137.106”尝试ping一下size=1的帧，抓包同样得到了多组等长的ping请求/回应帧，其中一组如下图：
这两帧的长度同样出人意料：不只因为长度仍都小于64字节，而是对比上一组size=0的ping请求/回应帧，这一组size=1的请求帧增加了1字节（由42变为43），而回应帧的长度没有变化！（仍是60字节）。这个结果是不符合道理的。
通过观察与分析，我们可以得出一个初步结论：Wireshark抓到的所有ping请求帧都是还未封装完成的帧，他们都没有将填充（Trailer）字符加到数据段后面就被抓包软件截获了，自然这些“半成品”被误认为是“残次品”处理，IP数据的头校验和错误应该也与此有关。因此，实际的最小帧长应该是ping回应帧的60字节。
问题仍然没有解决：为什么最小帧长是60字节而不是理论得出的64字节？对比以太网标准帧结构进一步观察，我们发现问题出在4字节的帧校验序列（FSC）上。当数据帧到达网卡时，在物理层上网
卡先去掉8字节的前导码，然后对帧进行CRC检验，并通过帧校验序列判断。如果帧校验和错，就丢弃此帧。如果校验和正确，并且目的地址是否符合接收条件，就将帧交给上层做进一步处理，同时去掉这4字节的校验码。因此，实际抓到的包是去掉前导码和帧校验序列之后的数据：
最大帧长：6+6+2+1500=1514字节
最小帧长：6+6+2+46=60字节
最小帧长的实验结果符合我们的分析，下面我们验证最大帧长。究竟size等于多少可以取得最大帧长的帧，我们并不能简单得到。事实上，我们指定的size的值是ping帧封装的ICMP协议数据包的数据（Data）部分的长度。而所有头部（MAC头+IP头+ICMP头）的长度可以由上面size=0的60字节的回应帧得到，即为填充（Trailer）字段前面的数据长度：42字节。因此，最大帧长的size=1514-42=1472。 为了验证我们的结论，我们采用命令行“ping -l 1472 -f（设置数据包不分段） 10.104.137.106”和“ping -l 1473 -f 10.104.137.106”验证ping最大帧长的临界值。结果如下二图：
同时用Wireshark抓包，获得了多组ping请求/回应数据包，其中的一组ping请求/回应帧如下图：
ping请求帧的长度为1514字节，这就是实际的最大帧长。数据部分长度为我们指定的size=1472字节，符合我们的分析。但是，IP头校验和仍然是错误的，因此可以判断错误的原因并不是我们之前所想象的那样，该帧还没有来得及加上填充字符（这一帧已经不需要填充字符）。
ping回应帧的长度并不是1514字节，而是最小帧长60字节，这是为什么呢？观察ICMP协议数据包上面的IP分组（IP Fragments）可以发现，回应帧的IP协议数据包被分为了两帧，我们请求的1472字节IMCP协议数据加上8字节的IMCP头部被分成了两段，分别被封装在第15、16帧中。结果如下图： 字节ICMP头部
8字节数据
因为对方回应的IMCP协议数据包的长度为带头部的1480字节，超过了请求的1472字节，因此对方机器自动将数据分组，在第15帧中封装了8字节的IMCP头部和1464字节的数据，在第16帧中只封装了剩余的8字节数据。
实验说明，我们在命令行中增加的-f只是控制了本机发出的ping请求帧不分段（一旦分段就提示需要拆分数据包），而无法保证对方回应的ping数据不分段。
5.3 结论
实际传输的最大帧长：1518字节，最小帧长：64字节
能抓包得到的最大帧长：1514字节，最小帧长：60字节（不考虑未完成的帧）
6 观察封装IP和ARP的帧中的类型字段
任意选择ARP和IP各一帧如下图：
可知ARP协议的类型是[0x0806]，IP协议的类型是[0x0800]。
【实验作业】
1 观察并分析通常的以太网帧
1.1 以太网帧格式
目前主要有两种格式的以太网帧：Ethernet II（DIX 2.0）和IEEE 802.3。我们接触过的IP、ARP、EAP和QICQ协议使用Ethernet II帧结构，而STP协议则使用IEEE 802.3帧结构。
Ethernet II是由Xerox与DEC、Intel（DIX）在1982年制定的以太网标准帧格式，后来被定义在RFC894中。IEEE 802.3是IEEE 802委员会在1985年公布的以太网标准封装结构（可以看出二者时间相差不多，竞争激烈），RFC1042规定了该标准（但终究二者都写进了IAB管理的RFC文档中）。
下图分别给出了Ethernet II和IEEE 802.3的帧格式：
⑴ 前导码（Preamble）：由0、1间隔代码组成，用来通知目标站作好接收准备。以太网帧则使用8个字节的0、1间隔代码作为起始符。IEEE 802.3帧的前导码占用前7个字节，第8个字节是两个连续的代码1，名称为帧首定界符（SOF），表示一帧实际开始。
⑵ 目标地址和源地址（Destination Address & Source Address）：表示发送和接收帧的工作站的地址，各占据6个字节。其中，目标地址可以是单址，也可以是多点传送或广播地址。
⑶ 类型（Type）或长度（Length）：这两个字节在Ethernet II帧中表示类型（Type），指定接收数据的高层协议类型。而在IEEE 802.3帧中表示长度（Length），说明后面数据段的长度。
⑷ 数据（Data）：在经过物理层和逻辑链路层的处理之后，包含在帧中的数据将被传递给在类型段中指定的高层协议。该数据段的长度最小应当不低于46个字节，最大应不超过1500字节。如果数据段长度过小，那么将会在数据段后自动填充（Trailer）字符。相反，如果数据段长度过大，那么将会把数据段分段后传输。在IEEE 802.3帧中该部分还包含802.2的头部信息。
⑸ 帧校验序列（FSC）：包含长度为4个字节的循环冗余校验值（CRC），由发送设备计算产生，在接收方被重新计算以确定帧在传送过程中是否被损坏。
1.2 实例分析
Ⅰ．Ethernet II帧分析
这一帧的长度是60字节，小于最小帧长64字节。对比1.1帧结构可以发现，前导码（Preamble）的8个字节已经被去除，因而实际帧长是68字节。目的地址（Destination Address）为[5c:26:0a:7e:3b:c7]，源地址（Source Address）为[f0:de:f1:ab:41:d8]。类型（Type）为[0x0800]，表示该帧封装的高层协议类型是IP协议。数据（Data）为[45 00 „„ 00 65]，因为长度低于46个字节，该数据段自动填充（Trailer）了一段字符。对比1.1帧结构可以发现，该帧没有帧校验序列（FSC），可能是抓到包时校验序列已经被底层去除（但是第5周802.1x接入实验中的EAPOE协议帧中有帧校验序列）。
Ⅱ．IEEE 802.3帧分析
这一帧的长度也是60字节，前导码的8个字节同样已经被去除，因而实际帧长也是68字节。目的地址为[01:80:c2:00:00:00]（解析为网桥间的生成树），源地址为[3c:e5:a6:f7:a9:f8]。长度（Length）为39字节，表示该帧封装的上层协议数据总长度为39字节。数据为[42 42 „„ 00 00]，因为数据长度为39字节低于46个字节，因此自动填充了一段字符。该帧同样没有帧校验序列。
2 ping同学的IP地址，分析帧，得到自己和同学的mac地址
开始做这个实验时，尝试去ping隔壁宿舍同学的IP地址[10.104.137.124]，但结果却不如人愿，无法ping到其主机，结果如下图：
同时用Wireshark抓包，得到了如下结果：
分析无法ping到的原因，本机一直广播发送ARP请求，询问哪个端口有[10.104.137.124]这台机器，但是却没有回应。这个问题作为思考题1进行分析。
后来去ping本宿舍（连接着同一交换机）的主机IP[10.104.137.106]获得了成功，结果如下图：
接受到了长度为32字节的回复数据包。同时用Wireshark抓包，通过下面一个ping的回应帧，可以得到自己和同学的MAC地址，结果如下图：
得到目标地址（因为是回应帧，因此这是自己的MAC地址）为[5c:26:0a:7e:3b:c7]，解析的制造商为Dell（对应自己的Dell笔记本）。源地址（同学的MAC地址）为[f0:de:f1:ab:41:d8]，解析的制造商为Wistron（同学是联想笔记本，而网卡是第三方纬创集团，可见国产品牌还需提高整体实力）。
3 验证用其他方法得到的mac地址是否一致
获取本机MAC地址的方法有多种，这里使用方法“运行 -> cmd -> getmac”验证MAC地址。结果如下两图，分别在自己和同学的机器上获得本机MAC地址。
结果与ping得到的MAC地址相符，自己的MAC地址为[5c:26:0a:7e:3b:c7]，同学的MAC地址为
[f0:de:f1:ab:41:d8]。
4 观察ARP请求帧中目标MAC地址的格式(以太网广播地址)
4.1 ARP原理
假设A要给B发送一个数据包，需要在帧头中填写B的MAC地址。但是这时计算机A可能只知道B的IP地址却不知道B的MAC地址，于是，在A不知道B的MAC地址的情况下，A就广播一个ARP请求包，请求包中填有B的IP，B收到请求后回应ARP应答包给A，其中含有B的MAC地址，这样A就可以开始向B发送数据包了。
4.2 ARP请求帧地址分析
用Wireshark抓包得到大量ARP帧，其中一个请求帧如下图：
目标MAC地址为[ff:ff:ff:ff:ff:ff]，表示广播发送。观察发现不只这一帧如此，所有ARP请求帧的目标MAC地址都是[ff:ff:ff:ff:ff:ff]。这一点由ARP原理很好理解，因为ARP请求帧的作用就是寻找自己不知道MAC地址的目标，因此必须采取广播的方式达到希望的目的。
5 观察最大帧长和最小帧长
5.1 理论分析
这里有必要再重现一下以太网帧的标准格式。因为单就长度而言，Ethernet II和IEEE 802.3的帧并无区别，因此这里只通过前者进行分析。Ethernet II的帧格式如下图：
理论上的最大帧长和最小帧长可以很容易地由图得到：
最大帧长：8+6+6+2+1500+4=1526字节
最小帧长：8+6+6+2+46+4=72字节
这两个结果很出乎意料，因为课本（同样是理论）告诉我们，以太网帧的最大帧长是1518字节（或是802.1Q提出的1522字节），最小帧长是64字节，这是什么原因呢？
初步推测，当数据帧到达网卡时，在物理层上网卡要去掉8字节的前导码（Preamble），所以，实际抓到的包是去掉前导码之后的数据：
最大帧长：6+6+2+1500+4=1518字节
最小帧长：6+6+2+46+4=64字节
这与课本符合的很好，那么实际是否能得到理论分析的结果呢？
5.2 实验检验
我们采用ping -l size命令来进行验证。首先，通过命令行“ping -l -1（不可能存在的size）”可以得到ping -l的测试范围为[0-65500]。，结果如下图：
不难想象，最小帧长应该是size=0时取得。用过命令行“ping -l 0 10.104.137.106（同宿舍同学的主机IP地址）”观察最短帧长，结果如下图：
上图表示ping到了size=0的帧。同时用Wireshark抓包，获得了多组ping请求/回应数据包，每组的数据和长度都相同，其中的一组ping请求/回应帧如下图：
出乎意料的是，这两帧的长度都小于理论分析的64字节。不仅如此，每一组的请求帧（左侧）都是长度为42字节（出奇的小）的出错帧（IP数据包的头校验和错误）。这个结果不禁让我们开始怀疑之前理论分析的最小帧长，难道最小帧长是左边抓到的42字节？
在分析这个问题之前，我们先用命令行“ping -l 1 10.104.137.106”尝试ping一下size=1的帧，抓包同样得到了多组等长的ping请求/回应帧，其中一组如下图：
这两帧的长度同样出人意料：不只因为长度仍都小于64字节，而是对比上一组size=0的ping请求/回应帧，这一组size=1的请求帧增加了1字节（由42变为43），而回应帧的长度没有变化！（仍是60字节）。这个结果是不符合道理的。
通过观察与分析，我们可以得出一个初步结论：Wireshark抓到的所有ping请求帧都是还未封装完成的帧，他们都没有将填充（Trailer）字符加到数据段后面就被抓包软件截获了，自然这些“半成品”被误认为是“残次品”处理，IP数据的头校验和错误应该也与此有关。因此，实际的最小帧长应该是ping回应帧的60字节。
问题仍然没有解决：为什么最小帧长是60字节而不是理论得出的64字节？对比以太网标准帧结构进一步观察，我们发现问题出在4字节的帧校验序列（FSC）上。当数据帧到达网卡时，在物理层上网
卡先去掉8字节的前导码，然后对帧进行CRC检验，并通过帧校验序列判断。如果帧校验和错，就丢弃此帧。如果校验和正确，并且目的地址是否符合接收条件，就将帧交给上层做进一步处理，同时去掉这4字节的校验码。因此，实际抓到的包是去掉前导码和帧校验序列之后的数据：
最大帧长：6+6+2+1500=1514字节
最小帧长：6+6+2+46=60字节
最小帧长的实验结果符合我们的分析，下面我们验证最大帧长。究竟size等于多少可以取得最大帧长的帧，我们并不能简单得到。事实上，我们指定的size的值是ping帧封装的ICMP协议数据包的数据（Data）部分的长度。而所有头部（MAC头+IP头+ICMP头）的长度可以由上面size=0的60字节的回应帧得到，即为填充（Trailer）字段前面的数据长度：42字节。因此，最大帧长的size=1514-42=1472。 为了验证我们的结论，我们采用命令行“ping -l 1472 -f（设置数据包不分段） 10.104.137.106”和“ping -l 1473 -f 10.104.137.106”验证ping最大帧长的临界值。结果如下二图：
同时用Wireshark抓包，获得了多组ping请求/回应数据包，其中的一组ping请求/回应帧如下图：
ping请求帧的长度为1514字节，这就是实际的最大帧长。数据部分长度为我们指定的size=1472字节，符合我们的分析。但是，IP头校验和仍然是错误的，因此可以判断错误的原因并不是我们之前所想象的那样，该帧还没有来得及加上填充字符（这一帧已经不需要填充字符）。
ping回应帧的长度并不是1514字节，而是最小帧长60字节，这是为什么呢？观察ICMP协议数据包上面的IP分组（IP Fragments）可以发现，回应帧的IP协议数据包被分为了两帧，我们请求的1472字节IMCP协议数据加上8字节的IMCP头部被分成了两段，分别被封装在第15、16帧中。结果如下图： 字节ICMP头部
8字节数据
因为对方回应的IMCP协议数据包的长度为带头部的1480字节，超过了请求的1472字节，因此对方机器自动将数据分组，在第15帧中封装了8字节的IMCP头部和1464字节的数据，在第16帧中只封装了剩余的8字节数据。
实验说明，我们在命令行中增加的-f只是控制了本机发出的ping请求帧不分段（一旦分段就提示需要拆分数据包），而无法保证对方回应的ping数据不分段。
5.3 结论
实际传输的最大帧长：1518字节，最小帧长：64字节
能抓包得到的最大帧长：1514字节，最小帧长：60字节（不考虑未完成的帧）
6 观察封装IP和ARP的帧中的类型字段
任意选择ARP和IP各一帧如下图：
可知ARP协议的类型是[0x0806]，IP协议的类型是[0x0800]。