计算机网络实验报告指南：Wireshark抓包与协议分析实战

“实验报告”这三个字，对我来说曾经意味着通宵、掉头发、以及一叠最后根本没人看的打印纸。直到后来我自己带过几次环境、帮人改过几版报告，才想明白一件事：实验报告不是写给老师交差的，而是写给三天后的自己看的。 你当时敲下的每条命令、记下的每个异常现象、画下的每张拓扑，都是一个“现场还原记录”。这篇东西，就是我把计算机网络课里那些经典实验从头到尾重新撸了一遍之后，整理出的一份可以直接照着做、照着写、照着交的完整版。

不管你用的是 Packet Tracer、GNS3 还是实机+Wireshark，实验的底层逻辑都是共通的。我会把每个实验的拓扑怎么搭、设备怎么配、命令怎么敲、数据怎么看、报告怎么写全部拆开，最后再单独拿出一章讲我踩过的坑。内容比较长，建议先收藏再慢慢看，适合正在做课程设计、备战期末实验考核、或者准备面试想临时补一补网络实操的人。

1. 实验环境准备：先把“工地”搭好，再谈干活

很多人的实验报告写得稀烂，根源不是不会操作，而是环境没搭明白就急着动手，结果抓到的包全是噪音，配置了半天的设备根本不通。这一节先把工具选型和网络规划讲清楚。

1.1 模拟器怎么选：Packet Tracer、GNS3 还是真机

• Cisco Packet Tracer：思科官方出的学习模拟器，胜在零成本、上手快、拓扑拖拽就行，功能覆盖 CCNA 级别的全部实验需求。缺点是模拟精度有限，部分协议细节（比如 STP 收敛时的真实行为、OSPF 的某些计时器行为）和真机有差异。
• GNS3：底层跑的是真实 IOS 镜像或 VIRL 镜像，协议行为更接近真机，适合做中大型企业网综合实验、路由协议反复验证。但配置门槛高，需要自己准备 IOS 镜像，资源开销也不小。
• EVE-NG：更偏向专业网络工程师，web 界面、多厂商设备支持，主打的是“虚拟化实验机房”。学生党一般用不到这个。
• 真机 + Wireshark：如果你手头有闲置路由器/交换机（哪怕是十几块钱的交换机），配合一台装了 Wireshark 的电脑，做数据链路层和网络层的观察实验是最直观的。

我的建议是：课程实验绝大多数场景用 Packet Tracer 就够，尤其涉及拓扑搭建、VLAN 划分、静态路由、DHCP、ACL 这些纯配置型题目。但凡是需要“看包”的实验，比如 TCP 三次握手、ARP 请求、IP 分片，最好用真机或 GNS3 + Wireshark，因为 Packet Tracer 的模拟模式虽然能看包，但没法做深度的报文逐字节分析。

1.2 拓扑规划：先把 IP 地址表填好

不管做哪个实验，第一件事永远是画拓扑 + 列地址规划表。别一上来就开设备，先想清楚：

• 网络里有哪些网段？每个网段用哪个子网掩码？
• 路由器的接口 IP 分别是什么？
• PC 的网关是谁？
• 哪台设备做 DHCP Server？地址池范围多大？

我见过太多人配完静态路由发现 ping 不通，最后排查了一个小时发现是 PC 的网关填错了。这种低级错误在报告里一旦出现，基本就告别高分了。

1.3 Wireshark 的基本姿势

Wireshark 是贯穿几乎所有网络实验的“放大镜”。但新手很容易犯一个错：开了抓包就懵了，屏幕上每秒几十个包，根本不知道看哪个。

几个小技巧先记住：

• 抓包前先想清楚“我要观察什么流量”，然后用 显示过滤器 把无关流量过滤掉。比如只看 HTTP：http；只看 TCP 端口 80：tcp.port == 80；只看某个主机的流量：ip.addr == 192.168.1.10。
• 抓包过程中不要乱点网页、不要开一堆后台应用，否则抓回来的包 80% 是噪声。
• 抓到包后先看基本信息列（No.、Time、Source、Destination、Protocol、Length、Info），确认报文种类和流向，再双击查看详细信息。

