基于SDN的负载均衡：Ryu控制器与Mininet完整实现与避坑指南

简介：基于SDN的负载均衡Python源码及配套文档，面向计算机相关专业学生、教师和企业人员，适用于毕业设计、课程设计、期末作业或项目初期演示。项目围绕SDN控制层与数据转发层分离实现流量均衡，包含可运行的Python主程序、用于流表增删的Shell脚本、网络拓扑文件和多张流程截图，能帮助理解控制器策略编写及负载均衡落地过程。资源包共31个文件，约1004KB，主要由py源码、sh脚本、png截图、topo拓扑和md说明文档组成，并附带README说明文件、示例工程目录及附赠参考资料，便于按模块开展学习与二次开发。目前已有78人学习下载，代码经测试运行成功，功能正常；通过学习可掌握SDN控制器应用开发思路、网络自动化编程与流表管理技巧，也可作为相关课程设计或科研实验的起步模板。

1. 基于SDN的负载均衡：为什么大多数课程设计死在演示前

做基于SDN的负载均衡课设的人，十个里有八个不是死在算法上，而是死在「从代码能跑」到「演示能看」这段路上。这个项目听起来是一个网络负载均衡系统，实际上考验的是你能否在 Controller 里把 ARP 代答、流表下发、双向 NAT、轮询策略这些环节全部串起来——任何一环掉链子，全网直接瘫痪。我见过太多人把 Ryu 控制器写得像 PPT，答辩现场 curl 到虚拟 IP 上，第一个包就超时，然后整个演示翻车。这篇文章按一条能复现的路线讲：环境怎么搭、Python 控制器怎么写、等开销负载均衡怎么落、典型坑长什么样，最后讲明文档和流程演示怎么组织才能拿到高分。适合正在做 SDN 相关毕业设计或课程设计、已经有 Python 基础和 Mininet 使用经验的同学。

2. 搭环境：Mininet+Ryu 最小复现拓扑与启动命令

2.1 为什么选 Ryu 而不是 POX 或 Floodlight

SDN 控制器的选择多得让人眼花，但做负载均衡这个题目，我一般直接推荐 Ryu。理由很简单：它是纯 Python 写的，和标题里的 Python 源码、Python 扩展完全对得上；OpenFlow 1.3 的支持完整，group table、meter 这些高级特性都能用；调试时可以直接在回调函数里 print 报文信息，不需要像 Floodlight 那样去翻 Java 日志。POX 也是个选择，但 POX 更像是教学玩具，对 OpenFlow 1.3 的支持一直停留在半成状态，流表操作接口设计得也比较老。

网络侧用 Mininet 虚拟出交换机、客户端和后端服务器。Mininet 的好处是拓扑可以写进一个 Python 文件里，随项目一起交付，评委能直接复现。很多同学纠结要不要上 eve-ng 或 GNS3，我的建议是：课程设计阶段完全没必要，Mininet 启动快、资源占用小、和 Ryu 通信的方式和真实 OVS 交换机完全一致，后面想扩展多路径拓扑也方便。

环境准备这块，Ubuntu 20.04 或 22.04 上装起来很快。先装 Mininet，然后通过 pip 装 Ryu。注意 Ryu 依赖的 eventlet 版本和系统 Python 版本有兼容性讲究，如果 pip 报编译错误，优先考虑用虚拟环境隔离。

sudo apt update sudo apt install -y mininet python3 -m venv ~/sdn-lb-venv source ~/sdn-lb-venv/bin/activate pip install ryu

这里用 venv 而不是直接 pip install 到系统环境，是因为后面调试时可能要重装不同版本的依赖，虚拟环境可以随便折腾，出了问題直接删掉重建，不怕把系统搞坏。

2.2 最小拓扑：一台交换机、三台后端、一个客户端

负载均衡至少要有一个客户端、一个负载均衡入口、多台后端服务器。我常用的拓扑是一台 OVS 交换机，挂三台服务器和一台客户端。服务器的 IP 规划为 10.0.0.1、10.0.0.2、10.0.0.3，客户端是 10.0.0.10，虚拟 IP（VIP）预留 10.0.0.100，这个 VIP 就是对外暴露的服务地址。

