计算机网络实验报告怎么写？从抓包到PDF的完整证据链

简介：一份计算机网络实验报告，来自桂林航天工业学院软件工程三班，系统记录了学生在课程设计中的十个实践项目，适合网络工程、软件工程等专业学生用作实验参考与复习资料。报告以实际配置过程为主线，覆盖小型网络组建与常用命令、FTP服务器配置、VLAN划分、静态路由、RIPv2、WWW服务、单区域OSPF、协议数据包结构分析、子网划分及CRC计算等内容，对网络设备操作、属性设置和故障排查方法均有详细说明，并附有大量命令输出与拓扑理解要点。资源为单个PDF文件，体积5.62MB，内容完整、目录清晰，便于按项目顺序阅读或直接检索所需实验模块。目前已有62人学习下载，适合正在学习计算机网络课程、需要对照实验报告查漏补缺或准备课程设计答辩的读者。

1. 一份带时间戳的PDF，为什么值得当成工程来做

看到“计算机网络实验报告(20211004165046).pdf”这个文件名，你可能会先注意到中间的学号，然后是那串像是乱码的时间戳。这其实是很多高校的提交通用格式：学号加提交时刻，坐实“这份报告是某个时间点生成的终稿”。一份合格的计算机网络实验报告，不该是最后一晚从网上拼出来的文档，而应该是“跑”出来的东西：你敲下的命令、抓到的报文、测出的延迟，都留有原始证据。这个标题能解决的问题很具体：帮你建立一套从实验设计、数据记录、结果分析到PDF成稿的完整流程，让每次提交不再靠熬夜和运气。

适合读这篇的人有三类：正在补计算机网络实验结果的在读学生、要给实验课定模板的助教，以及刚转入网络运维、想把故障排查过程存档的工程师。下面我不讲教科书定义，只讲我实际用过、也踩过的做法。

2. 实验报告的结构：目的、环境、过程、结果四段怎么填才不注水

先说明：这一章的“结构”不是学院派八股，而是方便复查的证据链。很多学生把实验报告写成“实验书摘要”，最终被退稿的原因不是没有完成实验，而是写出来的东西没法让别人还原你在电脑前做了什么。我批过几十份入门报告，真正拉开差距的，就是四段里有没有可复查的细节。

2.1 实验目的不是抄课本：一行字说清“你用什么方法验证了什么结论”

把实验目的从指导书里复制过来，是报告看起来“虚”的第一根源。“掌握TCP协议的工作原理”这句话放在哪次实验都对，放在哪次实验都没用。我对自己和同学的要求是，目的必须写成如下句式：用Wireshark抓取一次HTTP请求，从三次握手到数据交互，提取TCP连接建立的时序特征。这个句式里包含工具、场景和验证对象，后面写过程和结果时，每一段都能对着目的找落点。

如果把目的写得更可验证，还可以带上“预期”和“判定标准”。例如“通过ping测试验证同一网段内两主机连通性，预期丢包率为0，平均RTT小于1ms”。老师看到这样的目的，至少知道你事前想过结果长什么样。反观“掌握ping命令的用法”，这条根本不用做实验，在命令行按两次回车就算掌握了。

我常用的模板是“工具+场景+验证对象”。工具指明用什么采集证据；场景指明网络拓扑或访问路径；验证对象指明要观察哪个协议或性能指标。如果你用的是谢希仁《计算机网络》教材，写目的时最好用教材里的术语，例如“面向连接”“状态迁移”“超时重传”，这样后面引用抓包证据时，措辞能和课程要求对上。

2.2 环境记录要具体到版本号：设备、软件、拓扑、地址缺一不可

环境是报告里最容易被省略、却对复现最救命的部分。只写“使用Cisco模拟器”等于没写——Cisco Packet Tracer 8.2.1和GNS3里跑的IOS镜像，命令行为和协议定时器都有细微差异。我在报告里会放一张环境表，把平台、软件、模拟器版本、网段都写清楚：

环境表之外，还要有一张拓扑图。哪怕只是用PowerPoint画三个方块和两条线，也必须把接口号标出来。为什么这么强调接口号？因为配置段里要写interface G0/0/0，如果你的拓扑图上只有“PC-路由器”没有接口，读者就没法验证命令作用在哪条链路上。我在帮人改报告时经常看到拓扑图是网络上找的，配置代码是自己写的，两者完全对不上，这种情况一眼就会被判“疑似编造”。

