标签：字节 IP ping 地址 计算机网络 MAC XMU 实验报告 数据

实验二 实验报告

一、个人信息

姓名：XXX

学号：XXXXXXXXXXXXXX

二、实验目的

• 学习捕获和分析网络数据包

• 掌握以太网MAC帧、802.11数据帧和IPv4数据包的构成，了解各字段的含义

• 掌握ICMP协议，ping和tracert指令的工作原理

• 掌握ARP协议的请求/响应机理

三、实验内容与结果分析

任务 1 捕获和分析有线以太网数据包

1.1 观察MAC帧格式

任务要求：点击Ethernet II展开，查看MAC帧。

下图是教材中 MAC 帧的格式，我将以之作为参考。

通过 Wireshark，我捕获到了如下图所示的 MAC 帧。这是通过 ping xmu.edu.cn 发出的 MAC 帧。

• 下图最开头的 \(6\) 个字节是 MAC 帧的目的地址。通过数据包中的内容，这六个字节依次是 40 fe 95 fe 80 01。这与下图左半部分 Wireshark 为我们提供的文字版分析结果相符，这个目的 MAC 地址是 40:fe:95:fe:80:01。

• 接着六个字节是 MAC 帧的源地址，数据包中这六个字节内容依次为 7c 24 99 f1 17 d2，对应左图的 MAC 源地址就是 7c:24:99:f1:17:d2，查看网卡的 MAC 地址，可以发现是相符的。此外，从这个 MAC 地址的前 24 位中，可以看出网卡的厂商。这里 Wireshark 将这个地址视为 Apple_f1:17:d2，可以看出这是苹果公司制造的网卡。

• 再接下来的两个字节是类型字段，用来标识上一层的协议。这里捕获到的 MAC 帧的协议类型是 0x0800，代表上一层是 IP 数据报。

1.2.1 观察IP数据报的首部结构——IPv4

上图是 IPv4 数据报的格式。我们捕获到的 IPv4 数据报如下图所示。

• 第一个字段是版本，占四位，在下图中高亮的一个字节的前 \(4\) 位为 \(4\)，代表这是 IPv4 数据报。

• 第二个字段是首部长度，占四位，在上图中高亮的一个字节的后 \(4\) 位为 \(5\)，代表这个 IP 数据报的首部长度为 \(5\times 32 = 160\text{bit} = 20\text{Byte}\) 。这是 IP 数据报首部的最小长度，说明这个 IP 数据报没有可选字段。
• 下面 \(8\) 位一个字节是区分服务，在这个数据报中它的值是 00。这个字段一般不被使用，因此不做分析。

• 下面两个字节为总长度，这里是 0x54 = 84 个字节，这是首部和数据部分的总长度。这说明在这个数据报中，数据部分的长度为 \(64\) 字节。实际上观察最开始的图中，IP 数据报首部剩下的部分，确实是 \(64\) 字节。

• 下面两个字节是标识，这里的值是 0x94bf，是 IP 数据报处理软件内部的一个计数器，这里因为没有进行分片，所以在这个数据报中标识字段没有什么意义。

• 下面 \(3\) 位表示标志，这里这三位全都是 \(0\)，代表这个数据报允许分片，但是已经是最后一个了。

• 接下来的十三位是片偏移，这里是 \(0\)，代表这个数据报是第一个分片。

• 接下来的一个字节是生存时间 TTL，这里的值是 0x40 = 64，因为这是刚发出的数据报，所以这个 TTL 是初始值。

• 接下来的一个字节是协议字段，指出此数据报携带的数据使用何种协议，这里代表使用了 ICMP 协议。

• 接下来两字节是首部校验和，其值为 67 ee，很容易验证这是正确的。

• 接下来的四个字节是源地址，这里为 0a 20 46 2e，转换为点分十进制表示法为 10.32.70.46。与本地 IP 相符合。（参考上一个任务的截图）

• 首部最后四个字节是目的地址，这里为 db e5 51 c8，对应的点分十进制表示为 219.229.81.200。

1.2.2 观察IP数据报的首部结构——IPv6

图文结合，说明IPv6数据报首部各个字段的含义、 帧长与数据报长的关系，并且与IPv4数据报作简单对比。

上图是 IPv6 数据报的格式。

上图高亮部分是一个 IPv6 数据报的首部，其来源是本地使用 ping6 xmu.edu.cn 的命令发送一个 IPv6 的 ICMPv6 报文。

• 首先的四位是版本字段，这里为 \(6\) 代表 IPv6 数据报。

• 接下来的 \(8\) 位是数据量类，值为 0x00，是为了区分不同的 IPv6 数据报的类别或优先 级，和IPv4的区分服务字段的作用相似，这里没什么好解读的。
• 下面 \(20\) 位是流标号，其值为 0x70300。

