企业官网建设流程全解析

简介：北航研究生计算机网络实验三报告是一份聚焦地址解析协议与网络层工作原理的实验资料，面向计算机网络课程学生、考研复试者及需要借助网络封包分析工具进行抓包学习的初学者。报告以实际操作为主线，完整记录了地址解析请求与应答报文的字段解析、同网段与跨网段通信时地址解析交互的差异、地址解析缓存对通信效率的影响，以及默认网关在跨路由转发中的关键作用。同时，内容还涵盖网际控制消息协议的回送请求与应答、地址掩码请求、时间戳请求等常见类型，能够帮助读者系统掌握网络层地址映射机制，并提升网络排错能力。压缩包仅含一个 PDF 文件，体积 40KB，轻便易阅，适合按步骤对照学习。目前已有 111 人学习下载，是一份针对性强、适合实践教学的北航实验参考资料。

1. 这份北航研究生计算机网络实验：把 ARP 和 ICMP 报文从黑匣子变成可复现的抓包步骤

拿到这份北航研究生计算机网络实验报告的时候，我原本以为又是一份填表交差的课程存档。翻到实验 3 的网络层部分才发现，整篇都在做同一件事：把 ARP 缓存解析、默认网关选路、ICMP 各种 Type/Code 报文全部拿 Wireshark 实测数据做了一道对照。从 192.168.1.22 这台 VMware 虚拟机出发，实验依次覆盖了空缓存状态、同网段 ARP、跨网段 ARP 和 tracert 路径探测，每一张表都能落回报文里的真实字段值。这份资源适合所有想把计算机网络自顶向下那套理论落实为抓包实操的人：研一新生能照着 arp -d、ping、arp -a 三步复现整个流程；有基础的读者可以直接把报告里的 Type/Code 字段表当作排错速查来用。它最大的价值不是结论本身，而是每一条结论背后都有真实抓包数据在支撑，读一遍比自己对着教材猜协议流程要稳得多。

2. ARP 请求与应答：用 Opcode 和六个地址字段还原解析全过程

2.1 ARP 缓存是理解一切的起点：从空缓存到 dynamic 条目

报告的第一个实验动作很讲究：在 2.6.1 步骤 2 里先执行了一次 ARP 查询命令，结果只有一行 “No ARP Entries Found”，随后在步骤 4 再查，缓存里就有了新条目。这两个状态一对比，其实就是 ARP 机制最小闭环的演示。步骤 2 对应刚开机、还没有和对端通信过的状态，缓存自然为空；步骤 4 对应 ping 过一次之后的状态，对端 MAC 已经被写入缓存。

Interface: 192.168.1.22 --- 0x2 Internet Address Physical Address Type 192.168.1.21 00-0c-29-99-cb-04 dynamic

Type 列里的 dynamic 是判断映射来源的关键字段。它表示这条条目是主机通过网络中的 ARP 应答动态学到的，和人为指定的 static 条目在刷新策略上完全不同。常见做法是在需要固定映射的场景用 arp -s 手工添加，但实验环境里最好保持 dynamic，否则改完 IP 后缓存不会自动跟随，反而容易被旧映射误导。

在我反复做这类实验的经验里，很多人第一步就会在这里翻车：ping 通了，但 arp -a 看不到目标条目，就以为网络配置有问题。实际上 Windows 主机的 ARP 缓存有自己的老化机制，常用条目如果没有持续流量刷新，过几分钟就会过期消失。命令行里执行 arp -d 能把全部 dynamic 缓存清空，让主机回到实验要求的空缓存初始状态——这是整份报告里最实用的一条命令，后面所有复现都建立在这一步上。

2.2 请求与应答的六元组对比：广播与单播的字段差异

实验报告第 3 题把 ARP 请求报文和应答报文的字段逐项填了一张表，这六项就是 ARP 报文的核心载荷。我看着这份对比最直观的感受是：请求报文有两个识别特征，应答报文也恰好有两个对应特征，四个特征一抓一个准。

