简介东南大学网安学院的《网络测量》课程设计资料包面向网络工程、信息安全方向的本科生及自学者用完整源码和运行说明串起理论学习与动手实践。压缩包约17.4MB内含课程设计的核心代码与启动/配置文档用于复现数据包捕获、流量预处理、特征提取等关键环节。已有142人学习适合正在完成同类课程设计或希望系统提升网络测量技能的读者。内容围绕TCP/IP协议栈各层机制展开涵盖Wireshark抓包与降噪、流量统计与异常识别如DDoS、带宽滥用、基于延迟/丢包率/吞吐量的性能评估以及ping、traceroute等工具的诊断思路源码可能涉及Python、C等语言运行说明会指导编译、启动和结果解读并配有实验场景与作业任务帮助读者从数据采集一步步走到结论输出。整体既可作为课程报告和实验复现的参考也能在源码基础上二次开发是网络测量入门和进阶都实用的资源。1. 网络测量课程设计的真正门槛不是测量算法是运行边界拿到“东南大学网安学院网络测量课程设计”的交付包时大多数人以为难点在测量原理实际卡人的地方几乎都在运行边界root 权限不够、抓包接口选错、iperf3 版本行为不一致、换个教室网络拓扑就变。这类课程设计的目标不是让你发明新协议而是把链路时延、带宽、丢包率这些网络指标用工程手段测出来并解释得自洽。适合谁网安学院高年级本科生以及刚接触网络基础设施评估的入门工程师。你要交付的不是论文是一个能从 zip 解压到运行、再出图和写报告都顺畅的完整链路。这篇笔记就按这条链路拆开讲。2. 网络测量课程设计拆解从验收标准反推测量对象和工具选型2.1 课程设计的验收通常看这三样报告、源码、运行结果网络测量类课程设计和纯算法课设最大的区别在于结果不是唯一的评分依据过程和方法论站更重的比重。老师拿到你的压缩包第一步是解压看有没有运行说明第二步是按说明在你自己的环境或机房机器上跑一遍关键脚本第三步才是看报告里的数据是否合理。也就是说“内含源码和运行说明.zip”这个交付形式本身就是评分项的一部分。我见过不少同学把精力全砸在写一个花哨的拓扑发现算法上结果 README 只有三行字依赖没列全一跑就报 ModuleNotFoundError。反过来有的组只用了 ping、traceroute、iperf3 这三个再普通不过的工具但脚本组织干净、参数有注释、报告里每个数据都能对应到一次具体测量过程最后评分反而更高。这是因为网络测量的核心能力是“可复现性”同一段命令换个时间、换个机器结果是否还能解释得通。所以我在拆解这类课设时习惯先画一张验收映射表报告里的每个结论必须能追溯到某段源码、某次运行输出或某个 pcap 抓包文件。反过来说源码里每个模块都要在报告里有对应的数据分析段落。这样课程设计就变成一个闭环工程而不是几段零散脚本的拼凑。2.2 测什么、用什么测四类测量对象与工具选型网络测量课程设计覆盖的对象通常集中在四个方向往返时延RTT、链路带宽/吞吐量、丢包率、路径与流量特征。课程要求不同侧重点不同但绝大多数任务都能映射到下面这张选型表上。测量对象推荐协议/工具输出指标常见坑往返时延ICMP Echoping或 raw socketRTT、抖动、丢包率目标主机禁 ICMP、NAT 影响带宽/吞吐量iperf3TCP/UDP 模式吞吐量、带宽上限、重传率并发数太小、窗口限制、单位混淆路径与拓扑tracerouteUDP/ICMP逐跳 IP、每跳 RTT、AS 路径中间节点不响应导致 * 号流量特征tcpdump / pcap / netflow包长分布、协议占比、连接数snaplen 截断、接口镜像问题选型逻辑上我一般遵循“能复用系统自带工具就不重复造轮子”。比如 RTT 测量直接用系统 ping 命令加参数就能拿到数据很多同学却非要自己写 raw socket最后卡在校验和计算上。不是说自研不行而是课程设计的重点在于测量数据的解读工具只要足够可靠、参数你能讲清楚就算合格。反过来也有一类任务必须自研比如要求测量 TCP 连接建立时间SYN→SYN-ACK 的间隔或者分析特定应用层协议的行为特征这时候系统工具给不了你这么细的粒度才需要 scapy 或 raw socket 自己构造报文。这个判断本身就是课设想考察的能力。2.3 开跑前先确认三个外部条件权限、目标可达、防火墙新手最容易忽略的是测量环境的外部约束。代码写得再对权限不够照样跑不起来。我每次拿到这类课设源码后先不做任何代码阅读直接按顺序确认三件事第一当前用户有没有 root/sudo 权限。raw socket 抓包、发送 ICMP、绑定 5201 以下端口都需要特权。很多课程设计的机房机器默认给普通用户脚本一跑就报 Permission denied。解决办法要么是用 sudo 执行要么在开发阶段改用非特权替代方案比如用系统 ping 命令而不是自建 raw socket。第二测量目标是否可达。检查默认路由是否正常DNS 解析是否可用目标主机是否在同一个网段。用ip route、ping -c 3快速验证。跨网段测 RTT 时中间经过的防火墙和安全设备可能对 ICMP 做限速或丢弃这会让你的丢包率数据失真需要在报告里如实说明。第三目标网络是否对测量协议敏感。有些主机默认丢弃 ICMP但 TCP 80/443 端口开放有些网络会限制 UDP 高端口流量。应对方法是准备“协议备胎”ping 不通就改用 TCP 连接时延测量iperf3 的 UDP 模式被限速就换 TCP 模式并分析重传。这些边界条件写进运行说明能帮评分老师快速理解你的测量报告为什么在某个时段出现异常数据。3. 把源码包从 zip 变成可复现测量环境依赖、权限与运行说明3.1 源码包里应该有哪些文件一个少返工的组织方式我解压过不少同学发来的课设压缩包最常见的问题是文件散落在根目录脚本和输出数据混在一起还有一堆无用的__pycache__和.DS_Store。这类结构虽然不影响运行但会让评分体验很差。一个合格的测量课设源码包建议按职责分层network-measure-lab/ ├── README.md # 运行说明环境、命令、常见报错 ├── requirements.txt # Python 依赖清单 ├── scripts/ # 所有测量脚本 │ ├── ping_measure.py │ ├── traceroute_measure.py │ ├── iperf_runner.sh │ └── pcap_capture.sh ├── data/ # 测量原始输出 │ ├── rtt_morning.csv │ ├── rtt_evening.csv │ └── captures/ ├── report/ # 报告和图表 └── tools/ # 自研的小工具如有这个结构的好处在于脚本、数据、报告三分离评分老师想复现哪个环节都能快速定位。data/目录保留原始输出文件很关键它证明了你的图表不是手绘的而是由真实测量数据生成的。我甚至建议把每次测量的时间戳写进文件名比如rtt_20250112_1000.csv这样对照报告时能直接判断数据来自哪一轮实验。3.2 从 zip 解压到环境生效venv 和依赖的一次到位运行说明里最不能偷懒的就是环境准备。很多课程设计要求 Python 版本、scapy、numpy、matplotlib 这些依赖但机房机器上往往没有预装。直接在系统环境里pip install可能污染其他课程的环境所以我推荐用 venv 隔离。下面这段脚本可以原样放进 README# 1. 解压并进入项目根目录 unzip network-measure-lab.zip -d network-measure-lab cd network-measure-lab # 2. 创建虚拟环境并激活 python3 -m venv .venv source .venv/bin/activate # 3. 安装依赖 pip install -r requirements.txt # 4. 验证环境 python scripts/ping_measure.py --help逻辑说明第 1 步的-d指定解压目录避免 zip 内的文件直接散落在当前目录第 2 步的 venv 把依赖隔离在项目内卸载时直接删除.venv即可不动系统 Python第 3 步的requirements.txt需要锁定主要版本比如scapy2.5.0原因在后面避坑章节会细说。第 4 步跑一次--help能快速暴露环境问题避免进入测量阶段才发现 import 错误。参数说明--help不是所有自写脚本都有没有的话可以临时改成python -c import scapy; print(scapy.__version__)验证核心依赖如果你的脚本需要 root记得用sudo激活环境后再执行否则 raw socket 照样报权限错误。3.3 运行说明怎么写出“别人也能复现”运行说明的本质是一份“最小化操作手册”目标读者是三天后的你、以及从来没看过你代码的评分老师。核心原则是每一步都给出命令每段命令都给出预期输出。我惯用的模板结构是这样# 网络测量课程设计运行说明 ## 环境要求 - 操作系统Ubuntu 22.04 / Debian 12其他系统需自行适配 - Python3.10代码用了 match 语法 - 权限测量阶段需要 sudo 权限普通用户只能跑数据分析脚本 ## 测量步骤 1. 时延测量sudo python scripts/ping_measure.py --target 202.38.95.1 --count 100 2. 带宽测量服务端 iperf3 -s -p 5201客户端 bash scripts/iperf_runner.sh 3. 抓包验证sudo bash scripts/pcap_capture.sh -i eth0 -c 500 ## 预期输出 - ping_measure.py 运行后生成 data/rtt_morning.csv第一列为序号第二列为 RTT(ms) - iperf_runner.sh 结束时输出 Summary 段落关注 Transfer 和 Bitrate 两列 ## 已知问题 - 若目标主机禁 ICMPRTT 数据为全空改用 scripts/tcp_ping.py 测 TCP 连接时延 - 若 iperf3 报 unable to connect检查服务端防火墙是否放行 5201 端口这份说明的细节在于“预期输出”和“已知问题”。前者让使用者确认自己跑成功了后者把你自己踩过的坑提前写好避免别人在同一个位置浪费时间。我见过太多运行说明只写到“运行python main.py”就结束了这等于把调试成本全部转嫁给使用者在评分场景下非常吃亏。4. 网络测量核心模块的最小实现ICMP、iperf3、tcpdump 的关键参数4.1 时延测量用 raw socket 发 ICMP Echo 的最小 Python 实现虽然系统自带 ping 命令但课程设计往往要求你在源码里体现对协议的理解。自建 ICMP Echo 请求就是最常见的切入点。核心难点在 ICMP 校验和的计算以及报文结构下面是一份可以直接改来用的最小实现import socket import struct import time def checksum(data): # ICMP 校验和计算按 16 位字累加进位回卷最后取反 s 0 for i in range(0, len(data), 2): part data[i] (data[i 1] 8) s part s (s 0xffff) (s 16) return ~s 0xffff def build_icmp_echo(seq, payloadbseu-nm): # ICMP Echo Request: type8, code0 header struct.pack(!BBHHH, 8, 0, 0, seq, 1) csum checksum(header payload) # 重新打包把计算出的校验和填入第 3 个字段 return struct.pack(!BBHHH, 8, 0, csum, seq, 1) payload def ping_once(dest, timeout2): try: sock socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP) sock.settimeout(timeout) packet build_icmp_echo(seq1) t0 time.time() sock.sendto(packet, (dest, 0)) data, _ sock.recvfrom(1024) t1 time.time() # IP 头默认 20 字节其后第 1 字节是 ICMP type icmp_type data[20] return (t1 - t0) * 1000, icmp_type # 返回毫秒 RTT except socket.timeout: return None, None finally: sock.close()逻辑说明ICMP Echo Request 报文格式是 type(1B) code(1B) checksum(2B) identifier(2B) sequence(2B) payload。校验和必须先把校验和字段置 0 再计算最后回填。接收数据时由于是 raw socket内核会把 IP 头和 ICMP 头一起返回所以读取 ICMP type 时要跳过 20 字节 IP 头。参数说明timeout2表示每个包的等待上限防止目标无响应时脚本挂死identifier 固定为 1多进程测量时建议改成 PID 末两位避免串扰payload 字节数影响 RTT 结果默认 8 字节你可以改成 64、512、1400 来观察分片和排队时延差异。这套代码在普通用户下会抛 PermissionError跑的时候记得加 sudo或者改用系统 ping 命令解析输出。4.2 带宽与吞吐量用 iperf3 命令把参数调明白iperf3 是带宽测量的标准工具课程设计里不需要自研 TCP 流发生器把 iperf3 的参数用好、数据解释清楚才是重点。一次典型的测量流程分服务端和客户端两步# 服务端通常是目标主机或对端实验室机器 iperf3 -s -p 5201 # 客户端本机发起测量 iperf3 -c 目标IP -p 5201 -t 30 -i 1 -P 4 --logfile data/iperf_tcp.json逻辑说明客户端发起 TCP 流服务端接收并周期性输出吞吐量。-t 30表示持续 30 秒-i 1每 1 秒打印一行中间数据-P 4开启 4 个并发流。并发数很关键单流在长肥网络高带宽高延迟上可能撑不满带宽因为 TCP 拥塞窗口需要足够大4 到 8 并发是课程设计里比较稳妥的区间。参数说明如果要测丢包率和抖动加-u切 UDP 模式再用-b 500M指定发送速率服务端会回报丢包和 jitter。用-R可以测反向链路避免上下行不对称造成误判。我建议把输出存成 JSON 格式后面画图时用 Python 直接解析比手动复制终端输出靠谱得多。注意 iperf3 的服务端和客户端版本要一致跨大版本经常出现协议不兼容下一章会展开讲。4.3 流量捕获tcpdump 的 snaplen、过滤与输出文件流量特征分析是网安方向课设的常客比如统计一段抓包里的协议分布、包长分布、TCP 重传次数。tcpdump 是首选工具但参数设置有几个容易翻车的细节# 抓取 ICMP 流量 500 个包完整包长写入文件 sudo tcpdump -i eth0 icmp -c 500 -s 0 -w data/captures/icmp_measure.pcap # 从 pcap 文件里读取并统计包长分布 tcpdump -r data/captures/icmp_measure.pcap -nn -l | awk {print length($0)} | sort -n | uniq -c逻辑说明-i eth0指定接口抓错接口是新手最常犯的错笔记本通常有两个接口物理网卡和无线网卡要选对-c 500抓满 500 个包自动停止避免文件无限膨胀-s 0表示 snaplen 不截断保存完整包内容如果只想要包头统计改成-s 96可以大幅减小 pcap 体积。参数说明过滤表达式写在-w之前常见的有tcp port 80、udp port 5201、host 10.0.0.1-nn不做 DNS 和端口名解析保留数字形式减少抓包文件里的歧义。分析阶段如果嫌 awk 不够用可以用 scapy 的rdpcap()读 pcap 文件替代适合在报告里生成协议占比饼图。4.4 数据呈现把多次测量合并成一张对比图测量做完只是第一步评分老师看的是你能不能把原始数据变成有说服力的结论。我习惯用 matplotlib 把同一指标在不同时段的分布画成箱线图比折线图更能体现 RTT 抖动特征import matplotlib.pyplot as plt import numpy as np # 假设两份 CSV 都是单列 RTT 数据 morning np.loadtxt(data/rtt_morning.csv, delimiter,) evening np.loadtxt(data/rtt_evening.csv, delimiter,) fig, ax plt.subplots(figsize(8, 4)) ax.boxplot([morning, evening], labels[上午10点, 晚间22点]) ax.set_ylabel(RTT (ms)) ax.set_title(不同时段的往返时延对比) ax.grid(alpha0.3) fig.tight_layout() plt.savefig(report/rtt_compare.png, dpi150)逻辑说明箱线图能同时展示中位数、四分位距和离群点比均值更能反映 RTT 的真实分布。早晚高峰对比是课程设计里最容易出结论的实验如果晚间 RTT 明显变高说明链路存在拥塞可以结合 traceroute 定位拥塞发生在哪一跳。参数说明delimiter,要和脚本输出的 CSV 分隔符一致dpi150保证报告里插图清晰tight_layout()防止标签被裁剪。如果测量数据量不足箱线图会很难看至少保证每组样本量在 30 个 RTT 以上统计意义才勉强成立。5. 网络测量课设避坑手册5 个高频现象的根因与解决办法5.1 现象普通用户一跑 raw socket 就 Permission denied这是时延测量脚本最常见的翻车现场。原因很直接构造 ICMP 报文需要 SOCK_RAW 套接字而创建 raw socket 需要 CAP_NET_RAW 特权普通用户没有这个能力。解决办法有三个最简单的是在运行说明里明确要求sudo执行第二是改用系统 ping 命令用subprocess调用并解析输出第三是给 Python 解释器单独加能力sudo setcap cap_net_rawep $(which python3)但机房机器不一定允许这么操作。我一般推荐方案二少一个权限依赖代码组织反而更清爽。5.2 现象iperf3 测出的吞吐量比链路带宽上限还高这个现象很误导人。排查时先看单位iperf3 默认输出里的 “Bitrate” 是 bpsbit per second很多同学误读成 B/s于是数值凭空大了 8 倍。另外服务器端网卡的 offload 特性可能让 TCP 聚合包变大吞吐量看起来虚高。解决方法是看两端报告里的 “Retr” 列如果重传为 0 且 CPU 占用不高基本可以确认数据可信同时用-O 3参数跳过前 3 秒的慢启动阶段取稳态吞吐量作为结果。5.3 现象tcpdump 抓了半天显示 0 packets captured三个级别的原因第一抓包接口选错机器上有 docker0、br-xxx 之类虚拟网卡真实流量不走这里第二过滤表达式和流量特征不匹配比如目标地址写错、端口写错第三如果是远程桌面连接的机器流量可能根本不过被测网卡的协议栈。解决方法依次是ip addr查看接口列表和 IP 确认物理网卡先去掉过滤表达式抓 30 秒看能不能收到包用ping 本机IP做自环测试验证抓包链路。5.4 现象RTT 箱线图锯齿状且解释不了原因测量数据里偶尔有几个离群点很正常但如果整体抖动剧烈先检查是不是测量环境自己引入的干扰。最常见的是并发测量互相干扰你同时跑着 iperf3 和 pingiperf 把链路拥塞打满ping 的 RTT 自然飙高。解决方法是给不同测量模块分配时间片比如先做 30 分钟带宽测量再单独做 10 分钟 RTT 测量保证同一时刻只有一个负载源在影响被测链路。另外后台的 apt 自动更新、云同步服务也可能产生瞬时流量测量前用nethogs或iftop扫一眼进程占用。5.5 现象“我机器上能跑”但交付包在别人机器上直接报错这是课程设计评分中最遗憾的翻车。原因通常是三点代码里用了绝对路径解压到别的目录后找不到文件依赖没写版本scapy 升个大版本后 API 变了脚本没有错误提示别人跑挂了只能看到一堆 traceback 无从下手。解决方法是提交前做一次“干净环境演练”复制 zip 到一台新虚拟机严格按 README 操作但凡有一步需要你自己动手改路径或装依赖就把这一步补进 README。这个演练动作强烈建议至少做一遍我自己的血泪经验是看起来 10 分钟的事能省掉评分时一半的沟通成本。6. 让测量数据经得起追问三组对照实验的验证思路6.1 基线对照与交叉验证课程设计的答辩环节老师最喜欢问的就是“你怎么证明这个数据是对的”。空口说“我测了好几遍”没有说服力要用对照实验来自证。第一组是时间基线在凌晨 3 点和晚高峰 8 点各测一轮同样的指标如果 RTT、丢包率呈现出明显的时间相关性说明测量链路是灵敏的你能捕捉到真实网络变化如果两轮数据几乎一致反而要怀疑是不是测量目标不对比如测的是本地回环或缓存数据。第二组是交叉验证用两种独立手段测同一个指标比如 ping 的 RTT 和 tcpdump 抓包时间戳算出的 RTT 对比误差在 10% 以内就说明测量链路成立。6.2 参数敏感性测试和报告呈现更进阶的做法是参数敏感性测试改变 ICMP 报文长度64、512、1400 字节观察 RTT 变化趋势。如果 RTT 随报文长度线性上升说明链路没有明显拥塞延迟主要是传输时延如果 1400 字节时报文被分片或丢弃就能顺带分析出路径上的 MTU 限制。这部分发现写进报告含金量比均值加标准差高一个档次。呈现上我建议每个结论都配上“测量条件”小表时间、工具、参数、样本量、目标地址让每个数据都有完整的上下文。最后说一个我自己的习惯每次交付课设前把压缩包当全新项目完整跑一遍从unzip到测量出数到画图全程记录时间和报错。哪个环节需要超过 30 秒去猜说明运行说明写得还不够。这门课给你的不是一套测量代码而是一套“如何让测量结论经得起复现”的思维习惯带着它做任何网络相关的工程评估都用得上。希望帮到你。本文还有配套的精品资源点击获取