版本号同样重要。不同的模拟器版本对OSPF、VLAN的默认行为可能有变化，写清楚版本能让别人复现你的实验。如果你用的是真机，还应该写上设备型号和IOS/VRP版本，例如华为AR2220、V200R019C10。

2.3 过程和原始数据：命令输出、抓包文件和带时间戳的记录怎么留

过程部分最常见的注水写法是“使用ping命令测试连通性，结果显示网络通畅”。这句话只给出结论，没给出任何能复查的东西。我要求自己的过程记录至少包含三项：命令本身、输出摘要、输出被保存到的文件路径。这样别人可以在同一环境里重新跑一遍，对比输出。

终端命令建议用日志方式保存。我习惯用一个小脚本把所有测试输出打上时间戳：

#!/bin/bash # 实验记录脚本：保存ping结果并附带时间戳 LOG_DIR="./experiment_logs" mkdir -p "$LOG_DIR" { echo "===== $(date '+%Y-%m-%d %H:%M:%S') =====" echo "--- ping PC2 from PC1, 10 packets ---" ping -c 10 192.168.20.1 } | tee "$LOG_DIR/ping_$(date '+%Y%m%d_%H%M%S').log"

这段脚本的逻辑是：先创建日志目录，然后在一个子shell里同时输出当前时间和ping结果，用tee同时写到屏幕和文件。这样报告里可以用文件名引用证据，比如“见附件ping_20241020_153012.log”。参数说明：-c 10表示发10个ICMP报文；文件名里的%Y%m%d_%H%M%S是年月日时分秒，排序不会乱。如果怀疑网络丢包，可以把-i 1改成-i 0.5，让发包间隔变成0.5秒，但默认1秒已经够用。

抓包实验除了截图，更建议保存一份原始pcapng和tshark导出的文本。截图是给人看的，pcapng是给复查工具看的。报告正文里可以贴关键报文，附件里放原始文件，这样的实验过程别人无法质疑。

2.4 结果和结论：把“数据摆出来”和“讲清楚为什么”分开

实验结果部分不要只贴图，然后用一句“实验成功”收尾。拿TCP握手实验举例，我看到太多人贴一张抓包图，然后写“由图可知，TCP经过三次握手建立连接”。这句话没有利用图里的任何数据，等于白贴。一个能加分的写法，是把图中的关键指标摘出来做成表：

表格做完，结论自然就有了：传输层协议在本机回环下时延极小，若有异常，比如SYN重复发送，则说明有重传，需要进一步分析。这种结论建立在数据之上，不是“成功/失败”的二元判断。

我还想强调一个细节：把实际测量结果和理论值对比时，不要说“误差在允许范围内”。网络实验的“允许范围”不是公差，而是一个机制边界。回环接口RTT接近0毫秒是合理的，你要解释为什么合理，不是因为“误差”。这样写，报告才有工程感。

3. 四个高频实验场景：参数怎么设、数据怎么取、证据怎么留

计算机网络基础课程里，实验基本上绕不开四件事：抓包分析、组网路由、传输层行为、网络排查。这四个场景也是实验报告出错最集中的地方。这一章我按场景拆出“参数怎么设、数据怎么取、证据怎么留”，方便你直接照着做。

3.1 抓包分析：Wireshark过滤器写出能被复查的报文证据

抓包实验的难点是“抓到一堆包却挑不出关键会话”。Wireshark有两套过滤器，经常被混为一谈：捕捉过滤器在抓包前起作用，显示过滤器在抓包后起过滤作用。我的习惯是抓包时尽量不设过滤，宁可多抓一点；等停下后用显示过滤器锁定目标流。这样原始流量完整，后续分析错了还能回头重筛。

比如我要分析一次HTTP请求，先访问目标站点，停止抓包后使用显示过滤器：

tcp.port == 80

这个过滤条件把端口为80的包全筛出来。注意tcp.port既匹配源端口也匹配目的端口，不是只匹配其中一个。如果目标站是HTTPS，端口应该是443，这时tcp.port == 80会一个包都不剩。所以我会先用http这个显示过滤器看看有没有HTTP请求，没有就换成tcp.port == 443。

如果只想看TCP握手，可以加协议字段条件：

tcp.flags.syn == 1 || tcp.flags.ack == 1