from mininet.topo import Topo from mininet.net import Mininet from mininet.node import RemoteController, OVSSwitch from mininet.cli import CLI from mininet.log import setLogLevel class LBTopo(Topo): def build(self): s1 = self.addSwitch('s1', cls=OVSSwitch) for i in range(1, 4): server = self.addHost(f's{i}', ip=f'10.0.0.{i}/24') self.addLink(s1, server) client = self.addHost('client', ip='10.0.0.10/24') self.addLink(s1, client) def main(): setLogLevel('info') net = Mininet( topo=LBTopo(), controller=RemoteController('c0', ip='127.0.0.1', port=6653), switch=OVSSwitch, autoSetMACs=True ) net.start() CLI(net) net.stop() if __name__ == '__main__': main()

autoSetMACs=True 这个参数很重要，它让每台主机的 MAC 自动变成 02:00:00:00:00:01 这种规则地址，后面写控制器时就可以直接按编号推导 MAC，而不需要进 Mininet 里一个个查。拓扑里没有给交换机指定 IP，因为 OVS 只需要和控制器的 TCP 连接，不需要自己的管理 IP。

2.3 启动顺序：先起控制器还是先起 Mininet

顺序上有讲究。我习惯先在一个终端启动 Ryu 控制器，再启动 Mininet 拓扑。Mininet 里配置的 controller 是 RemoteController，交换机启动时会主动连接 127.0.0.1 的 6653 端口。如果反过来，交换机先启动，它会一直报连接失败，虽然 OVS 会不断重试，但日志刷屏看着头疼。

# 终端 1：启动 Ryu 控制器（先进入虚拟环境） source ~/sdn-lb-venv/bin/activate ryu-manager --verbose lb_controller.py # 终端 2：启动 Mininet 拓扑 sudo mn --custom lb_topo.py --topo lb --controller remote,ip=127.0.0.1,port=6653 --switch ovs,protocols=OpenFlow13

--switch ovs,protocols=OpenFlow13 这个参数容易被忽略。Ryu 默认用 OpenFlow 1.3 协商，而 Mininet 的 OVS 默认可能只启用 OpenFlow10 或 13 的兼容模式，不指定协议版本会导致版本协商失败，控制器端一直收不到 SwitchFeatures 事件。实际操作中我一般直接自定义拓扑文件，连 mn 命令行参数都省了。

2.4 连通性预检：此刻 ping 不通才说明 SDN 有意义

拓扑起来之后，第一件事不要急着测负载均衡，先跑一下连通性。在 Mininet CLI 里执行 pingall，此时预期结果应该是全不通。这不是失败，而是好现象——说明交换机里没有任何流表，所有流量都被扔给控制器，网络真的处在「受 SDN 控制」的状态，后面流表一上，全网才通。很多同学看到 ping 不通就以为环境坏了，其实这一步是后面答辩时证明「流表驱动转发」的绝佳素材。

mininet> pingall *** Ping: testing ping reachability client -> X X X s1 -> X X X ...

等控制器代码写好后，再跑一次 pingall，从全不通变全通，前后对比截图放进文档里，这就是整个项目最直观的流程演示素材。在遇到 ARP 黑洞、流表冲突这些问题时，pingall 也是第一排查工具。

3. 写控制器：Python 实现 ARP 代答、虚拟 IP 转发与轮询分发

3.1 三类报文三种命运：先想清楚再写代码

控制器接管交换机后，所有没命中流表的包都会以 PacketIn 消息送到 Controller。设计上要清晰回答三个问题：ARP 怎么处理、到 VIP 的 TCP 连接怎么转发、其他流量怎么办。我的方案是：ARP 请求由 Controller 代答，回应 VIP 的 MAC；到 VIP 的 TCP 请求做目的改写（DNAT）和源改写（SNAT），把流量分发到三台后端；其余报文一律走 learning switch 逻辑兜底转发。