请求报文的链路层 Destination 是广播地址，Target MAC 全零，意思是“我不知道谁是 192.168.1.21，你们谁是这个 IP 就把 MAC 报上来”；应答报文则完全反过来，Destination 换成请求者的单播 MAC，Target MAC 填上自己的真实值，完成一对一回复。判断请求还是应答，除了看 Opcode 之外，最快的办法就是看链路层目标是不是 ff:ff:ff:ff:ff:ff，广播目标只出现在请求里。

报告 2.6.1 步骤 6 的统计也很直接：截获的报文里只有 2 个 ARP 报文，其余 8 个是 ICMP。这个比例说明 ARP 只负责“问一次”，拿到映射后后续报文全部直接走单播，不会再重复广播。Opcode 字段两个取值分别表达 request（1）和 reply（2），Wireshark 里过滤时应写成 arp.opcode == 1 或 arp.opcode == 2，比全量 arp 过滤更能定位问题。

2.3 三步命令复现 ARP 填充流程

要复现报告里的完整流程，命令顺序必须固定：先清缓存、再开抓包、最后发流量。顺序反了就会什么都抓不到，这是我在多个环境里反复验证过的血泪经验。

:: 在 Windows 虚拟机 A 上以管理员身份执行 arp -d ping 192.168.1.21 -n 4 arp -a

第一句 arp -d 清空缓存，让主机回到空缓存状态；第二句 ping 触发一次完整的 ARP 解析和四次 Echo 交互；第三句 arp -a 查看缓存是否被写入。如果抓包工具开着，会在报文列表里依次看到：一条 ARP 广播请求、一条 ARP 单播应答、四个 ICMP Echo 请求、四个 ICMP Echo 应答。

这里有两个参数细节值得注意。ping 的 -n 4 指定发送 4 个 Echo 请求，和报告里统计到的 8 个 ICMP 报文（4 请求 + 4 应答）正好对上；如果默认只发 4 个，Wireshark 里看到的就是 2 个 ARP 加 8 个 ICMP，这和实验记录完全一致。arp -d 不带参数清全部缓存，带具体 IP 可以只清某一条。另外在地址栏输入 cmd 时务必用管理员身份运行，否则 arp -d 会提示“请求的操作需要提升”，白执行一次。

3. 跨网段 ARP 与默认网关：解析目标从对端主机变成网关 IP

3.1 同网段和跨网段的三处决定性字段差异

实验 2.6.2 把场景改成了跨网段：PC A 的默认网关换成 192.168.1.10，PC B 的默认网关换成 192.168.2.10。第二次抓包的结果拿出来和第一次对比，ARP 报文的结构出现了三个关键差异，报告第 5 题问的就是这个：请求报文的目标 IP 是谁、应答报文的源 MAC 是谁、应答报文的源 IP 是谁。

这三处差异背后的逻辑只有一句话：主机只对自己二层可达的设备发 ARP。跨网段的对端不在自己的局域网广播域里，数据帧必须先交给网关，由网关在三层转发。所以 ARP 请求落在谁头上，谁就是二层下一跳。跨网段 ping 时，请求的目标 IP 是网关地址，应答的源 MAC 是网关接口的 MAC，后续 ICMP 报文的目标 MAC 也一律是网关——三层目标是对端主机 IP，二层目标却是网关 MAC，这两层目标不一致正是网络层和链路层各自职责的体现。

报告里还有一个容易被忽略的细节：跨网段应答报文里的 Sender IP 是 192.168.1.10，不是对端主机。这进一步说明网关在代答 ARP，它用自己的 MAC 和 IP 去回应请求者，而不是把对端主机的信息转发回去。整个过程中 PC A 根本不知道 PC B 的 MAC 地址，也永远不需要知道。

3.2 不设默认网关的后果：二层广播域外的数据帧直接丢

报告第 4 题问了一个反向问题：如果不设置默认网关会有什么后果？答案写在实验记录里：无法访问不同网段的主机。这个结论听起来像废话，但实际报文层面发生的事情值得展开。

PC A 要向 192.168.2.10 发包，首先查自己的路由表，发现目标不在直连网段，也没有默认路由，于是返回“无路由”错误。此时根本不会发 ARP，因为系统在 IP 层就判定目标不可达。这与设置了网关但网关没回来的情况是两回事：后者会发出 ARP 请求但无人应答，表现在现象上是 ping 超时；前者则是 ping 直接报 “Destination host unreachable”，而且 Wireshark 里一个报文都抓不到。