如果你连过滤表达式都不太熟，就用最笨的办法：跑实验前把其他网络应用全关掉，只保留实验流量。这样即使不过滤也能一眼找到目标。

2. 数据链路层观察实验：ARP、MAC 地址表与交换机转发逻辑

这组实验是所有二层协议的基础。虽然看起来简单，但很多人做完了只留下几张截图，完全没搞明白交换机到底干了些啥。这里我给出一个完整的实验设计，以及报告里应该怎么写分析。

2.1 实验拓扑与地址规划

我用的是最简单但也最能说明问题的结构：两台 PC 接在同一台交换机上，PC1 的地址是 192.168.1.10/24，PC2 是 192.168.1.20/24。交换机不用做任何配置，默认就是透明转发。

实验流程分三步：

1. 在两台 PC 上分别打开 Wireshark，过滤条件写 arp or icmp。
2. 在 PC1 上 ping PC2。
3. 停止抓包，观察 ARP 请求、ARP 应答和 ICMP 回显。

2.2 关键观察点：ARP 请求是广播，应答是单播

你会发现抓到的 ARP 包很有规律：第一个包是 PC1 发出去的 ARP 广播请求，内容大致是“谁是 192.168.1.20？告诉 192.168.1.10”。目标 MAC 是全 F（FF:FF:FF:FF:FF:FF）。接着 PC2 会回一个 ARP 单播应答，内容就是“192.168.1.20 的 MAC 是 xx：xx：xx：xx：xx：xx”。

这个现象背后的逻辑值得在实验报告里详细论证：

• 为什么请求要广播？ 因为设备地址解析时不知道目标 IP 对应的 MAC 地址，只能先在全广播域内喊一声，让目标自己出来应答。
• 为什么应答要单播？ 因为广播请求里已经包含了 PC1 的 MAC 地址，PC2 可以直接把应答发回给 PC1，没必要再广播一次。
• 广播域是什么？ 交换机的所有端口默认处于同一个广播域，所以广播能到达 PC2。如果划分了 VLAN，广播就不会跨 VLAN 传播。

2.3 交换机 MAC 地址表的自学习过程

这个实验如果想做得深入一点，可以在交换机上敲 show mac address-table 来看 MAC 表的变化：

• 在 PC1 ping PC2 之前，先查看交换机 MAC 表，大概率是空的或只有零星条目。
• 执行 ping 之后，再查看一次，你会发现此时已经学习到了 PC1 和 PC2 的 MAC 地址，对应的端口也标出来了。
• 实验做完后如果交换机长时间没有收到对应端口的流量，MAC 条目会老化清除。这个老化时间在思科交换机上默认是 300 秒，可以在实验报告里写清楚。

为什么交换机能“自学”？ 因为交换机在收到数据帧时，会记录“源 MAC 从哪个端口进来”这个信息，存进 MAC 地址表。以后当它要转发目标 MAC 为这个地址的帧时，就知道该从哪个端口发出去了，不用盲目洪泛。这个“学习—转发—老化”的闭环，是整个二层交换的基石。报告里如果能把这条逻辑理清楚，比写上十页命令都管用。

2.4 报告里怎么呈现

不要只贴“PC1 ping 通了 PC2”这种结论。建议按这个结构写：

1. 列出从 PC1 端抓到的 ARP 请求报文的关键字段：源 MAC、目标 MAC、操作类型（1 表示请求）、发送端 IP、目标 IP。
2. 列出从 PC2 端抓到的 ARP 应答报文的关键字段：源 MAC、目标 MAC、操作类型（2 表示应答）。
3. 展示交换机学习完后的 MAC 地址表，标注端口。
4. 结合广播/单播逻辑，解释为什么 PC1 能拿到 PC2 的 MAC 地址。

如果你做的是 Packet Tracer，可以用“模拟模式” + “事件列表”展示交换机收到帧后的转发动线：洪泛、转发、丢弃。这比单纯抓包更直观，也更适合写进报告。

3. 网络层实验：IP 分片与 ICMP 协议行为观察

IP 分片和 ICMP 是计算机网络理论课里必考、但很多人没真正见过“现场”的知识点。文字描述分片总是很抽象，真抓一次包、看一次分片重组的全过程，记忆会牢固非常多。