这里最容易被初学者误解的是 ARP。客户端访问 10.0.0.100 之前，内核会先发一个 「who has 10.0.0.100」的广播包。如果 Controller 不答，客户端永远拿不到 VIP 的 MAC，后续 TCP 连接根本发不出去。这个环节和负载均衡算法无关，但它决定演示能否跑通，做项目时我把它放在第一个实现。

3.2 PacketIn 入口与 ARP 代答代码

from ryu.base import app_manager from ryu.controller import ofp_event from ryu.controller.handler import MAIN_DISPATCHER, CONFIG_DISPATCHER, set_ev_cls from ryu.ofproto import ofproto_v1_3 from ryu.lib.packet import packet, ethernet, ether_types, arp, ipv4, tcp from ryu.lib.packet import packet_base class SdnLb(app_manager.RyuApp): OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION] VIP_IP = '10.0.0.100' VIP_MAC = '02:00:00:00:00:fe' # 后端服务器：(IP, MAC, 交换机端口) SERVERS = [ ('10.0.0.1', '02:00:00:00:00:01', 2), ('10.0.0.2', '02:00:00:00:00:02', 3), ('10.0.0.3', '02:00:00:00:00:03', 4), ] def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.flow_install_count = 0 self.round_robin_index = 0 @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) def packet_in_handler(self, ev): msg = ev.msg datapath = msg.datapath in_port = msg.match['in_port'] pkt = packet.Packet(msg.data) eth = pkt.get_protocol(ethernet.ethernet) if eth.ethertype == ether_types.ETH_TYPE_ARP: self.handle_arp(datapath, in_port, pkt, eth) elif eth.ethertype == ether_types.ETH_TYPE_IP: self.handle_ip(datapath, in_port, pkt, eth)

handle_arp 要做的事情是判断 ARP 请求的目标 IP 是不是 VIP，如果是，就构造一个 ARP Reply 回给请求方，源 MAC 填 VIP 的 MAC。注意这个回复包要从 PacketOut 直接发给请求方所在的端口，同时要带原始数据，不能依赖 buffer_id，因为部分报文数据已经在 Controller 手里。

def handle_arp(self, datapath, in_port, pkt, eth): arp_pkt = pkt.get_protocol(arp.arp) if not arp_pkt: return # 只代答对 VIP 的 ARP 请求 if arp_pkt.opcode == arp.ARP_REQUEST and arp_pkt.dst_ip == self.VIP_IP: # 构造 ARP Reply: VIP_MAC -> 请求方 reply_pkt = packet.Packet() reply_pkt.add_protocol(ethernet.ethernet( ethertype=ether_types.ETH_TYPE_ARP, dst=eth.src, src=self.VIP_MAC)) reply_pkt.add_protocol(arp.arp( opcode=arp.ARP_REPLY, src_mac=self.VIP_MAC, src_ip=self.VIP_IP, dst_mac=arp_pkt.src_mac, dst_ip=arp_pkt.src_ip)) reply_pkt.serialize() ofproto = datapath.ofproto parser = datapath.ofproto_parser out = parser.OFPPacketOut( datapath=datapath, buffer_id=ofproto.OFP_NO_BUFFER, in_port=in_port, actions=[parser.OFPActionOutput(ofproto.OFPP_IN_PORT, 0)], data=reply_pkt.data) datapath.send_msg(out)

这里 OFPP_IN_PORT 是让包从原入口发回去，相当于模拟二层交换机的直接应答。如果你想对后端服务器的 ARP 也做学习转发，可以加一个 mac_to_port dict，我为了控制复杂度，demo 里只代答 VIP 的 ARP，其余 ARP 暂时丢弃，并在文档里注明这是安全取舍。

3.3 TCP 转发与轮询分发：双向改写才能建立连接

收到 TCP 报文时，要看目的 IP 是不是 VIP。如果是，就选一台后端，安装两条流表：正向把 VIP 改写为后端真实 IP 和 MAC，反向把后端真实 IP 改写回 VIP。反向改写很多人会漏掉，漏了之后 TCP 握手根本完不成。