• 接下来两个字节是有效载荷长度，代表除基本首部以外的字节数，这里为 0x10 = 16，数一下这个 IPv6 数据报的数据部分，刚好就是 \(16\) 个字节。

• 下面八位是下一个首部字段，这里因为没有扩展首部，所以这里的值代表数据部分使用的协议，这里为 0x3a = 58，代表使用了 ICMPv6 协议。

• 下面八位是跳数限制，这里的值为 0x40 = 64，这是一个刚发出的数据报，所以这是初始值。

• 接下来的十六位是源地址，代表我的 IPv6 地址，这里的值为 2409:8734:1a70:7e4:7c57:859a:be34:719b。

• 最后的十六位是目的地址，其值为 2001:da8:e800:251c::200。

与 IPv4 数据报相比，IPv6的头部更简化，去除了一些IPv4中的字段，将如分片等需求对应的复杂字段作为扩展首部而不是基本首部，并引入了一些新的字段以适应更先进的网络需求。

1.3 IP数据报分片

因为我使用的是 MacOS，所以我将题目中给定的 Windows 命令转化成了等价的 Unix 命令。

(a) ping -4 www.xmu.edu.cn

转化：

ping www.xmu.edu.cn -c 4

可以发现，这个 命令发出了 \(4\) 个 ICMP 包，根据抓包结果，每个包发送了 \(84\) 字节的数据，去掉 \(20\) 字节的首部长度，数据部分发送了 64 字节，与终端中所示相符。

(b) ping www.xmu.edu.cn -l 1472 -f -n 1

转化：

ping -c 1 -D -s 1472 www.xmu.edu.cn

可以发现，这个命令发送了一个 ICMP 包，每个包的总长度刚好为 \(1500\)，数据部分长度为 \(1480\)。这个长度刚好到达了以太网的 MTU 限制。

(c) ping www.xmu.edu.cn -l 1473 -f -n 1

转化：

ping -c 1 -D -s 1473 www.xmu.edu.cn

可以发现，在禁止分片的情况下，发送 \(1473\) 字节的数据报根本无法发送。

(d) ping www.xmu.edu.cn -l 1473 -n 1

转化：

ping -c 1 -s 1473 www.xmu.edu.cn

可以发现，ping 命令一共发送了两次 IP 数据报。

第一次的 IP 数据报总长度 \(1500\) 字节，数据部分长度 \(1480\) 字节，其标志字段为 0x1，代表后面还有分片。其片偏移为 \(0\)，表示这是第一个分片。

第二次 IP 数据报的长度为 \(21\) 字节，数据部分长度为 \(1\) 字节，其标志字段为 0x0，表示后面没有分片了。其片偏移为 \(1480\)，代表这个分片从第 \(1481\) 个字节开始。

还可以注意到两个 IP 数据报的标识字段相同，代表这两个数据报原来是同一个数据报。

两个数据报总数据长度为 \(1481\) 字节，与终端显示结果相同。

1.4 解释ICMP报文

图文结合 ，说明执行 一 次 ping 命令 ，共有 几个ICMP 请求帧和回应帧，比较请求帧和回应帧的差别及其对应IP头部的变化。

为了保持与 Windows 的 ping 命令保持一致，我这里使用 ping www.xmu.edu.cn -c 4 来发送和接收 ICMP 报文。

如图所示，一共发送了 \(4\) 个 ICMP 请求帧并接收了 \(4\) 个 ICMP 回应帧。

上面两张图分别是发送的第一个 ICMP 请求帧，以及它对应的回应帧。

通过对比可以发现，ICMP 报文的内容（也就是对应 IP 数据报的数据部分），只有两个地方有所差别：Type 和 Checksum。Checksum 应该是 ICMP 报文的校验和，因此本质上只有 Type 有区别，也就是 ping 对应的 ICMP 请求帧和回应帧，除了校验和，在数据部分只有类型不一样，其余全部相同。

接下来看 IP 数据报的首部，通过对比可以发现只有标识字段、校验和、TTL 和发送地址、接收地址不同。发送和接收的 IP 地址发生了交换，这是很容易理解的。TTL 不同是因为这里监听到的请求帧是刚发出的，而收到的回应帧是经过了好几个路由器转发过来的。标识字段不同也很正常，这是两个不同主机上不同的计数器产生的值。校验和字段不同是因为别的首部字段不同。值得注意的是，IP 数据报的总长度字段也是相同的，这说明发送和接收的 ICMP 请求/回应帧的数据格式其实是相同的。

最后是 MAC 帧的首部。MAC 帧的首部只有 MAC 地址的源地址和目的地址发生了交换，而代表上层协议的字段相同，都是 IP 数据报。

