简介：这是一份聚焦TCP协议迭代开发的计算机网络实验报告，覆盖RDT 2.0、RDT 2.2、RDT 3.0、选择响应协议以及Reno+拥塞控制等关键知识点，适合计算机网络课程学生、备考者以及希望深入理解传输层可靠传输机制的开发者参考。报告结合代码与LOG文件，详细分析了接收端校验和检查、发送端确认号队列跟踪、ACK包校验、超时重发及选择应答等机制，并针对拥塞控制中慢开始、拥塞避免、快恢复等阶段难以从日志中直接识别的问题，提出了每个传输轮次后输出当前发送序号、接收序号和cwnd值的解决思路。同时总结了迭代开发的优缺点，以及通过观察ssthresh和cwnd动态变化来理解拥塞控制过程的经验。资源为1个doc文档，大小约945KB，结构完整、重点突出，既有原理剖析，也有排错和报告组织方法。目前已有291人学习下载，对完成同类网络实验和撰写实验报告具有实用价值。
1. 计算机网络实验报告.doc 不是填空模板，而是可复现的证据链
很多人拿到《计算机网络实验报告.doc》，第一反应是赶紧找一份现成模板，把实验名称、班级学号填进去，再从网上抄几段结论。结果到了答辩或期末检查时，指导老师随口问一句“这个 RTT 是怎么测出来的”“重传包用了哪个过滤器”，现场就卡住了。计算机网络是一门验证性很强的课，TCP 重传、交换机转发表、CRC 校验、VLAN 划分，这些结论不是背出来的，是抓包抓出来、敲命令敲出来的。把实验报告当成工程文档来写，而不是作文来写，你的交付物才能在评审和面试里真正加分。这一篇就围绕一个问题展开：如何输出一份既经得起追问，又能自动化生成的 Word 实验报告，让 .doc 后缀不只是应付作业，而是可复用的技术资产。
2. 先解剖报告的技术骨架：场景、环境与可复现实验设计
2.1 课程实验、综合实验与生产验证：三种实验报告的不同侧重点
同样是《计算机网络实验报告.doc》，课程验证型、综合设计型、生产验证型三种场景的写法差异很大。课程验证型实验的报告重点放在“原理与报文的对应关系”上，比如抓一个 TCP 三次握手，要说明 SYN、SYN-ACK、ACK 分别对应抓包文件里的哪一帧；综合设计型实验要给出拓扑图、IP 规划表和配置脚本，结论是连通性验证结果；生产验证型实验则更强调变更前后的性能对比和回退策略。
| 实验类型 | 典型题目 | 报告侧重点 | 证据形式 | | 课程验证型 | TCP 三次握手、ARP 解析、ICMP 重定向 | 协议字段与操作步骤的对应关系 | 抓包文件、过滤表达式、报文截图 | | 综合设计型 | 小型校园网规划、VLAN 间路由配置 | 拓扑设计、地址规划、配置清单 | 配置文件、连通性测试表 | | 生产验证型 | 办公网割接、QoS 策略调整 | 变更对比、回滚条件、遗留风险 | 监控记录、设备日志、前后对比数据 |
拿到题目后先判断它属于哪一类，再决定报告里放多少理论、多少数据。写“验证型”实验翻来覆去抄课本原理，写“生产验证”又只放一张 ping 截图，都是份报告拿出去站不住脚的原因。基础是同一个：把实验场景定义清楚，别让读者猜你这份报告到底想证明什么。
2.2 用“五段式”结构替代流水账记录
我一般会把每份实验报告拆成五段：实验目标、实验环境、关键操作与配置、数据记录、结论与分析。这样所有实验都能复用一套骨架，后续转 Word、做目录也省事。下面是一个 Markdown 骨架，你可以直接拿它当中间格式来组织内容。
# 实验题目：基于 Wireshark 的 TCP 重传观察 ## 实验目标 - 观察 TCP 重传发生时的序列号变化 - 根据抓包结果估算重传超时 RTO ## 实验环境 | 项目 | 配置值 | | 操作系统 | Ubuntu 24.04 | | 抓包工具 | tshark 4.0 / tcpdump 4.99 | | 拓扑结构 | PC-A --- 交换机 --- 网关 | ## 关键操作与配置 1. 开启抓包 2. 发起连续 ping 3. 使用 tcp.analysis.retransmission 筛选 ## 数据记录 - 抓包文件：capture/tcp_retrans.pcapng - 过滤表达式：tcp.analysis.retransmission ## 结论与分析 - TCP 重传发生在第 12 帧，与前序包间隔 0.2 秒 - 原因分析：未收到 ACK，计时器超时触发重传这里把 Markdown 当作中间格式，好处是可以用 Git 管理版本，也可以让实验数据和报告文本放在同一个目录。五段结构不是模板，而是要求你把“目标、环境、操作、数据、结论”这五件事写清楚，缺任何一段，复现成本都会直线上升。尤其是“数据记录”里必须写清抓包文件的保存路径，别在报告里写“通过 Wireshark 抓包发现”，却不告诉读者 pcap 文件在哪儿，这不叫证据，叫感觉。
2.3 关键参数记录：不要只写结论，写命令和预期结果
实验报告最常见的毛病是“结论先行、过程失踪”。写 TCP 重传实验只写“网络存在重传”，却不写用什么命令触发、在哪个接口抓的包、过滤条件是什么。报告一旦落到别人手里，想复现就得猜。这里建议每个关键操作至少包含四个字段：操作命令、预期结果、实际输出、差异分析。
2.3.1 让操作步骤和计算机网络分层模型对应起来
写报告时最好明确每一步操作发生在哪一层。比如 ping 命令工作在网络层，交换机的 FDB 表作用于数据链路层，TCP 重传属于传输层行为。用“计算机网络自顶向下”的视角去组织叙述，读者就能很快判断你的配置是否合理。一个常见误用是拿 ping 的丢包率去证明“TCP 连接建立有问题”，但 ICMP 和 TCP 分属不同协议栈，中间可能还有流量整形设备在丢弃 ICMP，这样下结论就容易被质疑。报告中加一句“本次实验只验证网络层连通性，TCP 行为另见抓包文件”，严谨程度立刻不一样。
环境说明也要单独成表。很多报告只写“Windows + Wireshark”，但 Wireshark 版本影响解析规则，Linux 内核参数影响 TCP 重传行为，交换机的生成树模式影响转发表现。把这些变量写全，不是凑字数，是帮后面的人排除干扰项。
3. 用命令和抓包工具获取可追问的实验数据
3.1 先跑通最小验证命令，再开始录证据
写《计算机网络实验报告.doc》的素材阶段，不要急于打开 Wireshark 点鼠标。先准备一组能在终端里跑通的最小命令，确认网络环境正常，再录证据。下面是一组用 tcpdump + ping 做连通性验证的常用组合。
# 终端 A：后台抓包，只保留 ICMP Echo 请求的前 96 字节 sudo tcpdump -i eth0 -w ping-test.pcap -s 96 'icmp[icmptype] == icmp-echo' # 终端 B：向网关发起 10 次探测，间隔 0.5 秒 ping -c 10 -i 0.5 192.168.1.1-s 96的意思是 snaplen 设为 96 字节，ICMP 载荷不用看时能明显压缩 pcap 文件体积；-w把包写入文件而不是终端刷屏；过滤表达式icmp[icmptype] == icmp-echo只保留 Echo 请求，实际验证时建议同时抓 echo-reply，否则只有去程没有回程，很难说明链路双向正常。ping 的-c 10 -i 0.5表示发 10 个包、间隔 0.5 秒，适合观察时延抖动，也不会产生太多背景流量。先跑通这套组合，再决定要不要把抓包时间拉长。
3.2 把抓包结果整理成报告可直接引用的表格
pcap 文件本身不能直接贴进 Word，所以需要把关键字段导成文本或 CSV。用 tshark 按字段导出，比截图更清晰，表格数据也能在答辩时快速被追问。
tshark -r ping-test.pcap -Y 'icmp' -T fields \ -e frame.number -e frame.time_relative \ -e ip.src -e ip.dst -e icmp.seq -e icmp.rtt \ -E header=y -E separator=,这段命令里，-Y是显示过滤条件，-T fields表示按字段输出；-e frame.number输出帧编号，-e frame.time_relative输出相对时间，icmp.rtt是 Wireshark 计算好的往返时延，省去了手动用时间戳相减的麻烦；-E header=y让第一行输出字段名，-E separator=,生成 CSV，方便直接导入 Excel 或 pandas 做画图。导出的表超过 20 行时，报告正文只保留均值、最大值和异常样本，完整表放到附录或网盘链接，别让 Word 文档变成数据仓库。
TCP 重传的观察命令略有不同，因为重传不是靠“看到两个相同 seq”就算数，还要排除乱序、快速重传和超时重传。直接用 Wireshark 专家系统判断会更可靠。
tshark -r tcp.pcapng -Y 'tcp.analysis.retransmission' \ -T fields -e frame.number -e tcp.stream \ -e tcp.seq_raw -e tcp.len -e frame.time_deltatcp.analysis.retransmission是分析过滤器，Wireshark 已经综合了 ACK 和序列号变化来判断是否重传，比你自己数包要稳。输出里加-e tcp.seq_raw和-e tcp.len是为了核对原始序列号和载荷长度，frame.time_delta则能反映重传包和前一包的间隔，帮助判断是快速重传还是超时重传。把这些字段整理成表格，报告里再写一句“第 12 帧为重传包，距离上一个包 0.2 秒”，证据链就闭合了。
3.3 通过报文观察 CRC 校验：看计数器，不看包内容
很多人想知道“CRC 校验如何通过报文观察”，这是一个常见误区。以太网帧末尾的 FCS 字段是循环冗余校验值，绝大多数网卡在收包时先校验、再把 FCS 从帧里剥离，所以抓包文件里通常不会出现完整的 FCS 值。想在 Wireshark 界面里直接看到 CRC 数值，基本行不通。
| 观察对象 | 报告写法 | 容易犯的错 | | CRC 错误计数 | 写清接口名和统计值来源 | 把“抓包里看不到 CRC”说成“CRC 校验不存在” | | TCP 重传 | 给过滤条件和流号 | 只写“有重传”，不给 pcap 文件 | | RTT 波动 | 列均值 / 最小 / 最大 | 只写“网络很慢”，没有计算依据 |
正确的做法是去看网卡统计信息。在 Linux 下可以用 ethtool 直接读驱动维护的错误计数。
sudo ethtool -S eth0 | grep -i crc_errorsethtool -S输出的是网卡驱动暴露的统计项，不同厂商的字段名可能不同，常见的有crc_errors、rx_crc_errors、fcs_errors。看到这个计数在抓包期间持续增加，说明物理层或链路层存在帧校验失败；如果计数一直为 0，说明链路质量正常。在报告中写“CRC 错误计数 0，未发现 FCS 校验失败”，比写一句“链路正常”有说服力得多。对 FCS 被剥离的细节，也值得用一句话交代，这能体现出你对链路层和抓包原理的理解。
3.4 截图文件命名与路径规划
实验报告里的截图最好统一命名，建议用章节_序号_内容.png的方式，例如fig3_tcp_retrans_example.png。不要用中文文件名，Word 在跨平台复制时容易出问题。抓包文件单独放进capture/子目录，报告里引用相对路径，这样整份报告可以打包给其他人复现，而不只是一串文字。截图要截命令行和 Wireshark 窗口的关键区域，别把整个桌面截进去，避免泄露无关信息。
4. 用 python-docx 生成 .doc 报告：从 Markdown 到 Word
4.1 为什么优先选择脚本生成而不是纯 Word 手写
手工在 Word 里敲一份实验报告，边写边调格式，很容易出现标题不统一、表格边框缺失、图片大小不一致的问题。当实验报告数量多、还要频繁调整参数时，用脚本生成更划算。我通常的做法是：先用 Markdown 把报告内容写好，再用 python-docx 把内容灌进 Word 文档，最后用 LibreOffice 转成 .doc 交付。python-docx 本身只能保存为 .docx，不能直接生成老版 .doc，但现代评审环境基本都兼容 .docx；如果对方明确要求 .doc，用 soffice 一次性转换即可。
| 生成方式 | 优点 | 适用情况 | | Markdown + Pandoc | 编写快，适合代码块和表格 | 内部归档、技术博客改写 | | python-docx | 能精确控制样式、图片、目录域 | 多份报告批量生成、模板统一 | | Word 纯手写 | 所见即所得，临时微调方便 | 单份报告且没有重复交付需求 |
这里选 python-docx，是因为它的编程接口稳定，插入图片、表格、分页符都很直接，生成的 docx 可以被 Word 和 WPS 正常打开。
4.2 最小可用的 python-docx 生成脚本
下面这段脚本可以在十几秒内生成一份带标题、环境表格和证据图片的 Word 文档。
from pathlib import Path from docx import Document from docx.shared import Pt, Inches from docx.enum.text import WD_ALIGN_PARAGRAPH doc = Document() # 文档标题使用 Word 内置 Heading 样式，便于生成目录 doc.add_heading("计算机网络实验报告：TCP 重传观察", 0) # 环境信息表格 table = doc.add_table(rows=1, cols=2) table.style = "Light Grid Accent 1" hdr = table.rows[0].cells hdr[0].text = "项目" hdr[1].text = "配置值" rows = [ ("操作系统", "Ubuntu 24.04"), ("抓包工具", "tshark 4.0.6"), ("目标地址", "192.168.1.1"), ] for name, value in rows: row_cells = table.add_row().cells row_cells[0].text = name row_cells[1].text = value # 插入抓包证据图，限制宽度防止跨页 pic_path = Path("figures/tcp_retrans.png") if pic_path.exists(): doc.add_picture(str(pic_path), width=Inches(5.5)) doc.paragraphs[-1].alignment = WD_ALIGN_PARAGRAPH.CENTER doc.save("实验报告_tcp重传.docx")add_heading("...", 0)会把这一行设为 Word 的“标题”样式，目录功能可以直接识别；add_table配合table.style是为了避免表格没有边框；add_picture设置width可以把过大的截图压缩到版心宽度内，防止图片把页面撑破。doc.paragraphs[-1]指向刚插入的图片段落，设置居中后图片在 Word 里看起来更整齐。
4.3 中文字体与默认样式预设
python-docx 默认字体对中文不太友好，如果不设置，Word 可能会用默认西文字体渲染中文。生成报告前建议调整 Normal 样式。
from docx.oxml.ns import qn style = doc.styles["Normal"] style.font.name = "Times New Roman" style.font.size = Pt(11) style.element.rPr.rFonts.set(qn("w:eastAsia"), "宋体")这里把西文字体设为 Times New Roman，中文回退到宋体。qn("w:eastAsia")的作用是设置 Word 内容中的东亚字体属性，这一步在 WPS 和 Word 里都有效。如果导师要求正文用“宋体小四”，就把字号改成Pt(12)；如果标题要用黑体，可以通过修改 Heading 系列的样式实现，不要在写报告过程中手动去刷格式。
4.4 图片批量压一下，别让 doc 膨胀到几十兆
抓包截图清晰度要求并不高，一般 1600 像素宽就够了。用 ImageMagick 批量处理图片，再把压缩版本插入报告。
for f in figures/*.png; do convert "$f" -strip -resize '1600x1200>' "${f%.png}_web.png" done-strip会去掉图片的 EXIF 元数据，-resize '1600x1200>'表示只缩小不放大，宽或高超过 1600x1200 时才缩放。原始截图保留在figures/，报告中引用_web.png版本，可以显著降低最终文档的体积。很多实验报告卡在“一个 pdf/doc 超过 50MB”无法上传，问题多半出在这里。
5. 交付前让 .doc 真正可用：目录域、复核脚本和打印细节
5.1 在 Word 里放一个可自动更新的目录域
python-docx 生成的文档不会自动带目录，但可以写入一个 TOC 域。写入后用户打开 Word，按 Ctrl+A 再按 F9，目录就会根据标题样式自动生成。
from docx.oxml import OxmlElement from docx.oxml.ns import qn def add_toc(doc): para = doc.add_paragraph() fld = OxmlElement("w:fldSimple") fld.set(qn("w:instr"), 'TOC \\o "1-2" \\h \\z \\u') para._p.append(fld) return para add_toc(doc) doc.save("实验报告_tcp重传.docx")这里插入的是 Word 域代码，\o "1-2"表示只收集 1 到 2 级标题，\h让目录项变成超链接，\z是为了兼容 Word 的 Web 视图。域的好处是内容变化后可以更新，不是死目录。注意 python-docx 只负责插入域，不会替你计算页码内容，所以生成后第一次打开要手动更新一次域。
5.2 用复核脚本把报告里的证据再过一遍
交付前别只看文字，建议写一个复核脚本，重新读取 pcap 和统计值，确认报告里写的每一条数据都能从原始文件里找到。
set -euo pipefail echo "== pcap 时间戳 ==" stat -c %y capture/ping-test.pcap | tee evidence/pcap_time.txt echo "== ICMP 回复数量 ==" tshark -r capture/ping-test.pcap -Y 'icmp.resp_in' | wc -l | tee evidence/icmp_count.txt echo "== CRC 错误计数 ==" crc=$(ethtool -S eth0 | grep crc_errors | awk '{print $2}') echo "crc_errors=$crc" | tee evidence/crc.txtset -euo pipefail让脚本在任一命令出错时立即退出，避免带着半份结果交付；tee把输出同时打到终端和evidence/文件，留下复核痕迹。用这套脚本跑一遍后，报告里引用的抓包时间、ICMP 回复数、CRC 计数就都有了独立来源。若 tshark 输出的行数和报告对不上，先检查 pcap 文件是否被覆盖，再检查过滤条件是否写错。
5.3 文件名、页边距和表格跨页这些最后 5 分钟要处理的事
最终导出的文件不要叫“新建文档.docx”，命名里要带实验关键词和日期，例如tcp_retrans_实验报告_20250914.doc。Word 页面设置里把页边距调成常规的 2 厘米，避免打印时表格被截断。含有跨页表格时，选中表格行，在“布局”里勾选“在各页顶部重复标题行”，否则第二页的表格没有表头。最后用 LibreOffice 转成 .doc 后，再打开一次检查字体是否被替换，保存前把原始 pcap、脚本和 docx 副本一起留在实验目录中。下次换参数、换场景时，这份报告能让你在十分钟内重建整条证据链，而不是再从零开始抓包写文档。
本文还有配套的精品资源，点击获取