3.1 实验设计：故意制造 IP 分片

要观察 IP 分片，得先让一个数据报的尺寸超过路径 MTU。最经典的做法是：

• 准备一台 Linux 主机和一台 Windows 主机（或两台 Linux），同处一个网段。
• 在发送端临时把网卡 MTU 改小，比如从 1500 改成 1000：sudo ifconfig eth0 mtu 1000（注意实际接口名可能不同）。
• 然后从该主机 ping 对方，并指定包大小：ping -s 2000 <目标IP>（Linux 的 -s 指定的是 ICMP 负载大小，加上 ICMP 头部 8 字节、IP 头部 20 字节，总长度会超过 2000）。
• 在接收端抓包，就能看到 ICMP 请求被分成了多个 IP 分片。

如果你手头没有两台机器，用 GNS3 里的虚拟 PC 也可以。但注意 Packet Tracer 对分片细节模拟得很弱，建议用真机或 GNS3。

3.2 抓包结果怎么看

抓到的分片包在 Wireshark 里会显示为多个 IP 数据报，每个分片都带以下关键字段：

• Identification（标识符）：同一原始数据报的所有分片拥有相同的标识符，这是它们“同属一家”的凭证。报告里可以专门把这个字段标出来，证明这些分片确实来自同一个原始报文。
• Flags（标志）：其中 MF（More Fragments）位是 1，表示后面还有分片；最后一个分片的 MF 位为 0。
• Fragment Offset（片偏移）：表示该分片在原数据报中的相对位置，单位是 8 字节。第一个分片的偏移是 0，第二个分片的偏移等字段里的值，换算后正好是第一个分片的数据长度（注意要除以 8，因为片偏移的单位不是字节）。

写报告时，强烈建议画一张表格：

把 3 个分片的数据整理进去，再对照 IP 头部格式图解释一遍。这样老师一眼就能看出来你是真的看懂了“分片不是简单地把数据切成两半，而是要让每个分片都能作为独立 IP 数据报传输”这句话。

3.3 ICMP 的差错报告机制

网络层实验还有一个特别容易忽略的点：ICMP 不只是 ping 和 traceroute 用的回显/应答，它还承担着差错报告的角色。

做分片实验的时候，如果目标地址不可达、TTL 超时、分片重组超时，都会触发 ICMP 差错报文。比如：

• 在三台路由器组成的链路上，当数据报的 TTL 减到 0 时，路由器会向源地址发回一个“TTL exceeded”的 ICMP 报文（type 11）。
• 当你 ping 一个不存在的 IP（比如 192.168.1.99/24 里没有主机），ARP 解析不出来，通常会报“Destination Host Unreachable”。如果跨网段且路由表没有匹配项，会报“Destination Net Unreachable”。

我在报告里会把“ICMP 回显请求/回显应答”和“CGMP 差错报文”分开整理成一个对照表，标注 type、code、触发场景，这个小细节在答辩的时候很加分。

3.4 常见误区

• 误区一：以为分片是发送端主动做好的。实际上，分片可以发生在发送端，也可以发生在中间路由器上——只要数据报尺寸超过了出接口的 MTU，就必须分片。
• 误区二：以为 MTU 越大越好。实际上，超长数据报要么被分片（增加开销），要么被丢弃（如果 DF 禁止分片位置 1）。测试 MTU 大小用 ping 配合 -M do 参数就能探测。
• 误区三：把片偏移的单位搞错。片偏移以 8 字节为单位，抓包看到的 raw value 是比如 185，实际字节偏移就是 185×8=1480，正好是第一个分片的数据长度。

4. 传输层实验：TCP 三次握手、四次挥手与重传机制

传输层实验是面试高频考点，也是期末笔试必考。但笔试考的是概念，实验里你要亲眼看到每一个标志位的变化、每一个序列号的变化，再去对应教科书上的状态转移图。

4.1 怎么抓一次干净的三次握手

用 Wireshark 直接访问一个网站就能抓到大量 TCP 包，但太杂。更干净的做法是：

• 打开 Wireshark，过滤 tcp.port == 80。
• 在终端/命令行里访问一个静态资源服务（比如本地起的 nginx，或者 curl 一个简单的 HTTP 网页）。
• 停止抓包，只看最开始那三个包：SYN、SYN+ACK、ACK。