参数说明：tcp.flags.syn == 1表示SYN标志位置1的报文，||是逻辑或，tcp.flags.ack == 1匹配ACK标志位。这样能筛出SYN、SYN-ACK、ACK三类包，但也会带上数据包里的ACK，因为普通数据传输时ACK位也是1。如果你只想看建立过程，建议改用tcp.flags.syn == 1把SYN包列出来，再按TCP stream分组。

报告里需要的证据，不能只贴全屏截图。我会在Wireshark里调整显示列为“No. Time Source Destination Protocol Info”，并把时间显示格式改为“Seconds Since Previous Captured Frame”，这样能直观看到两个报文之间的时间差。然后我用tshark把这个会话的关键字段导成文本，避免截图过小看不清：

# 从pcapng中提取TCP握手的时间、序列号和IP tshark -r http_session.pcapng -Y 'tcp.flags.syn==1 || tcp.flags.syn==1&&tcp.flags.ack==1 || tcp.flags.syn==0&&tcp.flags.ack==1&&tcp.len==0' -T fields -e frame.time_relative -e ip.src -e ip.dst -e tcp.seq_raw -e tcp.ack_raw

这条命令的-Y过滤条件比较长，是为了在一次输出里同时覆盖SYN、SYN-ACK、以及三次握手的ACK（通常是一个不带载荷的纯ACK包）。参数含义：-r读取pcapng文件，-Y套用显示过滤器，-T fields表示按字段输出多列，每个-e定义一列。实际使用中，如果你只想快速定位，建议先查出会话的stream编号，再用tcp.stream == n过滤，后面的命令更简单。

3.2 组网实验：静态路由和动态路由的配置里，最容易丢掉的一行

组网实验通常在Cisco Packet Tracer或华为eNSP里做。很多同学的流程是照着指导书敲命令，ping通了就交报告。但报告里如果只写“ping通”，老师没法判断你理解了静态路由。以最简单的双路由器场景为例，静态路由配置如下：

conf t ip route 192.168.20.0 255.255.255.0 192.168.10.254

这段命令的意思是：要到达192.168.20.0/24这个网段，就把报文交给下一跳地址192.168.10.254。参数说明：第一段是目标网络地址，第二段是子网掩码，第三段是下一跳地址。注意掩码这里必须写成点分十进制，不能写/24；下一跳必须是与本设备直连的接口地址。如果写成出接口名G0/0/0，在以太网链路会上查不到下一跳MAC，命令可能会报“%Inconsistent address and mask”或者干脆不通。

配置完成后，记录验证命令的输出：

show ip route show ip interface brief

show ip route里应该能看到一条S 192.168.20.0/24 [1/0] via 192.168.10.254，S代表静态路由，[1/0]是管理距离和度量值。如果这条路由没出现在路由表里，说明配置被覆盖或者接口没起来。我见过很多人配置后忘了no shutdown，接口双down，路由自然不生效。

动态路由实验，比如OSPF，验证命令要换成：

show ip ospf neighbor show ip ospf interface

前者看邻居状态是否为Full，后者看接口在OSPF中的网络类型、hello间隔等。OSPF建立邻居的常见坑是两端的hello-interval不一致，默认是10秒。如果改了其中一边，另一边没改，邻居会卡在Init或ExStart。报告写到这里时，我会把show ip ospf interface的输出摘一段，标注hello时间，证明我检查过。

3.3 TCP/UDP行为分析：从抓包里计算连接建立耗时和RTT

TCP三次握手是计算机网络基础课里的必考八股，但八股背得再熟，实验报告里没有真正的抓包证据也白搭。我在做这类实验时，会先抓一个HTTP连接，然后用量化的方式把连接建立过程写进报告。抓包命令如下：

# 抓取访问example.com的TCP 80端口流量，30秒自动停止 tshark -i eth0 -f "host example.com and tcp port 80" -w http_example.pcapng -a duration:30

参数说明：-i指定网卡，-f是捕捉过滤器，host example.com and tcp port 80限定主机和端口；-w写文件；-a duration:30表示30秒后自动停止。这里要注意，-f是简单捕捉过滤器，语法和显示过滤器不同，不能写tcp.port == 80。

抓到文件后，我会先在Wireshark里确定TCP stream编号。通常选择第一个HTTP会话的stream，然后过滤：

tcp.stream == 0

这样窗口里只显示这一个会话。接下来把三次握手的三个报文复制到报告里，表格列出相对时间、源目IP、TCP序列号和ACK号。序列号的关键是：第二次握手的ACK号等于第一次握手的序列号+1，第三次握手的序列号等于第二次握手的ACK号。报告里如果能写出这个“+1”关系，就能证明你真的看了包，而不是抄图。