我在自建环境排障时，判断这两种现象差别是快速定位问题的关键。如果抓包全是零流量，先怀疑主机路由配置；如果能抓到 ARP 请求但没人应答，再怀疑链路和网关状态。报告里“如果不设置默认网关则无法访问不同网段主机”这个答案，落到排查动作上就应该先看 route print 输出里有没有默认路由 0.0.0.0/0。

3.3 在模拟器上复现跨网段场景的配置要点

实验环境里的 S1 是一台三层交换机，E0/1 端口接 PC A 所在网段。要在自己的环境复现同样效果，GNS3 或 eNSP 里至少需要一台三层设备充当网关，配置逻辑如下：

# S1 上配置两个网关接口（以 Cisco IOS 为例） interface GigabitEthernet0/1 no switchport ip address 192.168.1.10 255.255.255.0 no shutdown interface GigabitEthernet0/2 no switchport ip address 192.168.2.10 255.255.255.0 no shutdown ip routing

PC A 和 PC B 分别配置 IP 地址，默认网关指向 S1 的对应接口。这里最容易错的一个点是：如果 S1 运行在二层交换模式，ip routing 没开，两个网段之间永远不通，即使所有 IP 都配对了。另一个常见做法是直接用路由器串接两个网段，但实验报告的报文结构里明确写了“S1 E0/1”，三层交换机的端口形态更能还原这份数据的产出场景。

配置完成后从 PC A ping PC B，再到 PC A 上抓包，应该能看到和报告 2.6.2 一模一样的现象：ARP 请求的目标 IP 是 192.168.1.10，应答的源 MAC 是 3c:e5 开头的网关 MAC。如果在模拟器里抓到的是对端主机的 MAC，说明 PC A 的默认网关没生效，数据帧走了直连路径。

4. ICMP 报文全家桶：Type 与 Code 字段的实测对照

4.1 Echo 请求与应答：Type 8 和 Type 0 的一一对应

报告 3.6.1 步骤 2 截获了 8 个 ICMP 报文，第 1、3、5、7 个是 Echo request，Type 字段值为 8；第 2、4、6、8 个是 Echo reply，Type 字段值为 0。这 8 个报文的 Code 字段全部是 0。对应关系由网络层的 Source 和 Destination 字段保证——这是报告给出的答案，也是最容易在 Wireshark 里验证的一点。

# Wireshark 显示过滤器 icmp.type == 8 # 只看 Echo request icmp.type == 0 # 只看 Echo reply ip.addr == 192.168.1.21 # 锁定目标主机相关报文

从报文数量可以倒推 ping 的默认行为：4 个请求对应 4 个应答。每一个 Echo request 里的 Identifier 和 Sequence Number 与对应的 Echo reply 完全一致，这是应用层匹配请求和应答的另一重保障。报告中特意强调网络层的 Source 和 Destination 保证一一对应，实际理解时把 IP 层和 ICMP 层两层都对照一遍更稳妥：IP 层告诉你报文从哪来、到哪去，ICMP 层的 Identifier 和 Sequence 告诉你它是第几个请求、属于哪个会话。

4.2 地址掩码与时间戳：两个低频但必考的查询报文字段

报告第 7、8 题分别记录了地址掩码请求/应答和时间戳请求/应答的完整字段。这两类报文在实际业务流量里非常少见，Windows 自带的 ping 命令也不支持发送它们，实验里是借助 pingtest 程序构造的。地址掩码报文用于主机向网关询问子网掩码，时间戳报文则用于测量往返延迟。

图中出现了一个很关键的现象：同样的 Identifier 字段，Wireshark 同时用 BE（大端）和 LE（小端）两种方式解析，BE 显示 2560（0x0a00），LE 显示 10（0x000a）。这说明发送端按大端字节序填充，接收端解析时按小端读则得到 10。报告里没有展开讲字节序，但排查真实网络问题时遇到过不少报文解析不一致的案例，都是发送端和接收端的字节序假设不一致导致的。看到 BE 和 LE 两个值同时显示时，以 BE 为准是 Wireshark 的默认逻辑。