这三个包的序号变化非常有意思：

1. SYN：客户端发送 SYN，携带一个初始序列号（比如 ISN=1000，注意 Wireshark 默认显示的是相对序列号，如果不勾选“Relative sequence numbers”可以看到真实的随机初始序列号）。
2. SYN+ACK：服务器回复 SYN+ACK，它的 ACK 号是“客户端的 ISN+1”，同时自己也携带一个 ISN（比如 5000）。
3. ACK：客户端再回复 ACK，它的 ACK 号是“服务器的 ISN+1”。

把三个包的序列号和确认号排成一张表，你就能推导出 TCP 状态转移图里的每一步。报告里一定要写“为什么连接建立需要三次而非两次”：因为 TCP 是全双工通信，双方都需要确认对方的收发能力正常。如果只有两次握手，服务器端无法确认客户端的接收能力是否正常；如果四次，则属于浪费（第二次和第三次可以合并成 SYN+ACK 一次带回）。

4.2 四次挥手：别以为一定是“四次”

很多同学考试时背的是“客户端 FIN，服务端 ACK，服务端 FIN，客户端 ACK”，实验里确实经常抓到这样的四次握手。但要注意，中间两步有可能合并，也就是服务端把 ACK 和 FIN 放在一起发，这时候抓包看起来就像三次挥手。

另外，如果有一端程序没有正常关闭连接（比如强制 kill 进程），你可能根本看不到 FIN 包，取而代之的是 RST 包异常重置。这时候 TCP 状态直接跳到 CLOSED，不经过 TIME_WAIT。这个细节在报告里写出来，显得你真的认真观察了报文行为，而不是照抄课本。

4.3 重传机制：看一次超时重传

要观察重传，可以人为制造丢包：

• 用 Linux 的 tc netem 命令在发送端网卡上模拟丢包：sudo tc qdisc add dev eth0 root netem loss 20%。
• 从该主机 curl 下载一个大文件。
• 抓包观察：你会发现相同的序列号出现了两次，第二次出现时 Wireshark 会标记为 TCP Retransmission。

思考题：为什么同一个序列号会被重复发送？ 因为发送端收到确认之前，会把已发送但未确认的数据保存在发送缓冲区里，等待超时计时器到期后重新发送。这个过程体现了 TCP 的“可靠传输”特性：通过序列号、确认号、超时重传、滑动窗口等机制协同保证数据不丢、不乱、不重。报告里如果能结合抓到的“第一个包发出时间”和“重传包发出时间”，粗略估算出超时重传时间 RTO，效果会非常好。

4.4 滑动窗口和流量控制

抓一个持续传输的大文件，观察 Wireshark 展示的窗口大小（Window Size）如何变化。你可能会看到接收方的窗口值在慢慢变小，这是因为接收方的接收缓冲区慢慢被填满、应用层来不及取走数据，于是接收方主动缩小窗口，让发送方降低发送速率。

这就是 TCP 的流量控制。记住一个词：端到端。流量控制解决的是“发送方太快，接收方吃不下”的问题，和网络中间的拥塞控制解决“网络太堵”的问题不是一回事。这个纠结点在期末考和面试里反复出现，我的实验报告里会单独画一个窗口大小随时间变化的折线图（截 Wireshark 的 IO Graph 就行），一目了然。

5. 应用层实验：DNS、HTTP 与 NAT 的综合实战

应用层实验最容易被当成“走流程”，但其实最能从细节里看出水平。很多人 DNS 实验只会看一眼“解析成功了”，HTTP 实验只会说“状态码 200”。我建议你把 DNS 和 HTTP 的抓包放到同一个环境里做，然后把 NAT 的转换过程也串联进来，一口气把 A 记录、递归查询、请求头、状态码、源/目的端口改写全看了。

5.1 DNS 解析过程：从迭代查询到缓存命中

实验环境：一台 PC（Linux），用 nslookup 或 dig 查询一个域名，同时 Wireshark 过滤 dns。

重点观察：

