简介：南京大学2024年计算机网络课程实验合集，涵盖lab_1至lab_7共七个递进式实验，涉及集线器/交换机转发、路由器配置、防火墙设置、可靠传输模拟等主题，适合学习网络原理的学生、自学者或需要参考实验设计的教师。压缩包共38个文件，主体是29个Python脚本，另含6个文本配置说明、1份README指南、1个Shell启动脚本与1份pcap抓包数据，整体大小约39KB，轻量易查阅。目前已有160人学习。借助实验源码、测试脚本和抓包文件，可以还原每个实验的操作流程与验证方法，比如查看二层交换逻辑、路由表与防火墙规则设计，以及模拟网络通信中的丢包和重传。如果希望快速了解南大课程实验结构，或用Mininet搭建类似环境进一步练习，这套资料能提供直接的参考和动手基础。
1. 这个压缩包是南大计网课程的“实弹训练”：先想清楚它值不值得花一个学期
期末前两周，课程群里常见“求一个做完的NJU-2024-计算机网络课程实验.zip”——这是南京大学2024年计网课程实验的整套打包：实验指导、代码框架、评测脚本都在里面。它练的不是背出TCP三次握手，而是把socket通信、抓包分析、可靠传输、路由模拟从头到尾跑一遍。很多人的真实状态是：解压十分钟，跑通第一个demo两小时。读这篇的人大多带着三个问题：这包值不值得逐行啃、按什么顺序做容易拿分、做完后的参数能不能顶到面试里。这篇不讲虚的，只讲怎么做、坑在哪。在校生、求职者和想补网络基本功的工程师，都能从这套实验里拿到各自要的东西，前提是愿意在看不见的协议状态上花时间。
2. 解开压缩包先盘家底：目录结构、运行环境与最小启动命令
2.1 实验包该有的模块：从Socket到路由模拟
这类计网课程实验包通常装四样东西：实验指导书、源码框架、测试脚本、样例包。指导书告诉你评分点，源码框架把最麻烦的序列化和拓扑解析写好，测试脚本就是你拿分时会被调用的东西，样例包里是已经抓好的报文，用来对着改代码。四样东西里，指导书最容易被忽略，但README里往往写清楚了“评测时只看哪些输出”，这比你自己琢磨代码管用得多。
模块顺序也基本固定：先是Socket编程，再做HTTP与抓包分析，接着是实现可靠数据传输，最后做路由协议模拟。难度不是线性涨的：Lab1会卡在并发和分包，Lab2卡在过滤器写不好，Lab3和Lab4是真正让多数人熬夜的地方，因为它们考的是协议状态机——GBN的窗口怎么重传、RIP的坏消息怎么传播，这些在书上看都懂，写进代码就是另外一回事。
配套教材的话，我一般推荐一个组合：实验主视角用《计算机网络自顶向下》对照分层设计和Socket讲解，《谢希仁计算机网络》用来补协议细节。如果目标是备考408，王道和湖科大教书匠的网课能把“为什么这样设计”讲透，但实验里的工程坑课里不会讲，得自己踩。拿到包先别急着解压，先看README和test目录，按多数实验包的通行布局，“家底”大体长这样：
| 目录 | 常见内容 | 建议优先级 |
|---|---|---|
| LAB1_Socket/ | client/server 框架、Makefile 或 requirements | 先跑通 |
| LAB2_Packet/ | 抓包指导、样例 pcap 文件 | 阅读为主 |
| LAB3_RDT/ | 报文序列化框架、丢包模拟器 | 分配最多时间 |
| LAB4_Routing/ | 拓扑文件、转发逻辑框架 | 最后冲刺 |
2.2 先将环境对齐：选版本本身就是避坑
课程实验最容易被环境吃掉时间。按下面这套省心组合来，绝大多数情况不会卡壳：Python 选 3.8 到 3.12 之间，不要追求最新版，框架里如果用了 scapy 这类依赖，新版解释器发布后兼容补丁不一定跟上，import 直接失败；Wireshark 装 4.x，Windows 下安装时要勾选安装 Npcap，Linux 装好后把当前用户加进 wireshark 组，否则打开时接口列表全是灰的；路由模拟实验尽量用普通 Linux 虚拟机跑，WSL2 日常写代码够用，但虚拟网卡行为和真实 Linux 不完全一样，实验现象不符合预期时先怀疑环境而不是源码。
提交作业多数要求 zip 包，用zip -r 学号-姓名.zip 学号-姓名/打包，提交前用unzip -l检查文件名和内容再传。这套组合里最值得记的是版本不要乱升，计网实验不是生产项目，框架通常只在某个 Python 小版本上测过，我见过有人用新版本解释器跑实验框架，scapy 直接报错，两小时全花在解决依赖上，这是血泪经验。动手前先自检三条命令，环境对不对一眼看清：
python3 -V wireshark --version gcc --version2.3 最小启动命令：从解压到跑通框架自检
解压这步有一个高频坑：Windows 里打包的 zip，文件名是 GBK 编码，直接 unzip 会变成乱码，源码里出现“锟斤拷”。常见做法是解压时指定编码，然后立刻看目录结构和跑自测：
# 用 -O gbk 按GBK解压，避免中文文件名乱码（macOS自带unzip不支持该参数，用7z或p7zip替代） unzip -O gbk NJU-2024-计算机网络课程实验.zip -d nju_cnlab cd nju_cnlab # 看看包里到底有什么 find . -maxdepth 2 -type d | sort # 先跑框架自带的自测，环境对不对这一条就能试出来 python3 -m unittest discover -s LAB1_Socket -v第一条命令里的-O gbk是关键，同一个 zip 在 Windows 下正常，换到 macOS/Linux 就乱码，属于典型的换电脑就翻车。如果解压时直接报invalid zip archive: could not find EOCD，说明文件没下完整或者传输被截断，先重新下载，再用unzip -t测试完整性。find命令不是炫技，而是让你在改代码前确认四个目录都在；很多同学上来就进 src，改到一半发现测试脚本在 test 目录，评分读取 log 文件，搞错位置就全白做。
先跑自测更重要：一个能过的单元测试说明依赖装齐了、端口能绑、基础网络栈没被系统策略拦住。如果自测失败，记录第一行报错而不是整个终端刷屏的堆栈，多半是路径带空格、python 命令指向错误版本或者依赖没装。自测通过后建议立刻git init && git add -A && git commit——课程实验是反复改 bug 的过程，保留一个初始干净版本，后面把框架改坏时随时回滚，这就是你的后悔药。不需要推送到任何远程库，本地仓库就够。
3. 从零跑通Socket实验：一个可复现的TCP并发服务器与三个参数坑
3.1 实验要求拆解：客户端/服务器各要交付什么
Lab1 一般做的是 echo server 或文件传输：客户端连上、发消息、服务器原样返回或落盘。功能本身不难，难的是评测脚本怎么调用你。常见的评测方式是：启动 server，然后并发拉起几十个 client，每个 client 发送长度不同的内容，再逐字节核对返回值；还会在传输过程中直接掐断连接，看你的 server 是否崩溃。
所以交付的不只是“能聊天的程序”，而是四件事：能并发接受多个连接、对半分片或粘包的内容也能还原、异常断开不会带走整个进程、日志能指出每个连接从建立到关闭的状态变化。这四点分别对应并发模型、消息边界、异常处理和可观测性，也正是计网面试里被反复问的四个点。
3.2 TCP并发服务器参考实现（Python）
给一个能直接跑的最小参考。它用定长帧头解决粘包，用 read_exact 解决半包，线程模型处理并发，SO_REUSEADDR 解决实验机重复启动 bind 失败：
import socket import threading import struct def handle_client(conn, addr): # 帧格式：前4字节为大端长度，后面是payload def read_exact(n): buf = b"" while len(buf) < n: chunk = conn.recv(n - len(buf)) if not chunk: raise EOFError("client closed early") buf += chunk return buf try: length = struct.unpack("!I", read_exact(4))[0] payload = read_exact(length) # echo：按帧原样返回 conn.sendall(struct.pack("!I", length) + payload) except Exception as e: print(f"[{addr}] error: {e}", flush=True) finally: conn.close() def main(): srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 这个参数必须放在bind之前，否则TIME_WAIT会让第二次启动失败 srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind(("0.0.0.0", 8080)) srv.listen(128) while True: conn, addr = srv.accept() threading.Thread(target=handle_client, args=(conn, addr), daemon=True).start() if __name__ == "__main__": main()read_exact 是这版的核心。TCP 是字节流，recv 返回的字节数不保证等于消息长度，所以先定好“前 4 字节无符号大端整数是负载长度”，再按长度把内容收满。客户端发的时候也遵循这个帧格式，就不会发生粘包拆包混乱。SO_REUSEADDR 要放在 bind 之前才生效，这个参数解决的是 TIME_WAIT 状态下端口被占用的问题：实验场景里服务器反复重启，不加它第一次正常，第二次就报 Address already in use。
listen(128) 的 128 是 backlog，指内核为这个监听 socket 排队的连接数，不是并发上限。做并发压测时如果 accept 处理得慢，超过 128 的连接会排队被内核丢弃，表现为客户端 connect 超时。换成 selectors 或 asyncio 能处理更高并发，但课程评分一般不要求，手写线程模型最容易向面试官讲清楚每个客户端连接做了哪些事。
3.3 三个必调参数：recv缓冲区、超时、listen队列
第一个常见错误，是把 recv 的 n 设成 1。比如data = conn.recv(1)加循环去拼包，逻辑上没错，但每收一个字节都是一次系统调用，CPU 马上被打满，数据量一大就变成蜗牛。用recv(4096)一次性拿大块，再从缓冲区按帧取。
第二个是忘记给连接设置超时。客户端建立连接后不发数据，线程就永久阻塞，多个这样的连接会把线程耗尽。在 handle_client 开头加conn.settimeout(5)，超时抛异常后走异常分支关闭连接。
第三个是 listen 队列设置得不合适。实验机本地压测，128 够用；如果要演示并发上限，可以调到 1024 并观察ss -tnl里的 Send-Q。记住它和并发上限不是一回事，别在报告里写错。这三个参数背后的道理，是应用层和传输层的边界问题：TCP 保证字节有序不丢失，但消息边界、超时策略和并发策略都是应用层责任。面试官顺着这个思路问下去，你还会聊到滑动窗口和拥塞控制，正好对应后面的可靠传输实验。
4. 抓包实验的上手路径：Wireshark过滤器与三个隐蔽坑
4.1 抓包实验的评分点：不是抓到包，是过滤器写对
抓包实验最翻车的不是抓不到，而是抓到一大堆不知道怎么交差。评分老师通常只看三样：过滤器表达式写没写对、关键报文有没有标出来、报告里的序号/确认号/时间对不对得上。所以动手抓包前先想明白要验证哪条协议行为——三次握手、HTTP 请求响应还是重传，然后只抓这个范围，别开全局捕获。
课程实验里有一类经典题目：利用 Wireshark 观察 TCP 三次握手的序列号变化。你要能指出 SYN 包的 seq、SYN-ACK 包的 seq 和 ack，以及双方 seq 的递增规律。这个观察过程比截图本身重要，因为很多框架自带日志不打印网络层数据，抓包是唯一能证明你“真的发了这些报文”的途径。
4.2 必背的过滤器表达式：一张表解决大多数课程评分点
| 实验场景 | 显示过滤器 | 说明 |
|---|---|---|
| 抓本机实验端口 | tcp.port == 8080 | 只看这个端口的双向流量 |
| 区分单台主机 | ip.addr == 192.168.1.5 && tcp | 双向都显示 |
| 看三次握手 | tcp.flags.syn == 1 || tcp.flags.ack == 1 | 快速筛握手包 |
| 找HTTP请求 | http.request.method == "GET" | 只显示GET请求 |
| 找响应状态码 | http.response.code == 200 | 只看成功响应 |
| 本机回环通信 | ip.addr == 127.0.0.1 | 客户端服务器在同一台机器 |
注意 Wireshark 有两套过滤器：捕获过滤器（BPF 语法）和显示过滤器。课程实验写进报告的是显示过滤器，语法像tcp.port == 8080。新手容易下意识在显示过滤栏里填port 8080，那是 BPF 语法，马上报错，这是最常见的零分操作。
4.3 三个隐蔽坑：环回口、无权限、TLS加密
第一个坑是本机通信抓不到。客户端和服务器都在同一台机器上，流量走的是 loopback 接口，Wireshark 默认抓物理网卡，所以你看到的是空。解决：界面选 Loopback: lo，或命令行用-i lo。有的虚拟机里有两张虚拟网卡，选错了另外一张也会空。
第二个坑是权限。Linux 里普通用户打开 Wireshark，接口列表一片灰，提示没有权限。不要去sudo wireshark，那样抓到的文件归属 root，后续报告整理和文件导出都别扭。正确做法是sudo usermod -aG wireshark 你的用户名，重新登录后再开。
第三个坑是抓了一堆 TLS 密文。现在很多服务默认 HTTPS/QUIC，课程实验要求看 HTTP 明文时，要么在实验环境里自己起明文 HTTP 服务，要么临时关掉协议自动升级。报告中遇到加密报文，要写清楚“由于 TLS 加密，application data 不可读，握手阶段可见”，这比硬编造一段 HTTP 请求诚实得多，也符合计网实验重过程、轻结果的评分风格。再补一个玄学：防火墙有时会拦回环数据包，过滤器正确、接口正确还是空时，关掉防火墙再试一次，大多数情况是这个原因。报告里放截图时，记得在图上标注关键字段：序号、确认号、窗口；用 Wireshark 左下角的 Expert Info 看异常报文，写一句“这里出现乱序重传，原因是发送端突发量过大”这类观察，比堆十张截图得分高。
5. 避坑：可靠传输与路由模拟里最容易翻车的5个问题
5.1 可靠传输实验：窗口、丢包与超时重传的置错点
可靠传输实验是所有计网实验里最像真实工程的：基于 UDP 实现一个可靠协议，还要在丢包模拟器下测吞吐。大部分课程框架会给你一个 send/recv 的桩，要求实现 seq 编号、ACK、超时重传和窗口。光把功能跑通不难，难的是在 2% 丢包率下让它表现正常。
设计上有三个参数决定成败：窗口大小、超时时间、丢包注入方式。窗口太大，重传风暴会把带宽打没；窗口太小，吞吐上不去。超时时间比 RTT 短，会疯狂重传；比 RTT 长太多，性能白白浪费。丢包注入最好是可配置的，不要写死在 random 里，否则测试时丢包率不可控，报告里的实验数据也没法复现。选 GBN 还是 SR，课程要求说了算。GBN 接收方只需要一个窗口、发累积 ACK，实现简单但丢包率高时重传量大；SR 接收方要维护重排缓冲区，实现复杂但在高丢包率下吞吐明显更好。面试常问“为什么丢包率到 5% 时 GBN 几乎不可用”，答案就是累积重传放大。
5.2 路由模拟：毒性逆转、无穷计数与拓扑收敛
路由模拟实验里常见的是实现 RIP 距离向量，或者按老师要求实现链路状态。距离向量算法有一个著名毛病：好消息传得快，坏消息传得慢。A-B-C 链路里 C 断掉，B 发现不可达，广播给 A，A 又把自己的旧路由传回给 B，形成计数到无穷大。课程老师喜欢在拓扑里埋这个实验点，让你观察收敛轮数。
排错时先检查三件事：是否实现了毒性逆转，是否做了水平分割，路由更新定时器有没有和转发逻辑混在一起。很多同学把“定时广播路由表”和“收到更新后立即重算”写进同一个循环，结果是同一轮里你改我、我改你，下一跳不停震荡。常见做法是分成两个事件：更新定时器只负责发送当前表，收到消息再触发重算。
5.3 现象 → 原因 → 解决：五条踩坑记录
现象：UDP 模拟实验里，客户端发出去的包经常收不到或乱序。原因：接收缓冲区用的是默认大小（约 8KB），模拟器一旦突发多包，内核直接丢包。解决：在 socket 上显式设置
SO_RCVBUF到 65535 甚至更大，把缓冲区配置写进实验报告，说明这是测量后的选择。现象：GBN 在 1% 丢包率下吞吐降到几乎为 0。原因：超时重传时间拍脑袋设成 10ms，实际 RTT 大概 30ms，发送方还没收到 ACK 就超时，于是反复重传。解决：先用 ping 等方式估算 RTT 基数，把超时设成平均 RTT 的 2 到 3 倍，并做指数退避，实验数据立刻正常。
现象：路由模拟里始终存在环路，收敛很多轮也不结束。原因：距离向量实现里没有毒性逆转，对不可达邻居还把旧路由广播出去。解决：对下一跳指向本路由器的邻居，把对应目的网络的 metric 设为 16 跳（RIP 的无穷大），同时开启水平分割，把这条写进 README 并展示收敛前后表项对比。
现象：并发压测到几百个连接时 server 卡死或者 Segmentation fault。原因：多个线程共享同一个路由表或日志缓冲，不加锁导致数据竞争；少数情况是每个线程的默认栈不够大。解决：每个连接持有一个独立 buffer，全局日志统一加锁；想更简洁就换成 selectors 单线程多路复用，课程报告里还能多一个加分点。
现象：解压后文件名全是乱码，源码文件里出现“锟斤拷”。原因：压缩包在 Windows 下用 GBK 编码文件名，类 Unix 解压工具默认按 UTF-8 解析。解决：解压时用
unzip -O gbk；已经解压坏的目录用convmv -f GBK -t UTF-8 --notest -r .批量转码，之后重新跑测试脚本确认没有文件被漏解压。
6. 验收与复盘：三分钟确认实验做完，还能把它讲成项目经验
课程实验的最后一个环节往往被低估：验收。按下提交按钮之前，用一个三分钟的脚本检查服务器状态、并发能力和抓包结果。下面是一段可直接改的 bash 验收片段，适用于跑在本机的 Socket 或抓包实验：
# 1. 端口在听：看LISTEN和进程 ss -tlnp | grep 8080 # 2. 并发连接：短时间拉50个连接，数established for i in $(seq 1 50); do curl -s http://127.0.0.1:8080/health >/dev/null & done sleep 2 ss -tn state established '( dport = :8080 )' | wc -l # 3. 抓三次握手：只抓回环口上的SYN/SYN-ACK/ACK tshark -i lo -c 3 -f 'tcp port 8080' -Y 'tcp.flags.syn==1 || tcp.flags.ack==1'第一段检查端口有没有起来，第二段验证并发，第三段直接看协议层。三条都过，说明代码在“能用”之外还有证据；任何一条没过，按第 5 章的坑去排查。如果机器里没装 tshark，直接在 Wireshark 图形界面套同样的过滤器条件也可以，效果等价。
如果你走的是面试或校招方向，这套实验非常适合写进项目经历：不要写“熟悉 TCP/IP”，写“实现基于 UDP 的可靠传输协议，窗口和超时参数可调，支持注入 2% 丢包观察吞吐变化”。后者一拿出来就是话题，面试官可以直接追问窗口怎么选、重传怎么退避。devops 工程师也一样，线上服务大量 TIME_WAIT、负载均衡连接打满，这些场景和实验里的参数坑是同一套底层逻辑。
最后说一个我自己的习惯。当年做可靠传输实验，为了追求大窗口，把超时时间写成 10ms，结果在平均 RTT 30ms 的模拟器上疯狂重传，一晚上没跑出有效数据；后来养成习惯：改任何参数之前，先把当前链路的 RTT 和丢包率测一遍作为基线。计网实验真正值的不是那几个学分，是你以后排查问题时的本能——先测量，再动手。希望帮到你。
本文还有配套的精品资源，点击获取
