简介面向南京大学2024年计算机网络课程学生的实验资料包内容覆盖从基础集线器/交换机到路由器、防火墙、可靠传输等七个实验适合需要边做实验边写报告的本课学生也适合其他高校网络课程学习者参考。压缩包含38个文件以Python脚本为主29个py用于实现实验功能另有txt配置说明、sh启动脚本、pcap抓包数据及README指南整体仅39KB目录结构清晰对应lab_1至lab_7。目前已有159人学习。资料按实验拆分为独立目录如lab_3与lab_5实现路由器及转发规则表lab_6模拟blaster/middlebox可靠传输lab_7设计防火墙规则同时每个实验都附有测试脚本和mininet拓扑脚本可帮助快速搭建环境并验证协议行为。从simple hub到自学习交换机、路由转发、流量控制层层递进对理解TCP/IP协议栈和网络编程实践很有帮助也可作为撰写实验报告的参考起点。1. 拿到 NJU-2024-计算机网络课程实验.zip先别急着解压先做环境预检拿到 NJU-2024-计算机网络课程实验.zip 这个压缩包我给你的第一个建议是别急着双击解压。这份压缩包在大部分人手里翻车并不是实验内容有多难而是在解压那一步就踩了环境、编码、依赖三个坑。它不是一份双击就能跑的作业包而是把抓包分析、Socket 编程、路由配置三段实验串成一条线的半成品工程给你拓扑和代码骨架要你自己把协议跑起来、把报文留下来、把验证证据提交上去。适合三类人正在修这门课的学生、准备考研 408 或者面试想补协议细节的工程师、以及单纯想验证书上的模型和线上跑的流量到底一不一样的计算机网络自学者。2. 环境与前置解压姿势、ZIP 结构与运行时依赖的匹配2.1 用 unzip 还是 7z先看压缩包结构再选解压工具很多人的第一个动作是右键解压我习惯先对压缩包本身做一次体检。ZIP 不是单文件格式它由本地文件头、中央目录和结尾的 EOCDEnd of Central Directory构成解压器是靠 EOCD 定位中央目录来恢复文件清单的。这个结构上的特点决定了后面几个坑EOCD 丢了整个包就废了中央目录里的加密标志位被改过解压器就会鬼打墙一样找你要密码。Linux 下先跑两条命令file NJU-2024-计算机网络课程实验.zip zipinfo -v NJU-2024-计算机网络课程实验.zip | head -40file输出的是实际文件类型和压缩软件特征如果它显示“Zip archive data, at least v2.0 to extract”说明包结构基本完整。zipinfo -v会列出每个条目的压缩方式、CRC32 校验值和加密标志一眼能看出哪个文件被动过手脚。我一般还会顺手看一眼条目总数和压缩前后大小和发布页给的文件数对得上再动手。选择解压工具时Windows 上我优先用 7-Zip 而不是系统自带的资源管理器解压因为系统自带解压对损坏包的提示非常模糊7-Zip 会明确告诉你“本地文件头损坏”还是“数据错误”。Linux 上用unzip或7z都行但我更推荐先file再unzip不要无脑上jar或python zipfile那些工具在遇到坏包时报错信息更隐蔽。常见的报错invalid zip archive: could not find eocd就是因为尾部 EOCD 区域缺失多半是下载中断或者多线程下载工具把尾部字节弄丢了这时候不要反复重试解压先用zip -FF做修复尝试。2.2 中文乱码与伪加密Linux 下解压课程包的两个拦路虎课程包里经常有中文文件名的附件或说明文档Linux 下直接unzip会解出一堆乱码名字因为压缩包里文件名编码是 GBK/GB18030而系统默认按 UTF-8 解码。解压时显式指定编码unzip -O GBK NJU-2024-计算机网络课程实验.zip如果发行版的 unzip 不支持-O参数比如某些 BusyBox 或精简版改用 7-Zip7z x NJU-2024-计算机网络课程实验.zip7-Zip 对中文编码的自动识别比 unzip 好乱码概率低很多。解压出来如果还有个别乱码文件手动mv改回正确名字即可不用重新解压。伪加密是另一个隐蔽坑。ZIP 的加密标志位在本地文件头和中央目录里各有一个 1bit 的加密位把这一位置 1 但实际没有做任何密码运算就是伪加密。解压器读到标志位就会弹出密码框而你输入的密码永远不对。判断方法是看zipinfo -v输出里文件名右侧有没有*号或者用7z l -slt查看Encrypted 。如果是伪加密7-Zip 经常能无视标志位直接解出如果 7-Zip 也坚持要密码再用十六进制编辑器定位到加密位把它改回 0。遇到真加密的包就不要再折腾了回发布页找解压密码才是正道暴力破解一个课程包的性价比是负数。提示对实验包做任何修改前先复制一份原始 zip 到别的目录。伪加密修复和 zip -FF 修复都可能把文件彻底改坏后悔药要提前备好。2.3 运行环境匹配Python 版本、Wireshark 与 Mininet 的兼容组合解压只是开始真正决定实验顺不顺利的是运行时环境。这门课三个实验对应三套工具链抓包分析用 WiresharkSocket 编程用 Python路由实验在 Mininet 或网络模拟器里做。我的建议是先定 Python 版本再装其他东西。Python 选 3.8 到 3.10 之间最稳。实验框架代码大多是前几年写的用的还是distutils这类老接口Python 3.12 把distutils从标准库里移除了装依赖阶段就编译报错非常劝退。如果你机器上只有 3.12用 pyenv 单独装一个 3.10 专门跑课程代码别拿系统 Python 去怼。Wireshark 注意抓包引擎Windows 上必须先装 Npcap 而不是老旧的 WinPcap装 Npcap 时勾选 “Support loopback traffic”否则后面抓本机回环流量的时候一片空白。Linux 上对应的是 libpcap一般 Wireshark 安装时会自动带上。Mininet 只在 Linux 上原生跑Windows 用户要么用 WSL2要么退而求其次用 GNS3 或 Cisco Packet Tracer 做路由实验。我见过不少同学在 WSL1 里装 Mininet折腾半天起不来拓扑最后发现是 WSL1 不支持必要的网络命名空间特性换 WSL2 就好了。装完跑一遍版本确认python3 --version wireshark --version mn --version三个命令都能正常输出环境这一步才算过关。环境准备阶段花半小时比实验中途全线翻车再回头排查省太多时间。3. 核心实验落地抓包、套接字编程与路由转发的作业路径3.1 抓包实验用 Wireshark 观察 TCP 三次握手与 HTTP 报文抓包实验的第一步是找一个能产生干净流量的目标。现在很多网站默认 HTTPS刚上手就抓 HTTPS 会看到一堆 TLS 加密内容协议分析课要观察的 HTTP 明文根本看不到我第一次做这个实验就吃了这个亏。建议先抓一个本地 HTTP 服务把自己机器当服务器和客户端流量可控且完全符合书本模型。启动一个最简单的 HTTP 服务python3 -m http.server 8000然后在 Wireshark 里选择回环接口loWindows 对应 Npcap Loopback浏览器访问http://127.0.0.1:8000。抓到的包用显示过滤器过滤tcp.flags.syn 1 tcp.flags.ack 0这是三次握手的第一个包客户端 SYN序列号从 0 开始Wireshark 默认显示相对序列号。继续过滤tcp.flags.syn 1 tcp.flags.ack 1这是服务器回应的第二个包SYNACK 同时置位它的确认号是 1表示“我收到了你的 SYN 且期待下一个字节序号是 1”。第三次握手的包特征是tcp.flags.ack 1 tcp.flags.syn 0。把这三个包的 Seq 和 Ack 列出来对照就能完整复现教材里那张握手时序图。这里有一个参数层面的坑写实验报告时一定要把相对序列号改回绝对序列号。方法是 Wireshark 里 Protocol Preferences → TCP → 取消勾选 “Relative sequence numbers”。否则你在报告里写 seq0老师用绝对序号一核对根本对不上。抓包时长控制在 30 秒内就够了别让 pcap 文件膨胀到几十 MB后续分析卡顿不说提交也不方便。TCP 连接建立后观察 HTTP 请求行的分层结构帧 → 以太网头 → IP 头 → TCP 头 → HTTP 报文。每个头的长度字段、校验字段都可以对照课本逐个验证。比如 IP 头里的 Total Length、TCP 头里的 Window Size这些字段书上给的是示意图抓包里看到的是真实数值两相对照理解深度完全不一样。3.2 套接字编程UDP 不可靠传输的最小复现与 netem 丢包模拟Socket 编程实验的核心不是写一堆代码而是用一个最小程序验证“不可靠传输”到底长什么样。我推荐从 UDP 下手因为 UDP 没有重传机制丢包现象在抓包里肉眼可见TCP 自带重传和拥塞控制单机实验很难立刻看出效果。服务端代码# udp_server.py import socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # SOCK_DGRAM 对应 UDP sock.bind((0.0.0.0, 8000)) print(UDP server listening on 0.0.0.0:8000) while True: data, addr sock.recvfrom(1024) # 单次最多接收 1024 字节 print(frecv {len(data)} bytes from {addr}: {data})客户端代码# udp_client.py import socket import time sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) for i in range(10): msg fpacket-{i}.encode() sock.sendto(msg, (127.0.0.1, 8000)) # 发往本机回环地址 time.sleep(0.1)先跑服务端再跑客户端回环接口上 UDP 基本不丢包10 个包全到。这不能证明 UDP 不可靠只能证明回环链路太理想了。要演示丢包需要人为在链路上加损耗Linux 的tc netem就是干这个的sudo tc qdisc add dev lo root netem loss 30%这条命令给回环接口加了 30% 的丢包率再跑一次客户端服务端接收到的包数会明显少于 10。对比 Wireshark 里的抓包结果客户端发出了 10 个 UDP 报文服务端侧只看到了 7 个那 3 个去哪儿了就是被 netem 直接丢弃了。UDP 没有确认机制发送端完全感知不到丢包这就是不可靠传输的实锤。实验做完记得清理sudo tc qdisc del dev lo root不然回环接口一直丢包后面别的实验都会莫名其妙地失败这种隐蔽环境问题排查起来非常消磨精力。提示在容器或 WSL2 里lo接口上做 netem 模拟有的内核版本不生效。用tc qdisc show dev lo看不到输出时换eth0接口做同样的模拟效果一致。理解了 UDP 之后再回头做 TCP 版本把SOCK_DGRAM换成SOCK_STREAM客户端发给服务器的数据在 Wireshark 里如果看到[TCP Retransmission]标记那就是 TCP 检测到丢包后的自动重传。这一个对比就把“可靠”和“不可靠”两条路径讲清楚了。3.3 路由实验Mininet 静态路由与 ip_forward 的配置验证路由实验的目标是让两个不同子网的主机互通核心是理解“数据包如何经过一跳又一跳到达目的地”。这门课的路由实验通常分两个层次先做静态路由再做动态路由协议。静态路由手动配置直观且方便调试动态路由引入协议收敛时间一旦配置有问题很难分辨是配置错误还是协议还在计算所以不要一上来就上 OSPF。我习惯用 Mininet 建最小拓扑两个主机连接同一个路由器各自位于不同子网。拓扑规划如下设备接口IP 地址网关h1eth010.10.1.10/2410.10.1.254h2eth010.10.2.10/2410.10.2.254r1eth010.10.1.254/24-r1eth110.10.2.254/24-在 Mininet 里启动多主机拓扑并进入路由器节点开启转发sudo mn --topo linear,2 --mac --switch ovsk --controller noneMininet 默认拓扑里两个主机在同一子网达不到路由实验目的需要按实验包里的拓扑脚本自定义。但不管拓扑长什么样路由器能转发跨子网流量前提是内核开了 IP 转发sudo sysctl -w net.ipv4.ip_forward1net.ipv4.ip_forward是 Linux 内核的 IP 转发总开关值为 1 表示允许在接口间转发数据包。不开这个开关路由器收到的包只进不出主机 ping 不通查半天都找不到原因。然后进入命令行配置静态路由。Cisco 模拟器里的配置语法是Router(config)# interface g0/0 Router(config-if)# ip address 10.10.1.254 255.255.255.0 Router(config-if)# no shutdown Router(config-if)# interface g0/1 Router(config-if)# ip address 10.10.2.254 255.255.255.0 Router(config-if)# no shutdown Router(config)# ip route 10.10.2.0 255.255.255.0 10.10.2.254解释一下最后一条静态路由的参数目标网段10.10.2.0掩码255.255.255.0下一跳10.10.2.254。意思是“去往 10.10.2.0/24 的包交给 10.10.2.254 转发”。静态路由实验要求你能解释清楚为什么只需要在路由器上配路由而主机只需要配默认网关——因为主机的默认网关负责把跨子网流量交给路由器路由器再用路由表决定往哪个接口送。这个理解是整份实验的核心考点。验证方式用 ping 和 traceroute。主机 h1 ping 通 h2 后用traceroute 10.10.2.10看到第一跳是路由器接口地址就能完整展示“主机 → 网关 → 目标”的转发路径。实验包里如果要求配置动态路由建议先把静态路由的验证结果留存再启 RIP 或 OSPF 对比变化这样报告里能写清楚动态协议节省了什么人工操作。4. 踩坑排查解压、抓包、环境三大翻车现场的血泪经验4.1 解压报“文件损坏”或“CRC 失败”压缩包还能救吗现象Windows 下用资源管理器解压到一半弹窗“压缩文件已损坏”或者用 7-Zip 解出一个文件后报“CRC 失败数据错误文件已损坏”Linux 下报invalid zip archive: could not find eocd。原因分三类下载过程丢字节导致 EOCD 或中央目录被破坏压缩包被做了伪加密标志位篡改杀毒软件实时扫描锁定了部分文件导致解压器读取时出现瞬时 IO 错误。90% 的情况是第一种尤其网盘下载大文件时。解决先把原始 zip 复制一份备份再用zip -FF做修复zip -FF NJU-2024-计算机网络课程实验.zip --out fixed.zip unzip -t fixed.zip-FF会忽略损坏的中央目录尝试从本地文件头恢复文件清单。修复后的包用unzip -t做完整性测试能通过大半文件就有救。修复不了的单个文件检查是否真的重要——很多时候重新下载一次比修复更快。如果是伪加密导致 CRC 报错用 7-Zip 直接尝试解压它绕开加密标志的能力比 unzip 强。这里有个教训原始 zip 永远保留一份别在原始文件上反复试修复。4.2 Wireshark 抓不到包或界面全黑先查这三处现象选择了正确的网卡点开始捕获列表区一直全黑或只有零星几个广播包自己浏览器产生的 HTTP 流量完全看不到。原因Windows 上没装 Npcap 或者在安装时取消了回环支持启动时没有管理员权限Npcap 过滤不到完整流量显示器过滤器语法写错把tcp.port 80写成了tcp.port 80单等号被当成赋值语法过滤结果恒为空。解决先重装 Npcap安装向导里勾选 “Support loopback traffic”。然后右键 Wireshark 图标选“以管理员身份运行”。最后检查过滤器栏Wireshark 的显示过滤器用的是双等号捕获过滤器用的是单等号写错位置就什么也看不到。确认这三处都没问题后在捕获选项里勾选本机流量对应的接口Windows 上通常叫 “Npcap Loopback Adapter”再抓一次就正常了。4.3 Mininet 启动失败与 Python 依赖冲突版本是首要嫌疑现象sudo mn --test pingall启动拓扑时报ModuleNotFoundError: No module named distutils或者控制器启动后立刻退出报Controller startup failed。原因Python 3.12 里distutils被标准库移除而 Mininet 和一些实验脚本还在import distutils另外系统里同时存在 apt 装的 Python 和 pyenv 编译的 PythonMininet 用了一套实验脚本用了另一套两边的 site-packages 互不可见就会出现装了什么依赖都还报 ImportError。解决用 pyenv 装 Python 3.10 并设为当前 shell 默认版本重新安装 Mininet 的 Python 绑定或者至少在调用mn时保证python3指向同一个解释器pyenv install 3.10.12 pyenv local 3.10.12 sudo python3 -m pip install mininet如果distutils报错来自系统脚本临时用python3 -m pip install setuptools也能补上。Mininet 自带控制器起不来的显式指定控制器类型sudo mn --controller ovsc --test pingallovsc是 Open vSwitch 自带的控制器比默认的 reference controller 稳。排查这个问题的顺序是先确认which python3再看/usr/local/bin/mn和/usr/bin/mn是不是同一套环境最后再动控制器参数顺序反了你可能在一个正常的问题上浪费时间。4.4 实验报告与留痕截图没有时间戳等于白抓现象提交报告后被打回理由是“无法确认抓包时间”“序列号对不上”“流量不是本次实验产生的”。原因Wireshark 默认不显示绝对时间列截图只有包序号默认使用相对序列号三次握手看起来全是从 0 开始系统时钟没同步抓包时间戳和真实时间相差几小时。解决抓包前先同步系统时间Windows 下用w32tm /resync或直接开自动时间同步。Wireshark 里右键列头添加 “Absolute time” 列并把 TCP 协议首选项里的 relative sequence numbers 关掉。截图范围固定在三次握手那 5 个包以内不要截一屏几百个包重点不突出老师也没法核验。有条件的话把对应的 pcap 文件一起打包提交比任何文字说明都有说服力。这门课程的验收逻辑就是看你有没有亲手抓过真实的包、配过真实的路由截图造假很容易被识别但真实截图足够清楚的时候根本不需要额外解释。5. 验证进阶用 tcpdump 和 checksum 判断实验是否真的跑通5.1 三次握手的命令行复核Wireshark 图形界面适合分析但这个实验真正吃透之后命令行也能快速验证。用 tcpdump 抓握手包sudo tcpdump -i any -nn tcp[tcpflags] tcp-syn ! 0 -c 20 -w handshake.pcaptcp[tcpflags] tcp-syn ! 0是伯克利包过滤语法表示“捕获任何 TCP 标志位含 SYN 的包”-c 20抓 20 个就停-w直接写成文件。抓完读包确认tcpdump -r handshake.pcap -nn tcp[tcpflags] tcp-syn ! 0 and tcp[tcpflags] tcp-ack 0第一条命令输出的是纯 SYN 包即握手第一步把tcp-ack 0改成tcp-ack ! 0看到的就是 SYNACK。两行命令一对握手包一个都不会少。控制台里能这么干净地过滤比在 Wireshark 图里点来点去更有把握。5.2 别把网卡校验和卸载误判成协议错误抓包时经常遇到一个伪警报Wireshark 里 TCP 或 IP 头的 Checksum 列显示红色incorrect很多人第一反应是网络有错或者自己配置错了协议。实际上这是网卡校验和卸载Checksum Offload导致的正常现象——网卡在发送数据时计算并填写校验和但抓包工具在报文离开协议栈之前就拿到了数据此时校验和字段还是空的。判断方法很简单看同一流里是不是所有包的 checksum 都红而且接收方向正常。如果只有发送方向的包校验和红接收方向全绿那基本可以断定是 Offload 特性。Wireshark 首选项里可以关闭Validate TCP checksum if possible红字就消失了。真正的物理层链路错误会伴随 CRC 错误和大量重传同时出现不要看到一个红就急着调防火墙。说到 CRC抓包文件的以太网帧尾部有 FCS 字段Wireshark 会做帧校验。你观察到的Bad FCS通常是抓包设备本身收坏了帧不是你主机上的问题处理方式同样是把这些帧过滤掉再分析。这套判断逻辑——先看方向、再看频率、最后才怀疑协议——是整份实验给我留下的最值钱的排查习惯。第一次做抓包实验时我盯着一个 TCP checksum 红了半小时后来想明白是校验和卸载的问题从此所有校验类异常都先确认硬件 offload 再说别的。把这个习惯带到期末复习和面试里也适用被问到 TCP 可靠性你直接讲一次抓包里 Retransmission 和 Dup ACK 的出现条件比背十行概念都管用。希望帮到你。本文还有配套的精品资源点击获取