• DNS 报文使用 UDP 端口 53（大多数情况下），传输层头部非常简单，无三次握手、无可靠传输。所以 DNS 查询经常需要在应用层做超时重试，这也是为什么有时你 ping 一个域名第一次会卡一下、第二次就快了——第一次可能超时重发。
• DNS 请求和响应的 Transaction ID 相同，用于匹配请求和应答。
• 响应报文里的 Answer 可能是多个 A 记录（多个 IP），对应 DNS 轮询负载均衡或 CDN 调度。

如果条件允许，多抓几次相同域名的查询，第二次的响应时间明显变短，且 Answer 区会标记为非权威应答（Non-authoritative answer），这就说明命中了本地缓存。

5.2 HTTP 抓包：请求行、首部字段与状态码

在浏览器里访问一个纯静态页面（或者用 curl -v），Wireshark 过滤 http 或 tcp.port == 80，能看到完整的 HTTP 请求和响应：

• 请求行：GET /index.html HTTP/1.1，方法、URI、版本一目了然。
• 请求头：Host、User-Agent、Accept、Connection 等。
• 响应状态行：HTTP/1.1 200 OK，或 301/302/403/404/500。
• 响应头：Content-Type、Content-Length、Cache-Control 等。

我建议在报告里专门分析一次 301/302 重定向的会话：浏览器访问 http 版本，服务器返回 301，然后浏览器重新发起 https 请求。把这两段请求串联起来，可以完整演示 HTTP 到 HTTPS 的迁移逻辑，同时能引出 Referer、Location 等字段的作用。

5.3 NAT 转换：内部地址如何“偷渡”到公网

如果实验环境支持模拟外部网络（比如 GNS3 的 Cloud 节点，或者 Packet Tracer 里的多条路由链路），可以做这样一个拓扑：

• 内网 PC1：192.168.1.10/24
• 路由器 R1：内网口 192.168.1.1/24，外网口 202.113.15.1/30（或其它公网测试地址）
• 外网服务器：202.113.15.2/30 或 8.8.8.8 不可达时改用虚拟机里的另一台

PC1 上 curl 外网服务器的 HTTP 服务，同时 R1 外网口抓包。你会看到：

• 内网抓到的报文里，源 IP 是 192.168.1.10，源端口可能是 40000。
• 路由器外网口抓到的报文里，源 IP 变成了 202.113.15.1，源端口变成一个随机的新端口（如 50000），目标 IP 和端口不变。
• 外网服务器的响应报文回到路由器时，目标 IP 是 202.113.15.1，目标端口是 50000；路由器根据 NAT 映射表，将其改写为目标 IP 192.168.1.10、目标端口 40000，再转发给 PC1。

为什么需要 NAT？ 核心原因是 IPv4 公网地址稀缺。但这带来一个副产品：内网主机对外部网络“隐藏”了自己的真实 IP，所以常被误认为 NAT 是安全功能。在报告里可以顺便把这个误解澄清一下，能体现出你学习中的批判性思考。

NAT 实验最容易出错的地方是在路由器上忘了启用 ip nat inside 和 ip nat outside 的接口标记，或者忘了写 access-list 来定义哪些内网地址允许被转换。写报告时记得把你的 ACL 和 NAT 映射表截图，并逐个解释每一条命令的作用。

5.4 从应用层回头看下层——串联整条协议栈

做应用层实验时，很多人喜欢只过滤应用层协议，但我建议你关掉过滤，完整地看一次“从访问 URL 到页面显示”的全过程：

1. DNS 查询（UDP 53）→ 解析出目标 IP。
2. TCP 三次握手（SYN、SYN+ACK、ACK）→ 建立连接。
3. 发送 HTTP GET 请求 → 服务器响应 HTTP 200。
4. TCP 四次挥手或连接复用 → 关闭连接。

把这四个阶段按时间线列出来，就是一次最完整的“用户输入网址后发生了什么”的实战演示。这比背 100 遍 OSI 七层模型都记得牢。

6. 实验中最容易踩的坑：排错链路全复盘

这一节是我实际带实验、帮几十个同学排查过问题之后，总结出来的高频翻车点。每一个都对应真实案例，不是凭空杜撰。如果你实验做不通，按这个顺序查下去，大概率能在五分钟内定位。