1.5 tracert命令

图文结合，描述 tracert 工作原理，画出示意图。

因为我使用的是 MacOS，所以我使用了 Unix 上与 Windows 的 tracert 类似的 traceroute 命令。

我们通过 traceroute www.xmu.edu.cn 得到了上面的结果。注意到第 \(3\) 跳的结果是三个星号，这代表发出的三个包全部请求超时，没有收到回复。这可能是因为那一跳的路由器禁 ping，也有可能是那一跳的路由器不对 TTL 超时做响应处理，而是直接丢弃。

通过 Wiresharp 可以过滤出这个命令发出和接收的包。

因为包数太多，不方便每一个包的内容展开截图，但是通过观察可以发现，对于第 \(1, 2, 4, 5\) 跳，每一跳都会发出一个 TTL 等于对应的跳数的 UDP 包，这个包是无法交付的。在路由器转发的过程中，TTL 的值每经过一个路由器就会减小一，因此一开始填入的 TTL 是多少，就会在第几跳的路由器上发生 TTL 超时，这个时候，路由器就会发出一个 ICMP 时间超过差错报告报文，从而让我们知道这一跳的路由器的 IP 是多少。

通过捕获的结果可以发现，每一跳其实都会发出三次 UDP 包，每一个包都会对应一个 ICMP 差错报告的回应。

而第 \(3\) 跳没有收到时间超过的差错报告，而是直接请求超时，没有收到任何回应。这里可能的原因之前已经有所分析。

第 \(6\) 跳我们到达了目标主机，因此收到的不是 TTL 超时的 ICMP 差错报告了，而是因为我们发送的是不可交付的 UDP 包，所以收到了 ICMP 终点不可达的差错报告。

示意图如下：

1.6 ARP协议分析

图文结合，解释ARP报文(请求/响应)每个字段的含义; ping同一局域网的计算机和局域网外的计算机，产生的ARP请求有何不同，结合课本上的工作原理进行说明。

首先清空 ARP 缓存：

当然，为了防止在清空 ARP 之后，发出 ping 指令之前，有过网络流量，导致产生了多余的 ARP 缓存，我们将清空 ARP、ping 局域网内的主机、ping 局域网外的主机的三条命令放在一起执行：

可以观察到网络流量如下：

可以发现，在发出对 192.168.0.199 的 ping 之前，我们的主机发出了一条 Who has 192.168.0.199? Tell 192.168.0.196 的 ARP 询问，它询问了拥有 IP 地址 192.168.0.199 的主机的 MAC 地址。

而在发生对 www.baidu.com 的 ping 命令之前，我们的主机发出的却是 Who has 192.168.0.1? Tell 192.168.0.196 的 ARP 询问，它询问的却是 192.168.0.1 的 MAC 地址。这是我们的局域网内的路由器的 IP。这是因为 www.baidu.com(14.119.104.254) 是我们局域网外的主机，想要对它发送数据报需要通过路由器中转，因此我们要将数据发送给路由器，所以要通过 ARP 协议获得路由器 192.168.0.1 的 MAC 地址。

分析 ARP 请求的字段：

开头的 \(14\) 个字节是 MAC 首部，其中，目标 MAC 地址是 FF:FF:FF:FF:FF:FF，表示向局域网中所有主机广播，而源地址是我们自己机器的地址，类型字段是 ARP(0x0806)。

下面是 ARP 协议内容。首先开头的两个字节表示局域网的硬件地址类型，这里是 0x1 表示以太网。

然后两个字节表示 IP 协议的类型，而这里使用的是 IPv4 协议，所以是 0x0800。

下面是两个各占一个字节的字段：Hardware size 和 Protocol size，表示 MAC 地址的字节数和 IP 地址的字节数。

下面是一个字节的 Opcode，表示这个 ARP 包是响应还是请求，这里是 0x1 表示请求。

接下来一个 \(6\) 个字节是发送者的 MAC 地址（这里是 7c:24:99:f1:17:d2），然后 \(4\) 个字节是发送者的 IP 地址（这里是 192.168.0.196 的十六进制表示）。

接下来的 \(6\) 个字节，留空，因为我们不知道询问对象的 MAC 地址。最后的四个字节是询问对象的 IP 地址，这里是 192.168.0.199 的十六进制表示，这是我们想要询问 MAC 地址的 IP 地址。

分析 ARP 回应字段：

ARP 回应字段大体上的格式与请求字段相同，主要的差别在于：

• MAC 帧首部的源地址和目的地址都是具体的 MAC 地址了，因为这不再是广播，而是由之前的被询问对象发回来的回应。
• ARP 数据的 Opcode 变成了 2，表示这是 ARP 回应。
• ARP 数据中发送者和接受者的 MAC 地址字段都不为空，因为这是对于 ARP 请求的回应，应该告诉请求者自己的 MAC 地址。