def handle_ip(self, datapath, in_port, pkt, eth): ip_pkt = pkt.get_protocol(ipv4.ipv4) if not ip_pkt: return # 当前只处理到 VIP 的 TCP 流量 if ip_pkt.dst == self.VIP_IP and pkt.get_protocol(tcp.tcp): server_ip, server_mac, out_port = self.select_server() parser = datapath.ofproto_parser ofproto = datapath.ofproto # 正向流：VIP -> 后端真实 IP，发往后端端口 actions_fwd = [ parser.OFPActionSetField(ipv4_dst=server_ip), parser.OFPActionSetField(eth_dst=server_mac), parser.OFPActionOutput(out_port, 0), ] match_fwd = parser.OFPMatch( eth_type=ether_types.ETH_TYPE_IP, ipv4_dst=self.VIP_IP) self.add_flow(datapath, 800, match_fwd, actions_fwd) # 反向流：来自后端的回包，源 IP 改回 VIP，送回客户端 actions_rev = [ parser.OFPActionSetField(ipv4_src=self.VIP_IP), parser.OFPActionSetField(eth_src=self.VIP_MAC), parser.OFPActionOutput(in_port, 0), ] match_rev = parser.OFPMatch( eth_type=ether_types.ETH_TYPE_IP, ipv4_src=server_ip) self.add_flow(datapath, 800, match_rev, actions_rev)

select_server 就是简单的轮询：取模切换下标。这里故意先不做哈希，让逻辑直白一点，方便和下一章的等开销负载均衡做对比。

def select_server(self): s = self.SERVERS[self.round_robin_index] self.round_robin_index = (self.round_robin_index + 1) % len(self.SERVERS) return s def add_flow(self, datapath, priority, match, actions, idle_timeout=30): ofproto = datapath.ofproto parser = datapath.ofproto_parser inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS, actions)] mod = parser.OFPFlowMod( datapath=datapath, priority=priority, match=match, instructions=inst, idle_timeout=idle_timeout, buffer_id=ofproto.OFP_NO_BUFFER) datapath.send_msg(mod)

优先级我固定用 800，比 table-miss 的 0 高很多，保证命中转发流后不再触发 PacketIn。idle_timeout 设为 30 秒，意思是 30 秒内没有流量命中就让交换机删除这条流。这个参数后面在避坑章节重点讲，先记住它是「后悔药」，设太大流表满天飞，设太小连接频繁断。

3.4 buffer_id 的坑：为什么直接带 data 重放

Ryu 的 PacketIn 消息里通常会带一个 buffer_id，交换机的数据缓冲区内已经存了完整报文。一个看似高效的写法是把 buffer_id 传给后续的 OFPPacketOut 或 FlowMod，让交换机直接处理缓冲区里的报文。但在流表刚下发、当前包还需要转发出去的场景下，buffer_id 指向的缓冲区可能在流表动作执行前就被释放，变成悬空引用。所以我在所有 PacketOut 中都显式使用 OFP_NO_BUFFER 并携带 data，让 Controller 把报文数据原样交给交换机。代价是控制器到交换机的带宽占用高一些，但对课程设计和小型 demo 完全够用，换来的是稳定不翻车。

到这里，启动 ryu-manager 后再跑 pingall，三台服务器之间、客户端到服务器之间应该都是通的。而客户端去访问 VIP 上的 HTTP 服务，流量会被轮询分发到三台后端上，用 tcpdump 抓后端网卡就能看到请求分布。

4. 从轮询到等开销负载均衡：大象流、哈希分片与动态反馈

4.1 轮询的隐藏缺陷：大象流和哈希碰撞让负载重新失衡

上一章的轮询是按连接粒度分发的，五元组一样的连接会命中同一条流表，后续报文不再经过 Controller。这个机制本身没问题，但轮询只保证「第 N 个连接给谁」的顺序，不保证「每条连接的流量大小差不多」。实际业务里，少量大象流（大文件下载、视频流）会占用绝大多数带宽，而海量老鼠流（HTTP 请求、心跳包）看起来很多但字节量很小。