6.1 坑一：网关都没配，还怪路由不通

排查链路的第一步永远是：从源主机开始一层一层往下查。

• 先看本机 IP、掩码、网关配置对不对：Windows 用 ipconfig，Linux 用 ip addr、ip route。
• ping 同网段的其他主机，确认二层没问题。
• 再 ping 网关，确认三层出口通不通。
• 再 ping 跨网段地址，确认路由生效。
• 最后 ping 域名，确认 DNS 解析正常。

很多同学一上来就 ping 一个跨网段 IP，ping 不通就以为是路由配置有误，花半小时改路由表，最后发现 PC 的网关压根没写。基础检查永远比高深配置重要。

6.2 坑二：模拟器的“接口状态”没注意

Packet Tracer/GNS3 里经常出现一种情况：你明明配好了接口 IP，但接口是 down 的。原因可能是：

• 没有 no shutdown：思科 IOS 的路由器接口默认是 shutdown 状态，必须手动打开。
• 两端接口的协商模式不匹配：比如一边是 access、一边是 trunk，或者两边封装不一致。
• 光口/串口之间没有按 DCE/DTE 关系设置时钟频率（老考试题里常见，现在已经少见了）。

排查时用 show ip interface brief 看接口状态，凡是 down 或 administratively down 的一大串，逐个处理。这个命令应该成为你实验时的肌肉记忆。

6.3 坑三：Windows 防火墙拦截了 icmp，但你以为网络不通

这个坑在真机实验里尤其坑人。Windows 默认防火墙常常拦截 icmp 请求，导致你 ping 不到对面的 Windows 主机，但 HTTP、SSH 等流量其实是通的。

这时候不要一上来就怀疑路由器和交换机配置，先确认对方的防火墙设置。临时测试最快的方法是：在 Windows 防火墙的高级设置里，启用“文件和打印机共享（回显请求 - ICMPv4-In）”规则，或者直接关掉防火墙（测试完记得开回来）。

6.4 坑四：MTU 不一致，导致“能 ping 通但开不了网页”

这个坑很隐蔽。两台主机的 MTU 不一致，小包能通（比如 ping -l 100），大包不通（比如 ping -l 1500 或访问网页时因为下载大数据而被丢）。

排查方法：用 ping 渐进式测试包大小，找出“临界值”。如果包大于某个字节就不通，基本可以断定是 MTU 问题。检查链路两端设备的 MTU、以及交换机端口的 MTU 设置，统一成 1500 或 1492（PPPoE 环境是 1492）。

6.5 坑五：Wireshark 抓包抓了半天，发现抓的是自己电脑到虚拟机的流量

做 NAT、DNS 实验时，如果把 Wireshark 的抓包接口选错了（比如选了物理网卡，但实验流量其实是走虚拟网卡的），抓到的包全是不相关的东西。正确做法是：先用命令确认流量走哪个接口，再决定在哪个接口抓包。

排查链路里最容易被忽略的还有 DNS 缓存。你在实验里改了域名的解析记录，但客户端还是命中旧缓存，导致你看不到新响应。清理缓存：Windows 用 ipconfig /flushdns，Linux 用 sudo systemd-resolve --flush-caches（不同发行版命令略有差异）。

7. 从“能交差”到“高分报告”：内容组织的实战技巧

实验做完了，抓包数据也齐全了，最后一步就是把这些素材组织成一份像样的报告。我帮人改过几百份报告，最常见的毛病不是缺数据，而是逻辑混乱、数据堆砌、没有分析。

7.1 报告的骨架：按“目标—方法—数据—分析—结论”五段式

每做一个实验子项，都按这个结构组织：

1. 实验目标：用一两句话说清楚这个实验要验证什么原理、观察什么现象。
2. 实验方法：拓扑图 + 设备配置 + 关键命令，做到“别人拿着你的报告能复现实验”的程度。
3. 实验数据：抓包截图、Wireshark 关键字段表、命令行输出。截图要裁剪好、放大到字能看清，关键字段要用红框或箭头标出来。
4. 分析：把数据和原理对应起来，解释“为什么会出现这样的现象”。这是报告分量的核心。
5. 结论：总结验证了什么，有没有出现与理论不符的异常，以及你对异常的解释。