计算RTT时，用抓包里的相对时间列，取SYN发出和SYN-ACK到达的时间差。如果时间列单位是秒，0.001278就是约1.3毫秒。这里有一个概念坑：Wireshark的 Time 列默认是“绝对时间”，报告里算时差应该用“相对于第一个帧的时间”或“相对于上一帧的时间”。我习惯改成“Seconds Since Previous Captured Frame”，这样直接能读两次间隔。

3.4 网络排查实验：用ping/traceroute/nslookup组合定位故障

这个场景更贴近真实运维，也是实验报告里最容易被写成流水账的。我推荐的套路是：先立一个假设，再用命令验证，最后把每一步的输入和输出列成“排查日志”。最小命令组如下：

# 1. 查看本机网络配置 ipconfig /all # 2. 测试网关连通性 ping 192.168.10.254 -n 4 # 3. 跟踪到目标的路径 tracert -d 192.168.20.1 # 4. 检查DNS解析 nslookup www.example.com

注意参数差异：Windows的ping用-n 4指定4个请求，Linux用-c 4；tracert的-d表示不做反向解析，能明显提速。这些命令的每一个输出都要留文本。比如ipconfig里看看网关是否配置正确、DHCP是否启用；ping网关通但ping远端不通，说明问题在路由；ping网关不通，问题在物理链路或本机配置；nslookup能解析但ping不通域名，可能是防火墙或路由策略。把这些写进报告，就是一次完整的“故障定位矩阵”。

写完实验报告时，我会把排查过程中的错误信息原样保留，并在结论里说明“这条命令第一次输出了什么，说明什么问题，后来如何修正”。很多同学觉得报告里写失败是减分项，恰恰相反，对老师来说，能写出“为什么失败”比“一次成功”更能反映水平。

4. 从实验数据到PDF：排版、截图、命名与元数据处理

实验数据齐了，最后一步是产出PDF。这一章看着像是“格式”问题，其实最容易翻车。我见过太多人实验做得不错，最后因为PDF里图片压缩、字体乱码、文件名交错被扣分。下面按工具选型、截图处理、命名元数据三个环节说。

4.1 排版工具选型：Word转PDF、Markdown转PDF、LaTeX转PDF的取舍

我评过用三种工具交上来的报告，各有各的坑：

现在的我固定用“Markdown写正文，Pandoc转PDF”。原因很简单：实验报告里大量代码块和表格，Markdown的源码可读、可diff，我可以把报告放进git仓库每次改动都有记录。下面这条命令是我最常用的最小转换：

pandoc experiment.md -o experiment.pdf --pdf-engine=xelatex -V CJKmainfont="Noto Sans CJK SC" -V geometry:margin=2.5cm

参数说明：--pdf-engine=xelatex指定用XeLaTeX引擎，它才能正确处理中文字体；CJKmainfont设置中文主字体为Noto Sans CJK SC；geometry:margin=2.5cm控制页边距。这一步最常见的坑是系统里没有该字体，导致PDF中文全部变成方块。转换前先执行fc-list :lang=zh查看可用中文字体，再替换命令里的字体名。Windows系统如果没有Noto Sans，可以用“Microsoft YaHei”。

如果你已经习惯Word，也有一条建议：导出PDF时，在“选项”里勾选“不压缩图像”，并且不要用“最小文件大小”的发布模式，否则截图会被二次压缩。代码块如果是从终端复制的，Word默认字体不是等宽字体，可以把代码段设为Consolas或Courier New。

4.2 截图的处理：Wireshark窗口怎么截才像样，命令行输出怎么转成文本

报告里最刺眼的往往不是内容，而是整张全屏截图，任务栏、菜单、无关窗口全在里面。我的截图三条原则：只截当前活动窗口；把Wireshark列宽拉到关键信息完整；保存为PNG而不是JPG。对于Wireshark抓包窗口，我会先隐藏左侧的Packet List之外的冗余面板，然后最大化，确保No.、Time、Source、Destination、Protocol、Info六列都可见。如果信息列太长，把它拖到足够宽，必要时分成两行截图。

命令行输出不要用手机拍照。在Linux里直接重定向到文本文件，再在Markdown里用代码块嵌入。Windows PowerShell输出中文时可能出现编码乱码，可以先执行chcp 65001切换到UTF-8代码页，或者用Out-File -Encoding utf8保存。如果日志很长，只粘最后摘要部分。我常用一个小Python脚本，把多个日志文件自动转成Markdown格式：

