简介这份资源是东南大学网络安全学院网络测量课程设计的完整实践资料包面向正在修读网络测量、网络性能分析相关课程的高校学生以及希望动手理解网络流量采集与分析的初学者。内容围绕TCP/IP协议栈理解、数据包捕获与预处理、流量模式识别、延迟与丢包率等性能指标评估展开并配有源码与运行说明便于将课堂理论落到可运行的实验环境中。压缩包为zip格式整体约17.4MB内含源码与说明文档等文件源码可用于阅读网络测量工具的实现逻辑运行说明则帮助完成编译、执行与结果解读。目前已有142人学习关注适合作为课程设计参考、实验复现与排错思路的对照材料也可为后续网络管理、安全分析方向的学习打下实践基础。1. 网络测量课程设计到底在测什么从一份能跑通的源码包说起很多人第一次接触网络测量课程设计脑子里浮现的是 Wireshark 抓包、看几条 TCP 流、写个报告就交差。真到动手才发现课程设计要的不是会抓包而是能设计一套可复现的测量流程——从流量采集、特征提取、指标计算到结果可视化每一步都要有明确的输入输出和可验证的中间结果。这份东南大学网安学院的网络测量课程设计核心就是让你用一份带源码和运行说明的工程把测量这件事从概念落到能跑起来的代码上。它解决的是三个具体问题一是让你理解网络测量里时延、丢包、带宽、流特征这些指标到底怎么算出来的二是给你一套可改可扩的代码骨架不用从零搭环境三是通过运行说明让你能在本地复现整套流程而不是对着别人的截图猜。适合谁适合正在做网络测量、网络流量分析、网络安全课程设计的学生也适合想补上测量这一环的运维和开发。下面我按先跑通、再拆解、后避坑的顺序把这份课程设计里最值得复用的部分讲清楚。2. 把源码包跑起来环境、依赖和最小验证路径2.1 先看清目录结构再动手别急着 pip install拿到一个课程设计压缩包最常见的翻车方式就是解压完直接pip install -r requirements.txt然后被一堆版本冲突卡住。我一般会先花五分钟把目录结构过一遍确认入口文件、配置文件和数据集分别在哪。典型的网络测量课程设计目录大致长这样network-measurement-course/ ├── src/ │ ├── capture/ # 流量采集模块 │ ├── features/ # 特征提取 │ ├── metrics/ # 指标计算 │ └── visualize/ # 结果可视化 ├── config/ │ └── settings.yaml # 采集与计算参数 ├── data/ │ └── sample.pcap # 示例流量 ├── requirements.txt └── run.py # 统一入口先确认run.py或main.py这类入口是否存在再看config/settings.yaml里有哪些参数需要改。很多运行说明里写的直接运行其实默认你已经把数据路径配好了路径不对就会报FileNotFoundError这不是代码问题是配置问题。2.2 依赖安装与虚拟环境三条命令搞定隔离网络测量类项目通常依赖 scapy、pandas、numpy、matplotlib 这几个库有的还会用到 dpkt 或 pyshark。pyshark 依赖本机安装抓包工具跨平台最容易出问题所以如果源码里用了 pyshark优先确认本机是否已装好对应底层工具。我一般用虚拟环境隔离避免污染全局# 创建并激活虚拟环境 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装依赖建议加国内镜像加速 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple # 验证关键库版本 python -c import scapy, pandas, numpy; print(scapy.__version__, pandas.__version__)逻辑说明虚拟环境是为了让这份课程设计的依赖和你机器上其他项目互不干扰。参数说明-i后面是镜像地址网络不通时换一个即可如果requirements.txt里没锁版本建议手动把 scapy 锁到 2.5.x 这类稳定版本避免新版 API 变动导致解析报错。验证那一步很关键能提前暴露装了但导入失败的情况比跑到一半崩掉强。2.3 用示例数据跑通最小闭环环境好了之后不要一上来就跑全量数据。先用data/sample.pcap这种小样本跑通采集→特征→指标→输出的最小闭环# 用示例 pcap 跑完整流程输出到 results 目录 python run.py --input data/sample.pcap --config config/settings.yaml --output results/ # 如果入口支持分步执行先只跑特征提取 python run.py --input data/sample.pcap --stage features --output results/features.csv逻辑说明--input指定输入流量文件--config指定参数配置--output指定结果目录。参数说明--stage这类分步参数不是每个项目都有如果没有就老老实实跑全流程但要把输出目录清空再跑避免旧结果干扰判断。跑完后重点看三样东西控制台有没有异常堆栈、results/下有没有生成文件、生成的文件行数是否和样本规模匹配。这三样都对说明最小闭环通了再换真实数据。3. 拆开测量核心时延、丢包、流特征是怎么算出来的3.1 时延与丢包时间戳和序列号才是命根子网络测量里最基础的两个指标就是时延和丢包但很多人算出来的结果自己都不敢信问题几乎都出在时间戳和序列号的处理上。时延的本质是两个事件的时间差在抓包场景里就是同一流中请求包和响应包的时间戳之差。丢包则依赖序列号连续性判断如果序列号出现跳变中间缺失的包数就是丢包数。import pandas as pd def compute_rtt(df): 按流计算往返时延df 需包含 flow_id, timestamp, direction 列 rtts [] for flow_id, group in df.groupby(flow_id): group group.sort_values(timestamp) # 请求包记为 req响应包记为 resp配对计算时间差 reqs group[group[direction] req][timestamp].values resps group[group[direction] resp][timestamp].values # 简化配对按顺序一一对应实际项目需按序列号匹配 for r, s in zip(reqs, resps): if s r: rtts.append({flow_id: flow_id, rtt_ms: (s - r) * 1000}) return pd.DataFrame(rtts) def compute_loss(df): 按流统计丢包基于序列号跳变 loss_stats [] for flow_id, group in df.groupby(flow_id): seqs sorted(group[seq].dropna().unique()) if len(seqs) 2: continue expected seqs[-1] - seqs[0] 1 lost expected - len(seqs) loss_stats.append({ flow_id: flow_id, expected: expected, received: len(seqs), lost: max(lost, 0), loss_rate: max(lost, 0) / expected if expected else 0 }) return pd.DataFrame(loss_stats)逻辑说明compute_rtt按流分组后排序把请求和响应时间戳配对求差compute_loss用序列号范围减去实际收到的唯一序列号数量估算丢包。参数说明timestamp单位要统一抓包工具一般给的是秒级浮点乘 1000 转毫秒seq列如果被截断或回绕需要先做归一化处理否则丢包率会算成负数或异常大。这两个函数是课程设计里最该自己重写一遍的部分因为不同数据源的字段名和格式差异很大照抄往往跑不通。3.2 流特征提取五元组聚合与统计量选择流特征提取是把原始包聚合成流再算统计量的过程。五元组源 IP、源端口、目的 IP、目的端口、协议是最常用的流标识。聚合之后常见的统计特征包括包数量、字节总数、平均包长、包长方差、流持续时间、包到达间隔的均值和标准差。这些特征直接决定后续分析比如分类或异常检测的上限。def extract_flow_features(df): 按五元组聚合提取基础流特征 df[flow_id] ( df[src_ip] - df[src_port].astype(str) - df[dst_ip] - df[dst_port].astype(str) - df[protocol].astype(str) ) features df.groupby(flow_id).agg( pkt_count(length, count), byte_total(length, sum), pkt_len_mean(length, mean), pkt_len_std(length, std), duration(timestamp, lambda x: x.max() - x.min()), ).reset_index() # 包到达间隔统计 features[iat_mean] df.groupby(flow_id)[timestamp].apply( lambda x: x.sort_values().diff().mean() ).values return features逻辑说明先构造flow_id再用groupby聚合出包数、字节数、包长均值方差和流持续时间最后单独算到达间隔均值。参数说明pkt_len_std在单包流上会是 NaN需要填充为 0duration对单包流也是 0属于正常现象。这里最容易踩的坑是端口字段类型不统一有的数据源端口是字符串有的是整数拼接前必须统一成字符串否则同一个流会被拆成多个。3.3 指标计算与结果校验别让单位把你坑了指标算完一定要做校验否则报告里的数字看着漂亮实际全是错的。校验的核心是量纲一致性和边界合理性。时延单位是毫秒还是秒带宽单位是 Mbps 还是 MB/s丢包率是 0 到 1 还是百分比这些必须在配置里写死并在输出时标注。边界合理性则是看结果有没有明显违背常识的值比如时延为负、丢包率大于 1、流持续时间为负。指标常见单位合理范围校验方法往返时延毫秒0.1 ~ 数千检查是否有负值丢包率0~10 ~ 1检查是否越界流持续时间秒≥ 0检查单包流是否为 0平均包长字节40 ~ 1500检查是否超 MTU到达间隔毫秒≥ 0检查排序后 diff这张表建议直接放进课程设计的校验模块里每次跑完自动检查一遍。我见过太多人因为时延单位没换算把 0.05 秒写成 0.05 毫秒结论直接反了。校验不通过就停下来查数据源别硬着头皮往下写报告。4. 避坑与排查课程设计里最容易翻车的五件事4.1 抓包权限不足导致采集为空现象程序不报错但采集到的包数量为 0输出文件是空的。原因抓包需要管理员或 root 权限普通用户运行时底层库静默失败。解决Linux 下用sudo运行或给抓包工具设置 capabilitiesWindows 下用管理员身份打开终端。运行说明里如果没提权限这几乎是必踩的坑。4.2 时间戳精度不一致导致时延算错现象时延结果忽大忽小甚至出现负值。原因不同数据源时间戳精度不同有的到微秒有的到秒混用后差值失真。解决统一转成同一精度再计算建议全部转成毫秒浮点配对前先按时间戳排序确保请求在前响应在后。4.3 序列号回绕导致丢包率异常现象丢包率算出大于 1 或负数。原因TCP 序列号是 32 位超过上限会回绕直接做减法会得到错误结果。解决检测到序列号突然大幅下降时按回绕处理加上 2^32 再计算差值或者直接用抓包工具自带的丢包统计做交叉验证。4.4 大文件一次性读入内存直接 OOM现象跑真实流量时进程被系统杀掉。原因把整个 pcap 一次性读进内存几百 MB 以上就撑不住。解决分块读取按流或按时间窗口处理pandas 可以用chunksize参数分块scapy 可以用PcapReader逐包迭代。课程设计的示例数据小但换成真实数据必须改。4.5 配置路径写死导致换机器就跑不起来现象在自己机器上好好的换台机器就报文件找不到。原因配置里用了绝对路径。解决全部改成相对路径以项目根目录为基准或者在入口处动态计算项目根目录配置里只写相对位置。这个坑在交作业和答辩换机器时特别致命。5. 从跑通到改出花把课程设计变成你自己的测量工具跑通只是起点真正让这份课程设计有价值的是你能改它。我一般会从三个方向动手换数据源、加指标、做对比。换数据源是最快建立手感的方式把示例 pcap 换成你自己抓的一段流量观察哪些字段对不上、哪些函数需要改这个过程比读十遍代码都管用。加指标则是检验你是否真懂测量比如在现有基础上加一个流突发度指标用到达间隔的标准差除以均值看能不能区分交互式流量和批量传输。def burstiness(df): 计算流突发度到达间隔标准差 / 均值 result [] for flow_id, group in df.groupby(flow_id): iats group.sort_values(timestamp)[timestamp].diff().dropna() if len(iats) 2 or iats.mean() 0: continue result.append({ flow_id: flow_id, burstiness: iats.std() / iats.mean() }) return pd.DataFrame(result)逻辑说明突发度越大说明包到达越不均匀交互式流量通常突发度高批量传输突发度低。参数说明样本太少少于 2 个间隔时跳过避免除零和统计不可靠。这个指标加进去之后你可以拿它和包长均值做散点图往往能看出不同应用类型的聚类趋势这就是课程设计里设计二字的落点。验证方法上我习惯做两件事一是用同一份数据跑两次确认结果完全一致排除随机性二是手动挑几条流用抓包工具自带的统计功能对一遍时延和丢包确认自己的计算没有系统性偏差。这两步做完你对自己写的测量代码才有底气。最后一个具体技巧把每次运行的配置、数据源和结果摘要写进一个run_log.csv时间久了你会发现排查问题时最值钱的就是这份日志。我自己做这类课程设计最大的教训是别等到报告写完才回头验证代码边写边用最小样本验证每加一个指标就手动核对一条流。这个习惯让我少熬了很多夜。希望帮到你。本文还有配套的精品资源点击获取