时间戳报文的 Type 13/14，Originate timestamp 在请求和应答里都是 0，Receive timestamp 和 Transmit timestamp 在应答里是 14 小时 23 分 57.871 秒。这三个字段分别表示：发送方发出报文的时间、接收方收到报文的时间、接收方回复报文的时间。应答报文里 Originate 保持 0 说明中间这台主机没有实现完整的时间戳回显，这在虚拟化环境里很常见，因为虚拟机时钟同步策略会干扰子秒级时间字段。

4.3 差错报文：Destination Unreachable 和 TTL 超时的封装结构

实验 3.6.2 用 10.1.2.10 到 10.1.4.10 的 ping 构造了终点不可达场景，截获的 ICMP 报文 Type 为 3（Destination unreachable），Code 为 0（网络不可达）。报告指出一个关键机制：这个差错报文的 ICMP 部分至少分两层，外层是差错报文自身，内层封装了触发差错的原始 Echo 请求的 IP 头和 ICMP 头。

内层封装的作用是让源主机知道“哪个请求出了问题”。因为 ICMP 差错报文不会单独携带完整的原始数据，只在载荷里回带原始报文的 IP 头和前 8 字节负载，源主机据此匹配到具体是哪个 Echo 请求触发的差错。这解释了为什么报告里专门强调“封装的源 Echo 请求报文的 IP 层和 ICMP 层”——没有内层封装，源主机只能看到差错，不知道差错对应哪个会话。

同一次实验还对比了两种不同的目标：10.1.3.20 在 S1 一个端口子网内，路由器能转发出报文；10.1.4.10 不在路由表内，路由器直接回 Destination unreachable。这个对比说明差错报文是路由器在丢弃报文时向源端反馈的机制，而“能转发”不等于“能到达”，路由器只对自己的路由表负责。

5. 实验踩坑自查：ARP 缓存抓包漏报的五个真实原因

5.1 抓不到 ARP 报文，因为缓存里残留了 dynamic 条目

现象：Wireshark 开着，ping 也通了，但过滤器里一个 ARP 报文都没有，只有成对的 Echo 请求和应答。

原因：目标主机的 MAC 地址已经在 ARP 缓存里，主机发 ping 前直接查缓存拿到映射，不再发广播请求。Windows 的 dynamic 条目通常保留几分钟，只要在这段时间内再次访问同一目标，缓存就不会被清除。

解决：抓包前先执行 arp -d 清空全部缓存，确认 arp -a 输出是 “No ARP Entries Found” 或空表，再启动抓包工具。要注意 arp -d 需要管理员权限，普通终端会执行失败但不报错，检查方法就是清完后再执行一次 arp -a 看是否为空。

5.2 跨网段抓包看不到对端 MAC，看到的是网关 MAC

现象：按 2.6.2 组网后抓包，ARP 应答报文的 Sender MAC 不是对端主机地址，而是网关接口地址，初看以为抓错包了。

原因：跨网段通信时，PC A 根本不需要知道 PC B 的 MAC。数据帧的二层目标是网关，网关在三层把 IP 报文解包后再重新封装转发。ARP 只解决二层目标，所以解析对象是网关而不是对端主机。

解决：接受这个事实。判断标准是 ARP 请求的 Target IP 字段：同网段填对端主机 IP，跨网段填默认网关 IP。如果跨网段场景里看到 Target IP 是对端主机，反而是配置出了问题，多半是默认网关没生效。

5.3 过滤条件写错，报文在混合流量里被淹没

现象：Wireshark 里全是 TCP 重传、DNS 查询之类的噪声，找不到 ICMP 报文，以为实验失败。

原因：虚拟机的网卡上跑着大量管理流量，而实验只关心 ARP 和 ICMP。直接翻全量报文就像在流水账里找一页，尤其当 Wireshark 的默认排序不是按时间顺序时。