import glob files = sorted(glob.glob("./logs/*.log")) for f in files: print(f"### {f}\n") with open(f, encoding="utf-8") as fh: lines = fh.readlines() print("```text") print("".join(lines[-30:])) # 只取末尾30行 print("```\n")

这个脚本的逻辑：遍历logs目录下所有.log文件，按文件名排序；对每个文件输出小节标题和末尾30行内容，用text代码块包起来。参数说明：lines[-30:]是Python列表切片，取最后30个元素；为什么取30行？因为ping等命令的头部和输出中间很多重复行，报告里只需要统计摘要和最后几行状态。如果想把筛选后的字段导出成表格，可以继续用tshark的CSV输出，再手动贴进Markdown表格。

截图中的敏感信息处理也值得写。实验环境里的IP、MAC如果不想全文公开，可以在截图上打码，但要注意保留关键部分。Wireshark的Info列里有IP和端口，打码时最好只掩后两段，否则老师没法判断来源。也可以用tshark把IP换成host别名再导出，但那样报告的可复查性会下降，我一般只对真实互联网地址打码，私有网段地址192.168.x.x保留原样。

4.3 文件名与PDF元数据：让“(20211004165046)”这类时间戳从玄学变成规范

标题里的“20211004165046”乍看像乱码，其实是标准时间戳：2021年10月04日16时50分46秒。很多老师喜欢这样的命名，因为提交系统按文件名时间排序，一眼就能看出是不是最终版本。我自己的命名规则是：

课程名称_学号_姓名_实验编号_YYYYMMDD_HHMMSS.pdf

例如计算机网络实验报告_20211004165046_张三_实验2_20241020_1646.pdf。规则里学号姓名是为了归档，实验编号是为了区分周次，时间戳是为了标记版本。如果老师没给模板，就用这个规则，基本不会出错。

PDF元数据这个细节很多人忽略。Pandoc生成的PDF可以在开头用YAML头块写入标题、作者、日期：

--- title: "实验二：TCP三次握手抓包分析" author: "张三 20211004165046" date: "2024-10-20" ---

这样生成的PDF会内置文档属性，提交系统能识别，下载后也不是“文档1.pdf”这种无意义名字。如果你用Word，在“文件-信息”里设置标题和作者即可。这步花两分钟，但对做完报告后的归档、查重、提交管理都有用。

5. 实验报告避坑：五条让我翻过车的真实问题

这章是自查清单。我把自己和身边人反复踩的坑整理成五条，每条按“现象→原因→解决”写，交报告前对着看一遍，能挡掉大多数打回。

5.1 截图放大就糊，老师说“看不清”

现象：报告里的Wireshark截图，缩小到半页后协议列完全看不清，Info列也被截断；打印出来更是一团黑。原因：截屏时窗口没有最大化，关键列不在可视范围内；插入文档时又被Word压缩。解决：截屏前把Wireshark窗口最大化，隐藏冗余面板，把No.、Time、Source、Destination、Protocol、Info六列拖宽；保存为PNG，插入时不要拉伸超过页面宽度的80%。如果图片内容确实太宽，就分成两段上下贴，而不是整体缩小。但如果你的截图还是让人看不清，就用tshark把关键字段导出成文本表格，文字永远比图片可靠。

5.2 抓包只抓到一半，端口号找错导致全黑

现象：用Wireshark访问某个网站，显示过滤器填了tcp.port == 80，结果一个包都没有。原因：目标站点用的是HTTPS，服务端口是443不是80。这是最常见的新手抓包事故。解决：抓包时不设捕捉过滤器，先访问目标站点再停止；停止后，在显示过滤器里先用http试试，如果没有命中，就输入tcp.port == 443看TLS握手包。报告里要明确写“观察到TLS ClientHello，说明流量走443端口”，才算把分析闭环。我在帮别人改报告时还见过一种情况：过滤器写对了，但抓的是无线网卡，而流量走的是另一个虚拟网卡。解决方法是先确认Wireshark选中的接口是实际连接互联网或有通信的那个，否则什么都抓不到。

5.3 配置命令和拓扑对不上，老师一眼看出“这实验你没做”