任务 2 捕获和分析 802.11 数据

过滤出本机相关的802.11控制帧、数据帧、管理帧，并进行分析。

首先，因为我是用的是 MacOS 系统，所以需要先设置无线网卡工作于监听模式。这里可以将 MacOS 的无线网络管理工具 airport 添加到环境中，然后运行命令启动监听模式：

ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/bin/airport
airport sniff

然后，在 Wireshark 中选择以监听模式启动捕获：

控制帧

802.11 协议中的控制帧协助数据帧的传输，负责无线信道的清空、信道的获取等，还用于接收数据时的确认。

因此，我们可以发现我们捕获到的控制帧包含了许多关于 Wi-Fi 信道的信息，如最后最后一列的信息中的 SSID 都是 Wi-Fi 的名字。

这里以一个控制帧中的 Beacon Frame 为例，分析帧结构：

• 首先是 \(36\) 个字节的 Radiotap Header，里面规定了一些版本、数据率、时间戳等和信道相关的信息。

• 接着是和 Beacon 控制帧有关的信息，如帧类型、帧控制、接收地址、发送地址、BSS Id 和分片号。
• 最后是控制帧的数据部分。

管理帧

管理帧负责对无线网络的管理，包括网络信息通告、加入或退出无线网络，射频管理等。

可以发现管理帧的结构和控制帧很相似。

• 首先是 \(56\) 个字节的 Radiotap Header，这比控制帧的相应字段要长，主要是多了一个 Vendor namespace。

• 然后根据管理帧的不同类型，相应的结构也不完全相同。这里以 Request-to-send 帧为例，其内容是一开始一个类型字段，接着帧控制字段、持续期、接收地址、发送地址和校验和。

数据帧

数据帧负责传输数据报文，包括一种帧主体部分为空的特殊报文（Null帧）

• 首先依然是和前面两种帧类似的 Radiotap Header。

• 接着是数据帧的首部。数据帧的首部结构可以参照上图，包含帧类型、帧控制字段、持续期、若干地址（目标地址、源地址）、序号控制、分片号和校验和。

• 最后是数据帧的数据部分。

任务3.1 探索Wireshark更丰富的功能

数据流追踪

这里，我将一张图片发送到了 IP 为 10.26.35.248 的服务器。捕获到的发送流量如下：

可以发现，由于图片文件较大，TCP 协议会将其分成若干个数据段，每个数据段都是一个独立的IP数据包。

当我们使用「数据流捕获」的功能时，会弹出该流的完整数据流。还有这个数据流中包含的数据包。

协议分层统计

在进行这个任务的实验之前，我将 Wireshark 挂在后台进行捕获十分钟，在此期间正常进行访问网页、聊天、进行 ssh 工作等任务，以保证数据的普遍性。

分层统计结果如下：

四、实验小结

本次实验让我深入了解了网络数据包的结构和通信过程，通过捕获和分析各种帧和协议，我对网络通信有了更清晰的认识。

我学到了如何使用 Wireshark 捕获和分析以太网和802.11网络中的数据包。通过观察MAC帧、IPv4和IPv6数据包的结构，我更深刻地理解了网络通信的基本原理。特别是IPv4和IPv6数据包的首部结构对比，展示了IPv6相对于IPv4的简化和改进。

在IP数据报分片的任务中，通过对ping命令的不同参数的使用，我了解了IP数据报分片的原理和实际应用。这使我更加熟悉了网络通信中的一些细节，比如数据报的分片和重组。

通过分析ICMP报文，我深入了解了ping命令的工作原理，以及请求帧和回应帧的区别。这让我对网络工具的实际应用产生了更多兴趣。

在tracert命令的分析中，我了解了tracert的工作原理，以及如何通过TTL超时的差错报告来追踪数据包在网络中的路径。这展示了网络工具在排查网络问题时的实际应用。

在802.11数据的捕获和分析中，我对控制帧、管理帧和数据帧的功能和结构有了更深入的了解。通过追踪数据流，我理解了数据在网络中的传输过程，以及Wireshark强大的功能。

通过协议分层统计，我对网络通信中各种协议的使用情况有了更全面的认识。这让我感受到了网络通信的复杂性和多样性。

这次实验让我不仅学到了网络通信的理论知识，还通过实际操作深入体验了网络工具的应用。这种实践性的学习方式让我更好地理解了计算机网络这一复杂而又精彩的领域。

标签：字节,IP,ping,地址,计算机网络,MAC,XMU,实验报告,数据
From： https://www.cnblogs.com/hankeke303/p/18162940/XMU-Network-Lab2