假设第一条连到后端 1 的连接正好是个持续 10 分钟的视频流，后端的 2 和 3 只处理零碎请求，整体负载立刻失衡。这时候再优秀的轮询也无能为力，因为决策粒度在连接建立时就确定了。要解决负载失衡，得让「等开销」成为可度量的策略：要么让发往等价后端的分组路径/权重按实时负载调整，要么让一条大流能被切分到多条等价路径上。前者是动态加权，后者就是网络领域常说的等开销多路径（ECMP）思想。

4.2 等开销负载均衡的两个落点：服务器侧与路径选择侧

「等开销负载均衡」这个词在网络里有两层含义。一层是数据中心的 ECMP：同一目的地址存在多条代价相等的路径，交换机按流哈希把流量散到不同链路上；另一层是服务器负载均衡（SLB）：多台后端服务器能力对等，把请求按策略分发。两者本质相同——在等价资源之间按某种映射分派流量。课程设计里，如果拓扑是单台交换机连接多台服务器，那落点就在后端选择上；如果拓扑升级为环形或 leaf-spine，那落点就是路径选择。

需要在文档里把这两层说清楚，否则答辩时评委问「你的等开销体现在哪」容易答偏。我一般这么表述：多台服务器的处理能力是等开销的，控制器按实时负载做加权分发，是等价资源上的分配问题。如果拓扑里有两条交换机间链路，就为同一目的 IP 安装两条等价流表，实现逐流 ECMP。

4.3 用 OpenFlow 1.3 select group 实现等开销分片

Ryu 里实现逐流哈希的常见做法是 group table 的 select 类型。OpenFlow 1.3 的 select group 由交换机自行对报文做哈希，把不同流分散到不同 bucket，Controller 只负责定义 bucket 的权重和动作，不需要逐个连接装流表。相比 Controller 逐个流安装，group table 的转发面负担低得多，也更贴近生产级 SDN 负载均衡的实现方式。

def add_ecmp_group(self, datapath, group_id): parser = datapath.ofproto_parser ofproto = datapath.ofproto buckets = [] for server_ip, server_mac, out_port in self.SERVERS: actions = [ parser.OFPActionSetField(ipv4_dst=server_ip), parser.OFPActionSetField(eth_dst=server_mac), parser.OFPActionOutput(out_port, 0), ] buckets.append(parser.OFPBucket(weight=1, actions=actions)) req = parser.OFPGroupMod( datapath=datapath, command=ofproto.OFPGC_ADD, type_=ofproto.OFPGT_SELECT, group_id=group_id, buckets=buckets) datapath.send_msg(req)

group_id 自己分配，只要不和交换机现有组冲突就行。weight=1 表示三个 bucket 等权重，交换机内部对每条流算哈希，把流映射到某个 bucket。之后匹配到 VIP 的流表动作就不再是固定改写和出端口，而是直接 output 到 group：

def add_vip_to_group_flow(self, datapath): parser = datapath.ofproto_parser actions = [parser.OFPActionGroup(group_id=1)] match = parser.OFPMatch(eth_type=ether_types.ETH_TYPE_IP, ipv4_dst=self.VIP_IP) self.add_flow(datapath, 800, match, actions, idle_timeout=0)

这里的 idle_timeout 不能再设 30 秒，因为 group 表处理的是所有去往 VIP 的流量，流表如果老化，全网到 VIP 的连接都会中断。生产上这类 VIP 流表通常设为 idle_timeout=0，即永不超时。答辩时问到这一处，能讲清楚为什么超时参数在两种方案里完全不同，反而是一个加分点。select group 的局限是哈希基于五元组，哈希碰撞还是会发生，两条大象流哈希到同一个 bucket 时依旧会失衡，所以还要有下面的动态反馈。

4.4 动态反馈加权：把统计周期接进控制器

动态加权思路是周期性拉取每台后端对应端口的字节计数，根据速率调整 group bucket 的 weight。Ryu 里用 OFPFlowStatsRequest 或 OFPPortStatsRequest 都可以，端口级别更适合观察流量分布。Controller 每 5 秒发一次 PortStatsRequest，统计每个后端端口的收发字节数，算出增速后，把权重按「负载越轻权重越高」反向调整。