现象：报告拓扑图画的是PC1–R1–PC2，R1只画了两个口，但配置代码里写的是G0/0/0和G0/0/1，而且配置里第二行接口地址和拓扑图IP完全对不上。原因：拓扑图是网上找的，配置是照着别人的课件敲的，实验和报告分离。解决：做实验时先建一个“接口-IP”对照表，每敲完一条配置就同步更新一次。报告中的拓扑图必须来源于实验文件本身，哪怕丑一点，也要接口号对得上。如果模拟器里显示的是GigabitEthernet0/0/0，拓扑图上不要简写成Fa0/0。对于Packet Tracer用户，接口缩写常常是“G0/0”，eNSP里是“GE0/0/0”，名称不同没关系，但引用要和拓扑图一致。

5.4 Markdown转PDF中文乱码，或图片路径失效

现象：Pandoc在Windows转换时，PDF里所有中文变成方块；或者Markdown里的图片路径是../images/xx.png，但转换后图片空白。原因：XeLaTeX没有指定中文字体；图片路径相对于当前工作目录失效。解决：转换前先运行fc-list :lang=zh看有哪些中文字体可选，然后在命令里显式设置CJKmainfont。图片路径建议都用相对于Markdown文件所在目录的相对路径，并且在Pandoc命令里加--resource-path=图片目录。如果图片是你用Python脚本生成的，还要注意文件名不能被Pandoc当成URL解析，例如不要包含#或?。我遇到过一次文件名带#，Pandoc把它当成锚点，图片死活不显示，这是典型的玄学。

5.5 提交前十分钟发现自己交的是旧版

现象：文件名是实验报告_final_final.pdf，提交后发现里面少了一节实验数据，而真正的最终版叫实验报告_最终版_真的最终.pdf。原因：没有版本管理，靠感性命名，导致“final”越叠越长，最后自己也分不清。解决：使用时间戳命名，每次有改动就重新保存为带新时间戳的文件，不要在原文件上覆盖。交报告前检查PDF属性里的创建时间，确认它不早于实验结束时间。如果你用Markdown作为源文件，还可以把整个目录放进git，每次改动都有commit消息，这样即使提交后再发现问题，也能找回历史版本。最后补充一个我自己的土办法：提交时把PDF文件名复制到微信输入框，看文件名长度就够用，不要手动敲“最终版”。

6. 把报告做成可复查的产物：实验脚本与PDF自动生成

这一章是进阶做法，也是我目前最推荐的收尾方式。前面几章把实验报告拆成了“目的、环境、过程、结果、PDF产出”，如果你每次都按这个流程走，会发现大量动作可以自动化。我一个最小示范是用脚本自动跑完一组网络测试，并把关键统计值输出到专门的文件：

#!/bin/bash set -e REPORT_DIR="./report_$(date '+%Y%m%d_%H%M%S')" mkdir -p "$REPORT_DIR" # 执行测试，输出到日志 { echo "Ping gateway..." ping -c 5 192.168.10.254 echo "Traceroute to target..." traceroute -m 10 192.168.20.1 echo "DNS lookup..." nslookup www.example.com } > "$REPORT_DIR/commands.log" 2>&1 # 提取关键统计值 cat "$REPORT_DIR/commands.log" | grep -E "rtt|loss" > "$REPORT_DIR/summary.txt"

这个脚本的逻辑很直白：以时间戳创建报告目录，把三个测试命令的输出全部存入commands.log，然后用grep提取包含rtt或loss的行生成summary.txt。注意set -e的作用是遇到任何命令返回非零就停止，避免“误以为实验成功”。跑完后，我打开summary.txt，把数字复制进Markdown报告的“实验结果”表格，再执行4.1节的Pandoc命令转PDF。由于日志文件名带时间戳，报告里可以直接引用这个文件名作为附件证据。

如果想要更自动化，还可以把summary.txt直接嵌入Markdown模板，用模板引擎渲染，再一键转PDF。但我不建议在初学阶段做太多封装，因为一旦脚本报错，排错时间比手动复制更长。我的习惯是：先手动跑通一遍，把命令和参数固定下来，再写自动化脚本。这样脚本只是帮你记录，不是替你理解。

最后说一句我自己的教训：第一次交计算机网络实验报告时，我的Wireshark截图糊成一片，命令输出也没有保存，被老师打回重做，才意识到“实验报告”四个字的重心在“实验”而不是“报告”。数据是真跑出来的，PDF只是它的容器。每次做实验前，先建好以时间戳命名的目录，跑完一条命令就存一份输出，写完一段就存一次Markdown，这样提交时永远有后悔药吃。这套流程我沿用至今，希望帮到你。

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