7.2 数据呈现的技巧：善用表格和箭头

不要大段贴几十个包的截图。要提取关键信息，做成表格。比如展示 TCP 三次握手：

再比如展示 IP 分片：

这种表格一出来，老师就知道你是真的理解报文结构了。比贴十张截图管用得多。

7.3 不要只写“成功”，也要写“失败”

很多学生为了好看，把调试过程中遇到的所有错误都藏起来，只汇报“一次成功”。这其实是浪费了最值钱的素材。

有一次我发现一个学生的静态路由实验一直不通，排查到最后发现是路由器的下一跳地址写错了。他在报告里把这段“出错—排查—修正”的过程写了出来，还附带对照了错误的 show ip route 和修正后的 show ip route 输出。这份报告拿了全班最高分。

实验报告的价值在于体现“探索和修正”的过程，而不是表演“完美”。

7.4 让报告能和面试八股文联系起来

如果你是在准备校招或考研复试，写实验报告时主动把实验现象和经典的面试八股文联系起来，是一个极好的学习方式。例如：

• 做完 TCP 三次握手实验，就去把“为什么要三次握手”这个八股题背一遍，并用自己的实验数据重新回答一遍。
• 做完 DNS 实验，就去把“输入 URL 到页面展示发生了什么”这个经典面试题按抓包时间线梳理一遍。
• 做完 NAT 实验，就去把“从内网访问外网，源 IP 和源端口如何变化”描述一遍，这道题很多面经里都有。

实验报告写完后，不要直接扔进文件夹。隔三天再打开看一遍，如果你还能靠报告里的截图和数据把实验完整复现出来，说明这份报告是合格的。如果连自己都看不懂，那就得重新整理。

7.5 最后：一定要有的“实验心得”段落

很多报告的实验心得写得千篇一律：“通过本次实验，我加深了对计算机网络的理解。”这句话等于没写。

好的实验心得应该具体到：

• 哪一步操作让你对某个概念有了新的认识？比如“以前我以为交换机收到一个帧会向所有端口转发，但看到 MAC 地址表条目之后才真正明白，交换机的转发是有目的性的。”
• 排错过程中哪一个现象让你卡住了，最后是怎么解决的？
• 如果重做实验，你会调整哪些设计？

这里不需要写大话套话，就写真实的思考过程。哪怕只是一段，也足够打动人。

8. 进阶玩法：把实验报告升级成“小项目”

如果你学有余力，或者想把这份报告变成简历上的一个项目经历，我建议你在基础实验之外加一两个进阶内容。这也是我见过最有性价比的加分之一，投入的精力不算大，但整体档次会高很多。

一个值得尝试的方向是跨 VLAN 通信 + DHCP 中继的综合实验：两台主机在不同 VLAN，由一个三层交换机完成 Vlanif 间路由；同时为两个 VLAN 的主机动态分配 IP 地址。把 DHCP 交互的四步（Discover/Offer/Request/Acknowledge）抓包、把 VLAN Tag 的变化过程抓包，最后再用一个 ACL 限制特定 VLAN 之间的访问。这样一个实验，几乎把二层、三层、应用层、安全四个层面的知识点全串起来了。

另一个方向是在 PT 里模拟一个包含冗余链路的拓扑，观察 STP 从启动到收敛的过程。这个实验因为模拟器对计时器的模拟不一定特别真实，但状态变化（Listening → Learning → Forwarding 或 Blocking）是能看到的。写报告时顺便解释 BPDU 的作用、根桥选举原则、端口角色，深度一下就出来了。

这种“组合拳”式的实验，比单独做十个孤立的小实验更能体现真实网络工程中的思维——网络里的问题从来不是单一协议能解决的，永远是多层协议协同、多个设备配合的结果。

最后再分享一个小技巧。每次实验跑完，除了把报告写好，我还习惯把当时的**配置文件（running-config）**导出一份，存成文本，放到报告附录里。这样万一老师答辩时问“你当时交换机上到底配了哪些命令”，你翻一下附录就能流利回答。顺便，自己复习的时候也能快速恢复实验环境，不用从头敲一遍命令。这算是花钱都买不到的好习惯。