def monitor_loop(self): while True: for datapath in self.datapaths.values(): self.request_port_stats(datapath) hub.sleep(5) def request_port_stats(self, datapath): ofproto = datapath.ofproto parser = datapath.ofproto_parser req = parser.OFPPortStatsRequest(datapath, 0, ofproto.OFPP_ANY) datapath.send_msg(req) @set_ev_cls(ofp_event.EventOFPPortStatsReply, MAIN_DISPATCHER) def port_stats_reply_handler(self, ev): # 计算各后端端口速率后，调用 modify_group 更新 weight self.update_group_weights(ev.msg.body)

monitor_loop 要放进 Ryu 的线程调度里，常见做法是在init里调用 hub.spawn(self.monitor_loop)。权重更新的公式我一般用：新权重 = 基准值 ×（对端总速率 / 本端速率），再做归一化。注意速率是增量不是总量，所以每次回复要保存上一轮的计数器值，用 delta 除以间隔时间得到速率。

5. 四个高频踩坑点：流表冲突、ARP 黑洞、会话保持与控制器单点

5.1 只装了正向流表，回程报文全部丢失

现象：客户端到 VIP 的 TCP 握手卡在 SYN_SENT，curl 报超时；但抓后端网卡发现 SYN 已到达，服务端也回了 SYN-ACK，只是客户端永远收不到。

原因：Controller 只给「去往 VIP」的方向装了 NAT 改写流表，后端回包的源 IP 是真实服务器地址 10.0.0.x，没有流表匹配，被直接扔给 Controller，而 Controller 又没有对应的处理逻辑，回包就丢了。

解决：装流表时必须成对下发。正向匹配 ipv4_dst=VIP，反向匹配 ipv4_src=服务器 IP，把源改写回 VIP。我习惯在代码里把两条流的安装写在一个函数里，用注释标明 FWD 和 REV，防止漏。排查时在 Controller 端打开 --verbose，如果看到回程方向频繁出现 PacketIn，基本就是反向流漏了。

5.2 ARP 黑洞：没有代答，VIP 永远不可达

现象：所有后端之间的 pingall 通了，但客户端连 VIP 的 HTTP 服务永远失败；在客户端里 arp -n 看不到 VIP 的 MAC 条目。

原因：ARP 广播包被交换机泛洪到 Controller，但 Controller 里只写了 TCP 转发逻辑，没处理 ARP。客户端拿不到 VIP 的 MAC，二层报文根本发不出去。

解决：Controller 里必须为 VIP 实现 ARP 代答，这是 SDN 负载均衡的标配逻辑。注意代答要回给请求端口而不是所有端口——用 OFPP_IN_PORT 就把响应沿着来路发回去了。如果之后想教交换机自己处理 ARP，也可以下发一条 high-priority 流表把 ARP 包都导到 Controller，二选一即可，别同时做，两条路径会互相打架。

5.3 idle_timeout 太短：视频播放到一半连接被切断

现象：用 wget 下载大文件，开头正常，几秒之后速度归零，过一会又恢复。

原因：idle_timeout=5 秒时，TCP 长连接如果短暂没有数据传输，交换机就把这条流删了，后续的数据包再触发 PacketIn，Controller 重新选后端和装流表。问题是 TCP 连接已经在真实服务器上建立，重装流表后若映射到另一台后端，报文到了错误服务器，直接被 reset。

解决：连接建立后的数据流和新建连接的流要区分。最简单的方法是给已建立的连接匹配更细的字段（ipv4_dst + tcp_dst + 后端方向），把 idle_timeout 设成 60 秒以上，而新连接探测流保持 5 秒。这里的教训是：超时参数不是拍脑袋定的，要和业务特征匹配。交互式 HTTP 长短连接并存时，60 秒是稳妥起点。

5.4 轮询导致会话保持失效：登录状态反复横跳

现象：客户端连续请求两个页面，第一次落在后端 1，第二次落到了后端 2。如果写的是传统 Session 而非 JWT 无状态登录，用户状态直接丢失。

