简介这份资源是东南大学网络安全学院网络测量课程设计的完整资料包面向正在修读网络测量、网络性能分析相关课程的高校学生以及希望动手实践流量采集与协议解析的自学者。内容围绕TCP/IP协议栈理解、数据包捕获与预处理、流量模式识别、延迟与丢包率等性能指标评估展开并配有源码与运行说明便于将课堂理论落到可运行的实验环境中。压缩包为zip格式整体约17.4MB内含源码与说明文档等文件源码可用于阅读网络测量工具的实现逻辑运行说明则指导编译、执行与结果解读。目前已有142人学习下载适合需要完成课程设计、复盘实验流程或补充网络测量实操经验的学习者参考也可作为网络管理、安全分析方向入门练习的素材。1. 网络测量课程设计到底在测什么从一份课程交付物说起很多人第一次接触“网络测量课程设计”时脑子里浮现的是 Wireshark 抓包、看几个 TCP 握手然后写一份实验报告。但真正做过一轮完整交付的人会知道这件事的核心不是“抓包”而是把网络行为变成可复现的数字。你拿到一份包含源码和运行说明的课程设计压缩包里面大概率是一套从流量采集、特征提取、指标计算到结果可视化的完整链路。它解决的不是“网络通不通”而是“网络在什么条件下表现如何、瓶颈在哪、如何用数据证明”。这类课程设计适合两类人一是网络方向的学生需要一套能跑通、能改参数、能写进报告的测量框架二是刚转网络工程或运维的从业者想用一个小型可控环境理解延迟、丢包、抖动、带宽这些指标是怎么被算出来的。标题里的“网络测量”不是玄学它有一套成熟的方法论主动测量与被动测量、端到端与逐跳、时间戳精度与时钟同步。课程设计通常选其中一条路径做深而不是全铺开。我见过太多人把这类压缩包解压后直接找main.py跑结果报错就卡住然后开始怀疑环境。其实课程设计的运行说明往往假设了一个特定拓扑或依赖版本跳过“测量目标定义”这一步后面全是坑。所以下面不急着贴代码先把测量对象、指标定义和最小可运行环境讲清楚再进入源码结构和参数调优。2. 先定测量目标再写代码主动与被动测量的选型逻辑2.1 为什么课程设计通常从主动测量入手主动测量是你主动发包去探测网络比如 ICMP、TCP SYN、UDP 探测包。它的好处是可控你能决定发包频率、包大小、探测目标也能在单机环境下模拟出可重复的结果。被动测量则是镜像流量或抓包后分析更贴近真实业务但对课程设计来说抓包点、权限、流量量级都容易失控。常见做法是课程设计以主动测量为主干被动测量作为对比验证。选主动测量还有一个现实原因你不需要在路由器或交换机上配镜像口也不需要 root 权限去抓全量包。一个普通用户权限的 Python 脚本就能发 UDP 包并记录往返时间。但主动测量有个天然缺陷探测包本身会改变网络状态尤其是高频探测会引入额外排队延迟。所以参数设置里发包间隔和超时时间必须一起调不能只改一个。2.2 延迟、丢包、抖动、带宽四个指标的计算口径延迟通常指往返时间 RTT单位毫秒。计算方式是发送时间戳与接收时间戳之差。注意如果用的是应用层时间戳要确保发送和接收在同一时钟域否则单机测试没问题跨机就会引入时钟偏移。丢包率是“未收到响应的探测包数 / 总发送包数”但超时判定直接影响丢包率——超时设太短会把高延迟误判为丢包设太长测试时间拉长。抖动是 RTT 的变化程度常见算法是相邻 RTT 差值的绝对值平均或者 RFC 3550 里的平滑抖动。带宽测量更复杂课程设计里通常用包对技术或递增包大小找拐点但精度有限。下面这张表是我在课程设计中常用的指标定义与参数范围可以直接对照源码里的计算模块。指标计算口径典型参数范围常见误用RTT接收时间戳 - 发送时间戳超时 1s间隔 0.2s用 time.time() 跨机比较丢包率超时包数 / 总包数超时 1s连续 3 次超时算丢超时设 100ms 导致误判抖动相邻 RTT 差绝对值平均取最近 20 个样本用全体样本导致早期噪声带宽包对离散度或递增包大小包大小 64~1400 字节忽略链路层开销提示如果源码里用的是time.time()而不是time.perf_counter()在 Windows 上精度可能只有 15ms 左右测出来的 RTT 会明显偏大。改成perf_counter是最低成本的修正。2.3 最小可运行环境Python 版本、依赖和权限课程设计的运行说明一般会写 Python 3.8但实际依赖可能锁在某个旧版本。我一般会先建虚拟环境再按requirements.txt装不要直接全局 pip。如果源码里用了scapy在 Windows 上需要装 Npcap且要以管理员权限运行如果只用socket和statistics普通权限就够。下面这段命令是我在拿到任何课程设计压缩包后的标准起手式先确认环境再跑主程序。# 创建隔离环境避免污染全局包 python -m venv venv # Windows 激活 venv\Scripts\activate # Linux/macOS 激活 source venv/bin/activate # 先看依赖清单再安装不要盲目 pip install -r type requirements.txt # Windows cat requirements.txt # Linux/macOS # 安装依赖如果网络慢可以换国内镜像源 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple逻辑说明虚拟环境能避免课程设计依赖和你现有项目冲突。先查看requirements.txt是为了确认有没有scapy这类需要系统级依赖的包。参数说明-i指定镜像源只影响下载速度不影响包内容。如果安装scapy失败先检查 Npcap 是否安装而不是反复重装 Python。3. 源码结构拆解从入口脚本到结果输出3.1 典型目录布局与模块职责一份完整的网络测量课程设计源码目录通常长这样main.py或run.py是入口config.py或settings.ini放参数measure/下分sender.py、receiver.py、analyzer.pyoutput/存 CSV 或图表。运行说明里会写“先运行 receiver 再运行 sender”这是因为主动测量需要一端收包。如果只有单机源码可能用本地回环或模拟延迟。我拿到压缩包后不会直接跑main.py而是先看config里的默认目标地址和端口。很多课程设计默认目标是某个公网地址或校园网内地址你本地跑不通不是代码问题是目标不可达。改成127.0.0.1或局域网内另一台机器先让链路通起来再改参数做实验。3.2 入口脚本的参数解析与默认值陷阱入口脚本一般用argparse接收参数比如--target、--count、--interval、--timeout。默认值往往是为了演示设的比如count10、interval1跑一次很快但统计意义弱。做课程设计报告时至少要把count提到 100 以上interval根据网络稳定度调。下面是一个典型的参数解析片段我加了注释说明每个参数的实际影响。import argparse def parse_args(): parser argparse.ArgumentParser(description网络测量课程设计入口) # 目标地址默认值通常是示例地址必须改成实际可达地址 parser.add_argument(--target, default127.0.0.1, help探测目标 IP 或域名) # 探测次数默认 10 次太少统计抖动至少 50 次 parser.add_argument(--count, typeint, default10, help发送探测包数量) # 发包间隔单位秒间隔太小会引入自排队延迟 parser.add_argument(--interval, typefloat, default1.0, help发包间隔) # 超时时间单位秒跨公网建议 1~2 秒局域网 0.5 秒 parser.add_argument(--timeout, typefloat, default1.0, help单包超时) # 输出文件默认写到 output/result.csv parser.add_argument(--output, defaultoutput/result.csv, help结果输出路径) return parser.parse_args()逻辑说明argparse把命令行参数转成对象后续模块直接读。参数说明--count影响统计置信度--interval影响测量对网络的干扰程度--timeout影响丢包判定。如果源码里没有--interval说明它用固定 sleep你需要手动在发送循环里加。3.3 发送端与接收端的时间戳对齐主动测量最容易被忽略的是时间戳对齐。如果发送端和接收端是两台机器发送时间戳在 A 机器接收时间戳在 B 机器两者时钟不同步RTT 就不可信。课程设计里常见做法是接收端收到包后立刻回显发送端计算 RTT这样时间戳都在发送端避免跨机时钟问题。下面这段代码展示了发送端如何记录发送时间并计算 RTT。import socket import time def measure_rtt(target, port, count, interval, timeout): results [] sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(timeout) for i in range(count): # 用 perf_counter 获得高精度单调时钟 send_ts time.perf_counter() try: sock.sendto(bping, (target, port)) # 接收回显recvfrom 返回数据和地址 data, addr sock.recvfrom(1024) recv_ts time.perf_counter() rtt (recv_ts - send_ts) * 1000 # 转毫秒 results.append(rtt) except socket.timeout: # 超时记为 None后续统计丢包率 results.append(None) time.sleep(interval) sock.close() return results逻辑说明perf_counter是单调时钟不受系统时间调整影响适合测间隔。sendto发 UDP 包recvfrom收回显。参数说明timeout控制单包等待上限interval控制发包节奏。如果接收端没有回显recvfrom会一直等到超时所以接收端脚本必须先跑起来。4. 跑通之后怎么调参让测量结果能写进报告4.1 发包间隔与超时时间的联动调整很多人调参是单独改interval或timeout结果要么丢包率虚高要么测试时间太长。正确做法是联动局域网 RTT 通常小于 1mstimeout设 0.5s 足够跨公网 RTT 可能 50~200mstimeout设 1~2s。interval至少是timeout的 1.5 倍否则上一个包还没超时下一个包就发出去了统计会乱。我一般先用count20、interval1、timeout1做一轮预跑看 RTT 分布再决定正式参数。如果源码里用的是固定sleep(1)你可以把它改成读args.interval。改完之后用同一目标跑两组不同interval的数据对比平均 RTT 和抖动。通常interval从 0.2 提到 1.0平均 RTT 会下降因为自排队减少了。这个对比本身就是课程设计报告里很好的分析素材。4.2 结果文件格式与可视化前的清洗课程设计输出一般是 CSV列包括seq、rtt_ms、timeout。拿到 CSV 后不要直接画图先清洗把timeout为 True 的行单独统计丢包率RTT 列里的空值或 -1 要剔除。下面这段 Python 用pandas做基础清洗和统计输出丢包率、平均 RTT、抖动。import pandas as pd # 读取测量结果假设列名为 seq, rtt_ms, timeout df pd.read_csv(output/result.csv) # 丢包率timeout 为 True 或 rtt_ms 为空都算丢包 lost df[(df[timeout] True) | (df[rtt_ms].isna())] loss_rate len(lost) / len(df) # 有效 RTT 样本 valid df[df[rtt_ms].notna() (df[timeout] False)] avg_rtt valid[rtt_ms].mean() # 抖动相邻有效 RTT 差值的绝对值平均 jitter valid[rtt_ms].diff().abs().mean() print(f丢包率: {loss_rate:.2%}) print(f平均 RTT: {avg_rtt:.2f} ms) print(f抖动: {jitter:.2f} ms)逻辑说明pandas按条件过滤diff()算相邻差值。参数说明loss_rate的分母是总包数不是有效包数这样才符合丢包率定义。如果源码输出的列名不同改列名即可不要改计算逻辑。4.3 用对比实验验证测量稳定性单次测量没有说服力。我一般会做三组对比同一目标不同时间跑三次看平均 RTT 波动同一时间不同interval跑两次看自排队影响同一目标不同包大小跑两次看传输延迟变化。这三组数据放进报告比只贴一张图更有说服力。如果三次平均 RTT 差异超过 20%说明网络本身不稳定或者你的count太小需要增加样本量。注意如果三次测量中有一组丢包率突然飙高先检查目标机器是否在跑其他大流量任务而不是急着改代码。测量结果受环境影响很大控制变量比调参更重要。5. 避坑与排查课程设计里最容易翻车的五个点5.1 现象脚本报 Permission denied 或 socket 权限错误原因源码用了原始套接字raw socket或scapy的sr1这类操作需要管理员/root 权限。解决Windows 下用管理员身份运行终端Linux 下用sudo或者改用普通 UDP socket 的测量方式。如果课程设计必须用原始套接字运行说明里通常会写没写就是坑。5.2 现象接收端收不到包发送端全部超时原因目标地址不可达、端口没监听、防火墙拦截。解决先用ping或telnet确认目标可达再确认接收端脚本已启动并绑定正确端口。Windows 防火墙默认会拦入站 UDP临时关闭或加规则。如果是在同一台机器测试目标写127.0.0.1不要写本机公网 IP。5.3 现象RTT 数值异常大动辄几百毫秒原因用了time.time()而不是perf_counter()或者跨机时钟不同步。解决统一用perf_counter并确保 RTT 计算在发送端完成。如果源码在接收端算 RTT需要先做时钟同步课程设计里不推荐。5.4 现象丢包率 0% 但抖动极大原因超时时间设得太长高延迟包被当成正常包收下但 RTT 波动大。解决把timeout降到合理范围比如局域网 0.2s公网 1s重新跑。抖动大也可能是网络本身拥塞换时间段再测。5.5 现象CSV 结果列对不上画图报错原因源码版本和运行说明不一致或者输出格式被手动改过。解决先看output/下实际生成的 CSV 头一行按实际列名改清洗脚本不要硬套示例。如果列名是中文注意编码用utf-8-sig读取。6. 进阶技巧把课程设计变成可复用的测量小工具跑通课程设计只是起点。我习惯把源码里的发送、接收、统计三个模块拆成独立函数再加一个命令行入口这样下次测别的目标不用改代码只改参数。具体做法把measure_rtt抽到probe.py把清洗统计抽到analyze.py入口用argparse串起来。这样你手里就有一个最小可用的网络测量工具而不是一份只能跑一次的作业。另一个技巧是加时间序列输出。课程设计通常只给汇总值但把每次探测的 RTT 按序号写成时间序列能看出网络抖动的周期性。下面这段代码在原有 CSV 基础上增加一列timestamp方便后续画时序图。import csv import time # 在发送循环里记录每次探测的绝对时间 with open(output/result_ts.csv, w, newline) as f: writer csv.writer(f) writer.writerow([seq, timestamp, rtt_ms, timeout]) for i in range(count): send_ts time.perf_counter() wall_ts time.time() # 绝对时间用于对齐外部事件 # ... 发送和接收逻辑同上 ... writer.writerow([i, wall_ts, rtt, is_timeout])逻辑说明wall_ts是绝对时间用来和系统日志或其他监控对齐rtt_ms仍是perf_counter差值。参数说明newline防止 Windows 下多空行。有了时间序列你可以观察 RTT 是否在某个时间段集中升高从而判断是网络拥塞还是目标机器负载问题。最后一个习惯每次测量前先跑一轮count5的预热把预热数据丢掉。因为第一次发包可能触发 ARP 解析或路由缓存未命中RTT 会偏高。预热之后的数据更稳定报告里也更好解释。这个习惯帮我省掉了很多“为什么第一包特别慢”的疑问。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/10 12:26:09 · 阅读 1.2k 网络测量课程设计实战：从抓包到可复现数字的完整链路
简介这份资源是东南大学网络安全学院网络测量课程设计的完整资料包面向正在修读网络测量、网络性能分析相关课程的高校学生以及希望动手实践流量采集与协议解析的自学者。内容围绕TCP/IP协议栈理解、数据包捕获与预处理、流量模式识别、延迟与丢包率等性能指标评估展开并配有源码与运行说明便于将课堂理论落到可运行的实验环境中。压缩包为zip格式整体约17.4MB内含源码与说明文档等文件源码可用于阅读网络测量工具的实现逻辑运行说明则指导编译、执行与结果解读。目前已有142人学习下载适合需要完成课程设计、复盘实验流程或补充网络测量实操经验的学习者参考也可作为网络管理、安全分析方向入门练习的素材。1. 网络测量课程设计到底在测什么从一份课程交付物说起很多人第一次接触“网络测量课程设计”时脑子里浮现的是 Wireshark 抓包、看几个 TCP 握手然后写一份实验报告。但真正做过一轮完整交付的人会知道这件事的核心不是“抓包”而是把网络行为变成可复现的数字。你拿到一份包含源码和运行说明的课程设计压缩包里面大概率是一套从流量采集、特征提取、指标计算到结果可视化的完整链路。它解决的不是“网络通不通”而是“网络在什么条件下表现如何、瓶颈在哪、如何用数据证明”。这类课程设计适合两类人一是网络方向的学生需要一套能跑通、能改参数、能写进报告的测量框架二是刚转网络工程或运维的从业者想用一个小型可控环境理解延迟、丢包、抖动、带宽这些指标是怎么被算出来的。标题里的“网络测量”不是玄学它有一套成熟的方法论主动测量与被动测量、端到端与逐跳、时间戳精度与时钟同步。课程设计通常选其中一条路径做深而不是全铺开。我见过太多人把这类压缩包解压后直接找main.py跑结果报错就卡住然后开始怀疑环境。其实课程设计的运行说明往往假设了一个特定拓扑或依赖版本跳过“测量目标定义”这一步后面全是坑。所以下面不急着贴代码先把测量对象、指标定义和最小可运行环境讲清楚再进入源码结构和参数调优。2. 先定测量目标再写代码主动与被动测量的选型逻辑2.1 为什么课程设计通常从主动测量入手主动测量是你主动发包去探测网络比如 ICMP、TCP SYN、UDP 探测包。它的好处是可控你能决定发包频率、包大小、探测目标也能在单机环境下模拟出可重复的结果。被动测量则是镜像流量或抓包后分析更贴近真实业务但对课程设计来说抓包点、权限、流量量级都容易失控。常见做法是课程设计以主动测量为主干被动测量作为对比验证。选主动测量还有一个现实原因你不需要在路由器或交换机上配镜像口也不需要 root 权限去抓全量包。一个普通用户权限的 Python 脚本就能发 UDP 包并记录往返时间。但主动测量有个天然缺陷探测包本身会改变网络状态尤其是高频探测会引入额外排队延迟。所以参数设置里发包间隔和超时时间必须一起调不能只改一个。2.2 延迟、丢包、抖动、带宽四个指标的计算口径延迟通常指往返时间 RTT单位毫秒。计算方式是发送时间戳与接收时间戳之差。注意如果用的是应用层时间戳要确保发送和接收在同一时钟域否则单机测试没问题跨机就会引入时钟偏移。丢包率是“未收到响应的探测包数 / 总发送包数”但超时判定直接影响丢包率——超时设太短会把高延迟误判为丢包设太长测试时间拉长。抖动是 RTT 的变化程度常见算法是相邻 RTT 差值的绝对值平均或者 RFC 3550 里的平滑抖动。带宽测量更复杂课程设计里通常用包对技术或递增包大小找拐点但精度有限。下面这张表是我在课程设计中常用的指标定义与参数范围可以直接对照源码里的计算模块。指标计算口径典型参数范围常见误用RTT接收时间戳 - 发送时间戳超时 1s间隔 0.2s用 time.time() 跨机比较丢包率超时包数 / 总包数超时 1s连续 3 次超时算丢超时设 100ms 导致误判抖动相邻 RTT 差绝对值平均取最近 20 个样本用全体样本导致早期噪声带宽包对离散度或递增包大小包大小 64~1400 字节忽略链路层开销提示如果源码里用的是time.time()而不是time.perf_counter()在 Windows 上精度可能只有 15ms 左右测出来的 RTT 会明显偏大。改成perf_counter是最低成本的修正。2.3 最小可运行环境Python 版本、依赖和权限课程设计的运行说明一般会写 Python 3.8但实际依赖可能锁在某个旧版本。我一般会先建虚拟环境再按requirements.txt装不要直接全局 pip。如果源码里用了scapy在 Windows 上需要装 Npcap且要以管理员权限运行如果只用socket和statistics普通权限就够。下面这段命令是我在拿到任何课程设计压缩包后的标准起手式先确认环境再跑主程序。# 创建隔离环境避免污染全局包 python -m venv venv # Windows 激活 venv\Scripts\activate # Linux/macOS 激活 source venv/bin/activate # 先看依赖清单再安装不要盲目 pip install -r type requirements.txt # Windows cat requirements.txt # Linux/macOS # 安装依赖如果网络慢可以换国内镜像源 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple逻辑说明虚拟环境能避免课程设计依赖和你现有项目冲突。先查看requirements.txt是为了确认有没有scapy这类需要系统级依赖的包。参数说明-i指定镜像源只影响下载速度不影响包内容。如果安装scapy失败先检查 Npcap 是否安装而不是反复重装 Python。3. 源码结构拆解从入口脚本到结果输出3.1 典型目录布局与模块职责一份完整的网络测量课程设计源码目录通常长这样main.py或run.py是入口config.py或settings.ini放参数measure/下分sender.py、receiver.py、analyzer.pyoutput/存 CSV 或图表。运行说明里会写“先运行 receiver 再运行 sender”这是因为主动测量需要一端收包。如果只有单机源码可能用本地回环或模拟延迟。我拿到压缩包后不会直接跑main.py而是先看config里的默认目标地址和端口。很多课程设计默认目标是某个公网地址或校园网内地址你本地跑不通不是代码问题是目标不可达。改成127.0.0.1或局域网内另一台机器先让链路通起来再改参数做实验。3.2 入口脚本的参数解析与默认值陷阱入口脚本一般用argparse接收参数比如--target、--count、--interval、--timeout。默认值往往是为了演示设的比如count10、interval1跑一次很快但统计意义弱。做课程设计报告时至少要把count提到 100 以上interval根据网络稳定度调。下面是一个典型的参数解析片段我加了注释说明每个参数的实际影响。import argparse def parse_args(): parser argparse.ArgumentParser(description网络测量课程设计入口) # 目标地址默认值通常是示例地址必须改成实际可达地址 parser.add_argument(--target, default127.0.0.1, help探测目标 IP 或域名) # 探测次数默认 10 次太少统计抖动至少 50 次 parser.add_argument(--count, typeint, default10, help发送探测包数量) # 发包间隔单位秒间隔太小会引入自排队延迟 parser.add_argument(--interval, typefloat, default1.0, help发包间隔) # 超时时间单位秒跨公网建议 1~2 秒局域网 0.5 秒 parser.add_argument(--timeout, typefloat, default1.0, help单包超时) # 输出文件默认写到 output/result.csv parser.add_argument(--output, defaultoutput/result.csv, help结果输出路径) return parser.parse_args()逻辑说明argparse把命令行参数转成对象后续模块直接读。参数说明--count影响统计置信度--interval影响测量对网络的干扰程度--timeout影响丢包判定。如果源码里没有--interval说明它用固定 sleep你需要手动在发送循环里加。3.3 发送端与接收端的时间戳对齐主动测量最容易被忽略的是时间戳对齐。如果发送端和接收端是两台机器发送时间戳在 A 机器接收时间戳在 B 机器两者时钟不同步RTT 就不可信。课程设计里常见做法是接收端收到包后立刻回显发送端计算 RTT这样时间戳都在发送端避免跨机时钟问题。下面这段代码展示了发送端如何记录发送时间并计算 RTT。import socket import time def measure_rtt(target, port, count, interval, timeout): results [] sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(timeout) for i in range(count): # 用 perf_counter 获得高精度单调时钟 send_ts time.perf_counter() try: sock.sendto(bping, (target, port)) # 接收回显recvfrom 返回数据和地址 data, addr sock.recvfrom(1024) recv_ts time.perf_counter() rtt (recv_ts - send_ts) * 1000 # 转毫秒 results.append(rtt) except socket.timeout: # 超时记为 None后续统计丢包率 results.append(None) time.sleep(interval) sock.close() return results逻辑说明perf_counter是单调时钟不受系统时间调整影响适合测间隔。sendto发 UDP 包recvfrom收回显。参数说明timeout控制单包等待上限interval控制发包节奏。如果接收端没有回显recvfrom会一直等到超时所以接收端脚本必须先跑起来。4. 跑通之后怎么调参让测量结果能写进报告4.1 发包间隔与超时时间的联动调整很多人调参是单独改interval或timeout结果要么丢包率虚高要么测试时间太长。正确做法是联动局域网 RTT 通常小于 1mstimeout设 0.5s 足够跨公网 RTT 可能 50~200mstimeout设 1~2s。interval至少是timeout的 1.5 倍否则上一个包还没超时下一个包就发出去了统计会乱。我一般先用count20、interval1、timeout1做一轮预跑看 RTT 分布再决定正式参数。如果源码里用的是固定sleep(1)你可以把它改成读args.interval。改完之后用同一目标跑两组不同interval的数据对比平均 RTT 和抖动。通常interval从 0.2 提到 1.0平均 RTT 会下降因为自排队减少了。这个对比本身就是课程设计报告里很好的分析素材。4.2 结果文件格式与可视化前的清洗课程设计输出一般是 CSV列包括seq、rtt_ms、timeout。拿到 CSV 后不要直接画图先清洗把timeout为 True 的行单独统计丢包率RTT 列里的空值或 -1 要剔除。下面这段 Python 用pandas做基础清洗和统计输出丢包率、平均 RTT、抖动。import pandas as pd # 读取测量结果假设列名为 seq, rtt_ms, timeout df pd.read_csv(output/result.csv) # 丢包率timeout 为 True 或 rtt_ms 为空都算丢包 lost df[(df[timeout] True) | (df[rtt_ms].isna())] loss_rate len(lost) / len(df) # 有效 RTT 样本 valid df[df[rtt_ms].notna() (df[timeout] False)] avg_rtt valid[rtt_ms].mean() # 抖动相邻有效 RTT 差值的绝对值平均 jitter valid[rtt_ms].diff().abs().mean() print(f丢包率: {loss_rate:.2%}) print(f平均 RTT: {avg_rtt:.2f} ms) print(f抖动: {jitter:.2f} ms)逻辑说明pandas按条件过滤diff()算相邻差值。参数说明loss_rate的分母是总包数不是有效包数这样才符合丢包率定义。如果源码输出的列名不同改列名即可不要改计算逻辑。4.3 用对比实验验证测量稳定性单次测量没有说服力。我一般会做三组对比同一目标不同时间跑三次看平均 RTT 波动同一时间不同interval跑两次看自排队影响同一目标不同包大小跑两次看传输延迟变化。这三组数据放进报告比只贴一张图更有说服力。如果三次平均 RTT 差异超过 20%说明网络本身不稳定或者你的count太小需要增加样本量。注意如果三次测量中有一组丢包率突然飙高先检查目标机器是否在跑其他大流量任务而不是急着改代码。测量结果受环境影响很大控制变量比调参更重要。5. 避坑与排查课程设计里最容易翻车的五个点5.1 现象脚本报 Permission denied 或 socket 权限错误原因源码用了原始套接字raw socket或scapy的sr1这类操作需要管理员/root 权限。解决Windows 下用管理员身份运行终端Linux 下用sudo或者改用普通 UDP socket 的测量方式。如果课程设计必须用原始套接字运行说明里通常会写没写就是坑。5.2 现象接收端收不到包发送端全部超时原因目标地址不可达、端口没监听、防火墙拦截。解决先用ping或telnet确认目标可达再确认接收端脚本已启动并绑定正确端口。Windows 防火墙默认会拦入站 UDP临时关闭或加规则。如果是在同一台机器测试目标写127.0.0.1不要写本机公网 IP。5.3 现象RTT 数值异常大动辄几百毫秒原因用了time.time()而不是perf_counter()或者跨机时钟不同步。解决统一用perf_counter并确保 RTT 计算在发送端完成。如果源码在接收端算 RTT需要先做时钟同步课程设计里不推荐。5.4 现象丢包率 0% 但抖动极大原因超时时间设得太长高延迟包被当成正常包收下但 RTT 波动大。解决把timeout降到合理范围比如局域网 0.2s公网 1s重新跑。抖动大也可能是网络本身拥塞换时间段再测。5.5 现象CSV 结果列对不上画图报错原因源码版本和运行说明不一致或者输出格式被手动改过。解决先看output/下实际生成的 CSV 头一行按实际列名改清洗脚本不要硬套示例。如果列名是中文注意编码用utf-8-sig读取。6. 进阶技巧把课程设计变成可复用的测量小工具跑通课程设计只是起点。我习惯把源码里的发送、接收、统计三个模块拆成独立函数再加一个命令行入口这样下次测别的目标不用改代码只改参数。具体做法把measure_rtt抽到probe.py把清洗统计抽到analyze.py入口用argparse串起来。这样你手里就有一个最小可用的网络测量工具而不是一份只能跑一次的作业。另一个技巧是加时间序列输出。课程设计通常只给汇总值但把每次探测的 RTT 按序号写成时间序列能看出网络抖动的周期性。下面这段代码在原有 CSV 基础上增加一列timestamp方便后续画时序图。import csv import time # 在发送循环里记录每次探测的绝对时间 with open(output/result_ts.csv, w, newline) as f: writer csv.writer(f) writer.writerow([seq, timestamp, rtt_ms, timeout]) for i in range(count): send_ts time.perf_counter() wall_ts time.time() # 绝对时间用于对齐外部事件 # ... 发送和接收逻辑同上 ... writer.writerow([i, wall_ts, rtt, is_timeout])逻辑说明wall_ts是绝对时间用来和系统日志或其他监控对齐rtt_ms仍是perf_counter差值。参数说明newline防止 Windows 下多空行。有了时间序列你可以观察 RTT 是否在某个时间段集中升高从而判断是网络拥塞还是目标机器负载问题。最后一个习惯每次测量前先跑一轮count5的预热把预热数据丢掉。因为第一次发包可能触发 ARP 解析或路由缓存未命中RTT 会偏高。预热之后的数据更稳定报告里也更好解释。这个习惯帮我省掉了很多“为什么第一包特别慢”的疑问。希望帮到你。本文还有配套的精品资源点击获取