解决：抓包期间先只过滤需要的内容，用显示过滤器把噪声压到最低。备用过滤器写法是 arp || icmp，只看两类协议；如果还在跑 tracert，加上 icmp.type == 11 只关注超时报文。过滤条件写好后，再回到 ping 命令重新触发一次流量，比在历史报文里翻找靠谱得多。

5.4 tracert 中途断跳，中间路由器不回应 TTL 超时

现象：tracert 只显示第一跳或第二跳就停住，后面的路径全变成星号，以为网络链路真的断了。

原因：部分路由器的安全策略会禁用 ICMP 回显或 TTL 超时响应，报文到达该设备后被静默丢弃，源端收不到任何反馈。这不等于链路不可达，目标可能依然能收到后续 TTL 更大的探测报文。

解决：先把 tracert 的等待时间参数加大，然后用 ping 直接测试目标可达性作为对照。如果 ping 目标能通而 tracert 中间有星号，基本可以判断是中间设备策略导致的。抓包验证时注意：只要源端还在继续发送 TTL 递增的 Echo 请求，就说明 tracert 进程没有放弃，星号只是收不到回执。

5.5 地址掩码请求发出去没有应答，协议被系统安全策略拦掉了

现象：pingtest 程序发出 Type 17 地址掩码请求后，Wireshark 里只有请求没有应答，等半天也没有 Type 18 报文。

原因：Windows、Linux 的新版本内核默认不响应地址掩码请求，这类协议被认为具有信息泄露风险，大部分主机和路由器固件默认关闭。实验报告里能抓到应答，是因为实验环境使用了较老的操作系统镜像或模拟器版本。

解决：不要在现代操作系统上纠结这类报文，直接换用 GNS3 里的旧镜像或 eNSP 模拟环境复现。抓包验证的重点放在报文格式的解析上，请求和应答的 Type/Code/Identifier/Sequence 字段完全对称，理解这个对称关系比跑通一次更重要。

6. 把实验报告当排错手册：BE 字节序与 Type 速查的两种用法

这份报告读到最后，最有复用价值的其实是两张表：一张是地址掩码和时间戳报文里的 BE/LE 字段对照，一张是 ICMP 各类报文的 Type/Code 速查。我在实际跟踪网络问题时，通常会把这两个维度组合成一套快速验证的方法。

先说 BE/LE 字段。Wireshark 对同一个 Identifier 同时显示 BE 和 LE 两个值，这在报告的时间戳和地址掩码表格里都出现过。例如 BE 2560（0x0a00）和 LE 10（0x000a），对应关系就是 0x0a00 按小端读出来等于 0x000a 即十进制 10。遇到可疑报文时，我一般会先对比 BE 显示的值和发送端日志里的十六进制原始内容，确认发送端按什么字节序填充的，再决定以哪个视图为准。排查两边系统字节序不一是很常见的问题，例如嵌入式设备和 x86 主机互发报文就经常在这里错位。

第二张表是 ICMP Type 速查。实验覆盖了两类询问报文和两类差错报文，测试和排障光靠这四组还不够，但可以用同样的方法扩展：遇到陌生报文先记 Type，再查 Code，最后看内层封装。例如 Type 3 的 Code 从 0 到 15 分别表示网络不可达、主机不可达、协议不可达、端口不可达等，报告只覆盖了 Code 0 这个场景，但排查思路完全一样：外层 Type 说明报文类别，内层原始负载说明是哪个请求触发的。

把这份实验报告作为自检清单来用时，我建议每个人照着 2.3 小节的命令序列完整跑三遍：第一遍只看 ARP 请求和应答，第二遍加看 Echo 请求的 Type 字段，第三遍用 tracert 构造 TTL 超时。每一遍都在 Wireshark 里用固定的显示过滤器，例如 arp.opcode、icmp.type，而不是凭肉眼在报文列表里找。三遍跑完，网络层这组协议的字段对应关系基本就刻在脑子里了。从那以后我每次抓网络层实验前都强制走一遍清缓存、过滤、逐层展开的流程，再也没被空报文列表坑过。希望这份实验数据也能帮你把 ARP 和 ICMP 的细节彻底理顺。

本文还有配套的精品资源，点击获取