原因：轮询或纯哈希只保证分发均匀，不保证同一个客户端的会话固定在同一个后端上。所有基于 Cookie 的会话保持要求「同一来源 → 同一后端」。

解决：课程设计里最简单的是按客户端 IP 做哈希取模，把会话绑定到某台服务器；或者用目标 IP + 源 IP 做一致性哈希。文档里如实写明：当前方案按源 IP 哈希实现了会话保持，但单点哈希在客户端 IP 数量少时分布不均，后续可以引入一致性哈希环。这一条写进「不足与改进」，答辩时非常有说服力，比假装完美更能拿高分。

5.5 控制器进程意外退出，全网进入黑匣子状态

现象：Ryu 进程崩溃后，所有已有连接断断续续，新连接完全不通；OVS 交换机里的流表还在，但没人处理新的 PacketIn。

原因：SDN 集中控制的天然缺陷——控制面是单点。交换机侧的流表无法自愈，也没有替代控制器可以接管。

解决：演示前给 Ryu 套一个 systemd 服务或 supervisord 守护进程，崩溃后自动拉起。更符合 SDN 语义的做法是部署两个控制器实例，交换机配置 multiple 连接，但 Ryu 对多控制器支持有限，成本高，课设里不建议硬上。在文档风险章节写清楚「控制面单点是本方案的已知限制」，比被评委问住要好得多。

6. 把项目包装成高分交付物：文档结构、流程演示脚本与三项验证指标

6.1 文档目录怎么组织，评委才觉得「完整」

源码交付物里文档比代码更影响评分。我建议按五份文档组织：需求与方案设计、环境搭建指南、源码说明、测试报告、操作手册。源码说明里要有每份 Python 文件的职责表、关键函数列表、数据流图（用文字描述版的箭头图，不依赖绘图工具）。测试报告附上三张截图：pingall 从全不通到全通、curl 访问 VIP 的输出、后端三台机器的负载分布，比任何描述都有力。

6.2 流程演示脚本：5 分钟跑完的固定动作

演示要用脚本约束，不能靠现场手敲命令。我把演示固定为四步，每一步都有预期输出：

# 第一步：启动控制器和拓扑 ryu-manager --verbose lb_controller.py sudo mn --custom lb_topo.py --topo lb --controller remote,ip=127.0.0.1,port=6653 --switch ovs,protocols=OpenFlow13 # 第二步：验证全网连通（预期：全部 ping 通） mininet> pingall # 第三步：连续发 9 次请求到 VIP，观察后端命中分布 mininet> client curl -s http://10.0.0.100/ # 预期：三台后端各响应 3 次左右 # 第四步：抓后端网卡统计连接数 mininet> s1 tcpdump -i s1-eth2 -c 3 tcp port 80

第三步的多机 curl 可以用 Mininet 的 xterm client 来做，也可以在 client 里用 Python 脚本循环请求。预期输出的波动本身就是演示的一部分——指出「这里命中偏向后端 2，是因为哈希碰撞」，然后引出动态反馈优化。

6.3 三项验证指标：用数据证明负载均衡生效

指标选三样最直观的：吞吐量、首包响应延迟、后端负载均衡度。吞吐量用 iperf 打流，分别测「直连单台后端」和「通过 VIP 访问」时的总吞吐，证明聚合能力大于单机。首包时延对比开负载均衡前后的 curl 耗时，注意冷启动有 ARP 和流表安装开销，要取第二三次以后的稳定值。负载均衡度用每台后端接收的连接数或字节数计算标准差，标准差越小说明分发越均匀。三张数据表放进测试报告，比写一千字「系统性能良好」管用得多。

最后说一句我做这个项目时吃的亏：当时把流表老化时间调到 5 秒去演示下载，现场翻车，才发现参数和演示场景必须提前匹配，脚本要连续完整跑三遍才算稳。所有优化都该在真实演示前用同样命令复测一遍，而不是只看单次成功。希望帮到你。

本文还有配套的精品资源，点击获取