1.1 SDN 基础：控制平面与数据平面分离
1.1 SDN 基础：控制平面与数据平面分离
本节摘要：SDN（软件定义网络）的核心主张只有一个——把决定"包往哪转"的控制平面与实际转发的数据平面解耦，控制逻辑集中到可编程的控制器。本节从传统网络的三个具体困境出发，讲清分离的因果，并给出三层架构与接口关系，为理解 OpenFlow 的角色定位打底。
学习目标
阅读完本节，你应当能够：
- 描述传统分布式控制平面的三个工程痛点
- 画出 SDN 三层架构并标注北向/南向接口
- 区分"集中控制"与"集中转发"这两个常被混淆的说法
传统网络卡在哪
想象一个五十节点的数据中心要改一条路由策略。运维得逐台登录交换机敲 CLI，或者在网管平台上点五十次。原因很简单：决定转发的控制逻辑（路由协议、生成树、ACL）就运行在每台交换机自己的系统里，网络越大，"一致性"就越贵。
痛点可以归纳成三条：
- 决策分散：每台设备独立跑协议，全局视图无人掌握，策略只能拼凑
- 创新被锁死：新转发逻辑要等厂商固件更新，周期以年计
- 运维是体力活：变更逐台下发，配置漂移与回滚都靠人肉
2000 年代中后期，斯坦福的研究者（Nick McKeown、Martin Casado 等人）在 Clean Slate 等项目里反复验证：如果给转发设备留一个统一的外部控制接口，网络的可编程性会质变。这个思路的集大成者就是 SDN，而那个"统一接口"的第一个标准化成果就是 OpenFlow。
三层架构与两个接口
SDN 的经典画法是三层。控制层是大脑，基础设施层是肌肉，应用层是大脑里跑的想法。
SDN 三层架构图
注意一个容易踩的理解偏差：SDN 集中的是控制，不是转发。数据包依然在交换机本地线速转发，控制器只写规则、不当二传手。如果每个包都上控制器，那不叫 SDN，叫做集中式路由器，性能撑不住任何真实网络。
分离带来的账单
收益前面说了，代价也要摆出来，工程没有免费午餐：
| 维度 | 传统网络 | SDN 分离后 |
|---|---|---|
| 全局策略 | 逐台拼凑 | 控制器一处下发 |
| 创新速度 | 等厂商固件 | 改应用即可 |
| 单点风险 | 无集中故障点 | 控制器集群成为关键 |
| 协议复杂度 | 设备间协议繁多 | 集中在南向一处 |
| 排障思路 | 看设备配置 | 看流表与报文交互 |
⚠️ 常见坑：把 SDN 等同于 OpenFlow。OpenFlow 只是南向接口的一种（虽然是最著名的一种），P4、NETCONF、gNMI 都在分同一杯羹。本教程聚焦 OpenFlow，但别在架构认知上画等号。
💡 关键直觉：判断一个系统是不是"真 SDN"，就看转发决策的生成位置——在设备固件里，就不是；在可编程的外部控制器里，就是。
加练：用两个抓包点验证"分离"不是口号
三层架构图是纸面上的说法，落到解剖台上可以直接用数据证明。在同一台 Mininet 宿主机上开两个抓包点：一个抓控制通道（回环口），一个抓数据通道（交换机的物理口），你会看到两类流量在文件级别上就分了家。
第一个终端抓控制面，Ryu 已在 6653 端口监听：
# 抓包点一：控制通道（控制器与 OVS 都在本机，走回环口） sudo tcpdump -i lo tcp port 6653 -w ctrl.pcap # ... tcpdump -r ctrl.pcap -c 8 | awk '{print $3, $5, $NF}' # 127.0.0.1.6653 > 127.0.0.1.41922: Flags [P.], length 104 <- Packet-In（h1 的 ARP）
第二个终端抓数据面，只看第一跳端口：
# 抓包点二：s1 的 1 号端口（h1 接入侧），只存在 ARP/ICMP，没有任何 OpenFlow 字节 sudo tcpdump -i s1-eth1 -c 6 -e # 00:00:00:00:00:01 > 00:00:00:00:00:02, ethertype IPv4 (0x0800): 10.0.0.1 > 10.0.0.2: ICMP echo request
两个文件对照能读出三件事：控制报文只在 6653 端口出现，数据报文里找不到任何 OpenFlow 痕迹；h1 发出的 ICMP 在数据口出现时，转发决策早已由几毫秒前的 Packet-In / Flow-Mod 交互写进流表；此后同一流的后续报文不再触发控制报文。把 ping 的 -c 参数从 3 改到 300，ctrl.pcap 几乎不再增长，而 s1-eth1 上的捕获线性增长——"首流上控制器、后续本地消化"这条 SDN 的经济账，在这里变成了可以度量的文件大小差异。
再用规则落地的证据补最后一环：
sudo ovs-ofctl -O OpenFlow13 dump-flows s1 # priority=10,in_port="s1-eth1",dl_src=00:00:00:00:00:01 actions=output:"s1-eth2"
这三条证据链（控制口报文、数据口报文、流表条目）合起来，就是"控制与转发分离"在解剖台上的完整物证。往后每一章的实验，本质上都是在换一个角度重新审这三份证据。
概念辨析：三组最容易混的说法
初学者常把几对术语搅在一起，这里一次性切开。集中控制与集中转发：前者指决策集中，转发仍在设备本地线速执行；后者指每个包都途经中心节点，那是集中式路由器，性能模型完全不同。SDN 与 OpenFlow：SDN 是架构思想，OpenFlow 是实现该思想的一种南向协议，正如 HTTP 不等于互联网。控制器与网管：网管系统只读配置与状态，不参与转发决策；控制器的输出直接变成流表，写的是转发行为本身。分不清第三组的人，往往会低估控制器故障的影响半径——网管挂了网络照转，控制器失联的策略边界则要靠 5.2 节的失联模式来兜底。
本节要点回顾
- 痛点三件套：决策分散、创新锁死、运维体力活，是 SDN 出现的直接动因
- 三层架构：应用—控制—基础设施，北向 REST、南向 OpenFlow
- 集中控制 ≠ 集中转发：数据面仍在本地线速跑
- 代价：控制器成为单点，需要集群化与可靠性设计
下一节看 OpenFlow 这个"南向标准"是怎么从论文走到产业的。