简介：一套基于SDN架构的网络流量监控与控制Python项目源码，面向网络工程、计算机等专业学生，适用于毕业设计、期末大作业和课程设计等场景，解决缺少可运行、可解释的高评分源码的痛点。代码注释覆盖关键逻辑，新手也能看懂并快速部署使用。资源包共2000个文件，以1838个Python源码文件为核心，承担监控采集与策略控制逻辑；另含C/C++扩展模块、JSON配置、HTML/JavaScript管理界面及说明文档等，整体约112.58MB，分类清晰，便于按模块阅读、调试与二次开发。目前已有387人学习下载，属于导师认可的高分项目。从中可获取流量监控、策略控制的可复用框架与代码实现，并借助注释理解SDN数据转发、规则下发等关键思路，能快速搭建实验环境，为完成高质量课程设计或毕业设计提供可靠参考。
1. SDN 网络流量监控与控制：为什么这套 Python 源码值得你花时间拆一遍
做毕业设计或者课程设计选 SDN 方向，最怕的不是看不懂论文，而是看完 OpenFlow 协议、看完控制器文档，打开电脑却不知道第一行代码该写在哪。这套基于 SDN 架构的网络流量监控和控制 Python 源码正好补上这段空白，代码注释写得很细，新手照着走能跑通，老手拿来做二次开发也有得挖。源码里还看到了 greenlet.c、corecext.c、queue.c 这类 C 扩展文件，这说明控制器的运行环境依赖较深，部署时有一个明显要留神的点。整体看下来，这套资源适合三类人：网络方向做毕业设计的学生、想快速搭一个流量监控演示系统的开发者、以及想理解 Ryu/OpenFlow 转发逻辑但不想从零啃协议的初学者。我拆完这套源码之后一个很直观的感受是，它把论文里的南向接口、流表下发、拓扑发现这些概念全部落到了能跑的代码上，值得照着敲一遍。
2. 先把环境装对：PyPy、Ryu 与 Mininet 的版本匹配关系
2.1 这套源码为什么依赖 PyPy 而不是默认的 CPython
看到项目文件里有 greenlet.c 和 corecext.c，我第一反应是这套源码的控制端跑在 PyPy 之上。PyPy 的 greenlet 模块比 CPython 原生实现更快，协程切换开销更小，而 SDN 控制器处理大量 packet-in 事件时恰恰需要高并发的事件循环。Ryu 控制器自身的事件模型就是基于 greenlet 的，所以项目作者选择了 PyPy 作为运行环境，这是从性能出发的合理选型。
环境搭建这块我踩过不少坑，先说最简单的路径。PyPy 建议装 7.3.x 版本，对应 Python 3.6 或者 3.9 的兼容层，Ryu 4.34 在这两个版本上都表现得很好。Mininet 用 2.3.0 以上版本就行，它主要负责创建虚拟网络拓扑，和 PyPy 没有直接依赖冲突。装 PyPy 的方式在 Linux 下很简单:
# Ubuntu 20.04/22.04 下安装 PyPy3 sudo apt update sudo apt install pypy3 # 验证版本 pypy3 --version装完之后检查一件事:pypy3和python3是否指向同一个环境。很多问题出在这个环节——pip 装包时装到了 CPython 的 site-packages 里，但运行源码时用的是 pypy3，导致导入 greelnet 直接报错。我一般会强制指定用 pypy3 的 pip 来装依赖，这样不会装错环境。
2.2 Ryu 控制器的依赖关系与安装顺序
Ryu 是这套源码的控制层核心，负责和 Mininet 里那些虚拟交换机通信。安装它的坑点在于依赖顺序——如果先装 Ryu 再装 PyPy 相关的 C 扩展，容易遇到编译错误。推荐的安装顺序是: 先确定 PyPy 环境可用，再装 Ryu 的依赖，最后装 Ryu 本身。
# 安装 Ryu 的基础依赖 pypy3 -m pip install six gevent greenlet # 安装 Ryu 控制器程序本身 pypy3 -m pip install ryu # 验证 Ryu 是否可以正常启动 pypy3 -m ryu.app.ryu_manager --version参数说明: 第二条命令里的ryu是 Ryu 的 Python 包名，装完以后命令行工具是ryu-manager，但通过pypy3 -m的方式调用可以避免 PATH 指向错误版本的问题。如果最后一条命令出现版本号，说明 Ryu 安装成功。如果报缺少lxml或者ncclient，单独补装即可。
提示: 不要用系统自带的 python3-pip 来装 Ryu，这会让控制器跑在 CPython 上，后续导入 greenlet 时会出现版本不匹配。项目正文里列出的那些 C 源文件，本质上是 PyPy 运行时的一部分，不是项目本身的业务代码。
3. 把监控和控制在代码里拆开看：从流表到可视化
3.1 packet-in 处理流程：控制器是怎么“看见”全网流量的
SDN 网络流量监控的设计逻辑，本质上就是围绕 OpenFlow 的 packet-in 消息做文章。交换机收到一个没有匹配流表项的报文时，会封装成 packet-in 发给控制器，控制器收到后决定是下发新流表规则，还是直接把报文丢弃或泛洪。这套源码里监控模块的入口就在这里。
核心代码文件里处理 packet-in 的逻辑大概长这样:
@set_ev_cls(ofp_event.EventOFPAsynPacketIn, MAIN_DISPATCHER) def packet_in_handler(self, ev): msg = ev.msg datapath = msg.datapath ofproto = datapath.ofproto parser = datapath.ofproto_parser # 从报文里解析出源 MAC、目的 MAC 和入端口编号 pkt = packet.Packet(msg.data) eth = pkt.get_protocols(ethernet.ethernet)[0] # 统计流量: 记录当前端口的收包数和字节数 dpid = datapath.id in_port = msg.match['in_port'] self.flow_stats[dpid][in_port]['packets'] += 1 self.flow_stats[dpid][in_port]['bytes'] += len(msg.data) # 如果没有匹配到流表规则，走默认的 flood 逻辑 actions = [parser.OFPActionOutput(ofproto.OFPP_FLOOD)] out = parser.OFPPacketOut( datapath=datapath, buffer_id=msg.buffer_id, in_port=in_port, actions=actions, data=msg.data ) datapath.send_msg(out)这段代码的几个关键点:msg.match['in_port']取到的是报文进入交换机时的物理端口，self.flow_stats是一份 Python 嵌套字典，用来按交换机和端口维度累计流量数据。这里没有做复杂的流表匹配逻辑，而是把监控信息的采集放在控制器这一侧，好处是你想接入 influxdb 或者其他时序数据库时，直接写这个字典就行。坏处是高流量下 CPU 占用会变大，不过对课程设计和毕设场景来说完全够用。
3.2 流表下发：从“监控”切到“控制”的分水岭
网络流量控制不是把某个端口关掉那么简单，它的核心思路是基于监控数据动态调整流表规则。这套源码里控制逻辑通过新增FlowMod消息来实现，举个例子: 当某个端口的流量超过设定的阈值，控制器下发新的流表项，把来自该端口的高带宽流量引导到预设的 QoS 队列。
def install_flow(self, datapath, priority, match, actions): ofproto = datapath.ofproto parser = datapath.ofproto_parser # 构造一个 FlowMod 消息 mod = parser.OFPFlowMod( datapath=datapath, priority=priority, match=match, instructions=[ parser.OFPInstructionActions( ofproto.OFPIT_APPLY_ACTIONS, actions ) ], buffer_id=ofproto.OFP_NO_BUFFER, idle_timeout=30, hard_timeout=0 ) datapath.send_msg(mod)参数含义要弄清楚:priority决定流表匹配顺序，数值越大越优先;idle_timeout=30表示这条流表 30 秒没有报文命中就自动删除;hard_timeout=0表示没有硬性过期时间。这个设计是有讲究的——监控类流表规则不该永久驻留，否则交换机流表会被占满，所以用短超时让不活跃的规则自动消失。实现控制逻辑时，只需要在监控阈值判断触发后组装 match 和 actions 传给install_flow，比如把某个 IP 段报文的 output 端口从 1 改成 3，就能实现路径切换。
3.3 Web 可视化层：不用写前端也能展示监控数据
不少 SDN 项目做到控制器下发流表就停住了，但毕设答辩老师通常会往“你怎么证明你的监控是有效的”这个方向提问。这套源码自带的 Web 可视化模块刚好能应对这个场景，它基于 Python 内置的 HTTP 服务把统计结果渲染成简单页面。
class FlowStatsHTTPHandler(BaseHTTPRequestHandler): def do_GET(self): # 从控制器实例里取流量统计数据 stats = self.server.app.flow_stats # 拼装 JSON 数据，供前端定时轮询 payload = json.dumps({ "switches": [ { "dpid": dpid, "ports": port_stats } for dpid, port_stats in stats.items() ] }, ensure_ascii=False).encode() self.send_response(200) self.send_header('Content-Type', 'application/json') self.send_header('Content-Length', str(len(payload))) self.end_headers() self.wfile.write(payload)这一段把flow_stats字典直接转成 JSON 输出，前端用 ECharts 定时请求这个接口就能画折线图或者拓扑图。源码包里带了一个极简的 HTML 页面，打开就是流量曲线。对 Python 开发者来说这个设计是最省事的方式——不需要引 Flask，标准库就能撑起一个演示级监控面板。想换 FastAPI 或者 Flask 的思路也很直接，把这段 handler 换成对应框架的路由即可。
4. Mininet 联动测试：从拓扑启动到流量回放
4.1 自定义拓扑脚本的启动参数与测试流程
跑这套源码，第一步是启动 Mininet 拓扑，第二步是启动 Ryu 控制器。两者之间的启动顺序有讲究——先后台拉起控制器，再创建拓扑，这样交换机启动后马上就能找到控制器并建立连接。
# 终端 1: 启动 Ryu 控制器 pypy3 -m ryu.app.ryu_manager ./sdn_monitor_controller.py --verbose # 终端 2: 启动 Mininet 拓扑 sudo mn --topo linear,3 --controller remote,ip=127.0.0.1 --switch ovsk,protocols=OpenFlow13两个参数需要特别解释:--controller remote,ip=127.0.0.1告诉 Mininet 交换机去连接本地控制器而不是自带的ovs-controller;protocols=OpenFlow13指定使用 OpenFlow 1.3 协议。源码里的控制器代码在初始化的set_ev_cls装饰器里监听了OFPStateChange事件，如果协议版本对不上，交换机连接建立会失败，但 Ryu 日志里未必有直观报错，只会看到HELLO协商失败后反复重连的现象。
4.2 用 hping3 和 iperf 制造真实流量验证监控效果
拓扑起来之后，下一步就是制造流量。很多同学会犯一个错误: 在 Mininet 的mininet>命令行里用pingall测一下通不通就算完了，这不叫流量监控验证。监控系统得看到可量化的数据变换，也就是用工具产生持续的 TCP/UDP 流量。
# 进入 mininet 交互后 h1 ping -c 4 h3 # 在 h1 上启动 TCP 流量打向 h3，持续 30 秒 h1 iperf -s -p 8080 & # 在 h2 上作为客户端发起连接 h3 iperf -c 10.0.0.1 -p 8080 -t 30 -i 5跑完这组命令以后，观察两个地方: 一是运行控制器的终端，Ryu 会打印出PACKET_IN的调试日志; 二是打开源码自带的 Web 监控页面，能看到 h1 对应端口的packets和bytes在上涨。这一步通了以后，你的监控链路就闭环了: Mininet 生成流量 → 交换机上报 packet-in → 控制器解析并统计 → Web 页面展示。
4.3 流量类型识别的进阶观察：ICMP 与 TCP 的差异化呈现
监控页面如果只显示流量大小，答辩时显得单薄。这套源码里对协议类型的解析还处于基础阶段，但可以顺手扩展成能区分 ICMP 和 TCP。在 packet-in 处理函数里增加对ipv4和tcp协议的判断，就能在统计数据里多记录一个protocol字段。
# 分别打两种流量做对比验证 h1 ping -c 20 h3 h3 iperf -c 10.0.0.1 -p 8080 -t 20这样操作的价值在于，答辩老师问“你的系统能不能识别不同流量类型”时，你给出来的不是口头承诺，而是两组流量下监控页面的差异化数据。这是拿高分的答辩展示思路。
5. 避坑清单：PyPy 兼容性与流表下发的高频翻车点
5.1 骗人的“安装成功”：pypy3 和 pip3 指向不一致
现象: 执行pypy3 -c "import ryu"或pypy3 -m ryu.app.ryu_manager时提示ModuleNotFoundError，但用python3试同一个命令却一切正常。
原因: 你安装 Ryu 时用的是pip3而不是pypy3 -m pip。系统的 pip3 绑定的是 CPython 解释器，安装的第三方包写进了 CPython 的 site-packages 目录。PyPy 启动后在自己的解释器路径里找不到这些包。
解决: 强制指定 PyPy 的包管理命令，整个环境的依赖都统一用这一条命令来装:
pypy3 -m pip install --user ryu pypy3 -c "import ryu; print(ryu.__version__)"装完后检查pypy3 -m pip list里是不是列出了 ryu，且这个命令的 prefix 路径包含site-packages/pypy3。
5.2 Ryu 日志疯狂刷 ERROR 但交换机拓扑没建立
现象: 控制器正常启动，日志里出现ERROR: *** Error: failed to receive echo reply或者交换机反复断开重连的消息，Mininet 里的pingall不通。
原因: Mininet 默认创建的 OVS 交换机使用 OpenFlow 1.0 协议，而控制器代码写了OFPFlowMod时用的是 1.3 版本的数据结构（例如OFPInstructionActions），协商失败后连接被交换机主动断开。
解决: 在 Mininet 启动命令里显式指定协议版本，并且尽量不要用sudo mn的默认参数:
sudo mn --topo tree,2 --controller remote,ip=127.0.0.1 --switch ovsk,protocols=OpenFlow13如果还不行，直接手动确认 OVS 交换机上的协议监听状态:
ovs-vsctl list-br sudo ovs-vsctl set Bridge s1 protocols=OpenFlow135.3 监控页面有数据但流量控制不生效
现象: Web 页面能看到端口流量在正常跳变，但设置了流量阈值之后，违反阈值的流量没有被重新路由或者丢包。
原因: 多数情况下是流表的优先级跟默认流表规则冲突导致的。默认OVS交换机里有一条priority=0的转发表规则，如果你的动态流表下发时priority低于或缺省，新规则永远不会被匹配到。
解决: 在控制器里显式把所有控制流的优先级设置不低于 1000，并在下发后验证流表确实写入成功:
sudo ovs-ofctl dump-flows s1 -O OpenFlow13检查输出里是否出现了priority=1000开头的新规则。流表没出现在列表里，就回头检查install_flow函数有没有被真正调用——常见原因是阈值判断的逻辑写在了事件回调里，但回调根本没有被触发。
5.4 C 扩展编译报错：greenlet.h 文件找不到
现象: 在 PyPy 环境安装 greenlet 或者启动控制器时，出现fatal error: greenlet.h: No such file or directory的编译错误。
原因: 这套源码依赖的 greenlet 是源码编译安装的，CPython 工具链在编译时会找 CPython 的头文件路径，但实际运行环境是 PyPy，头文件路径不兼容。还有一种情况是操作系统缺少 Python 的开发头文件包。
解决: 不要尝试手动编译 greenlet，直接用 PyPy 的预编译 wheel 包:
pypy3 -m pip install --only-binary :all: greenlet如果网络环境限制了--only-binary的获取，则安装 PyPy 对应的开发包:
sudo apt install pypy3-dev5.5 控制器重启后流表残留在 OVS 交换机里
现象: 修改了控制器代码后重启 Ryu，发现 Mininet 里的交换机还保留着上一次的流表项，新代码的逻辑没有生效。
原因: 重启 Ryu 控制器不会自动清除 OVS 交换机上的流表，交换机没断开连接就不会主动向控制器重新请求全量流表。
解决: 在每次启动控制器之前，先用命令清空交换机流表:
for br in `sudo ovs-vsctl list-br`; do sudo ovs-ofctl del-flows $br -O OpenFlow13 done也可以用 Mininet 的--clean参数在重启拓扑时一并清理残留:
sudo mn --clean6. 把监控数据接到时序数据库：从 demo 变成可扩展的监控平台
前缀提到过这套源码里控制器核心是一个继承自 Ryuapp_manager.RyuApp的类，flow_stats是挂在实例上的普通字典。跑完基本流程之后，建议你把这份数据接到时序数据库里，比如 InfluxDB，否则控制器一旦重启，流量统计历史就丢了。这里给出一个采集写入的最小实现，平时我做完基础实验以后，会直接复用这套扩展思路，把代码改成按固定频率把统计结果推送到本地时序库。
# stats_exporter.py 放在控制器同目录下，用 threading.Timer 定时执行导出 import json import threading import time from influxdb import InfluxDBClient class StatsExporter: def __init__(self, controller, interval=10): self.controller = controller self.interval = interval self.client = InfluxDBClient(host='127.0.0.1', port=8086) self.client.switch_database('sdn_monitor') self._timer = None def export_loop(self): # 组装 InfluxDB 的 line protocol 数据 points = [] for dpid, ports in self.controller.flow_stats.items(): for port, stat in ports.items(): points.append({ "measurement": "port_traffic", "tags": {"dpid": str(dpid), "port": str(port)}, "fields": { "packets": stat.get("packets", 0), "bytes": stat.get("bytes", 0) } }) try: self.client.write_points(points) except Exception as e: print(f"write influxdb failed: {e}") # 重新启动定时器 self._timer = threading.Timer(self.interval, self.export_loop) self._timer.daemon = True self._timer.start() def start(self): self._timer = threading.Timer(self.interval, self.export_loop) self._timer.daemon = True self._timer.start()这段代码核心在于controller.flow_stats是公开的字典属性，所以外部类能直接读取，本质上不需要给控制器本身做任何改动。write_points是按批量模式写入，每条数据都带dpid和port标签，这样你在 Grafana 里能按交换机端口单独切分面板。如果本地没有 InfluxDB 服务，可以先用influxd命令启动，默认 8086 端口。这一步扩展做完，原本一个毕业设计项目就升级成了带历史数据回溯能力的监控系统。
我自己在跑完这套流程之后养成的习惯是，每次改控制器代码之前先清流表、重启后用 tcpdump 抓包确认 OpenFlow 消息确实在交换机和控制器之间流动，然后再做功能验证。从那以后几乎没再出现过“代码改了但交换机没反应”的焦虑。这套基于 SDN 的 Python 源码下载下来以后，建议你也按这个流程完整走一遍，从环境搭建到流量回放再到数据扩展，每一步都留痕迹，希望帮到你。
本文还有配套的精品资源，点击获取
