2. SDN架构与数据平面演进
传统网络设备（交换机、路由器）把控制逻辑和数据转发都封装在同一个封闭盒子里：路由协议进程运行在设备本地CPU上，计算出转发表后下发给本机的转发芯片，转发芯片再按表项对每个报文做查表、改写、转发。这种"控制与转发耦合"的架构在早期网络规模下工作良好，但当网络规模扩大、业务需求变得多样时，问题就暴露出来：每台设备独立决策，全局视图缺失；厂商私有实现导致新协议部署周期长；运维人员只能通过命令行逐台配置，难以做全局流量工程。
SDN（Software-Defined Networking）的核心思想就是把这两件事拆开：控制平面负责"怎么走"——计算路径、生成转发表、维护全局拓扑与策略；数据平面负责"照着走"——按已有表项对报文做高速转发。两者之间通过标准化的南向接口通信。这样，控制逻辑可以集中在一个或一组控制器上，用软件实现，具备全局视图；数据平面设备退化为通用转发硬件，只关心"匹配+动作"。
控制平面与数据平面的分离关系
分离之后，网络被抽象成三层：应用层（路由、防火墙、负载均衡等业务逻辑）、控制层（SDN控制器，维护拓扑、计算路径、下发流表）、基础设施层（交换机/路由器等转发设备）。控制器通过南向接口（典型如OpenFlow）向设备下发流表；设备通过南向接口上报端口状态、流统计、Packet-In事件。应用层则通过北向接口（REST API等）调用控制器能力。
以一次主机通信为例：主机A首次发包，交换机查不到匹配流表，触发Packet-In上报控制器；控制器根据拓扑和策略计算出路径，向沿途交换机下发Flow-Mod安装流表；后续同一条流的数据包直接在数据平面按流表转发，不再经过控制器。这就是"首包上送、后续硬件转发"的典型工作模式。
OpenFlow的局限
OpenFlow是SDN早期最成功的南向协议，它定义了"匹配域+动作"的流表模型，让控制器可以编程控制转发行为。但随着实践深入，OpenFlow的局限逐渐显现：
- 协议固定、扩展困难：OpenFlow的匹配字段和动作集由标准组织定义，每增加一种新协议头（如VXLAN、SRv6、自定义隧道），都需要推动标准更新，周期长、落地慢。
- 表项数量与硬件资源受限：OpenFlow流表通常基于TCAM实现，容量有限（典型交换机仅几千到几万条），难以支撑大规模细粒度流表。
- 无法表达有状态处理：OpenFlow本质是无状态的匹配-动作模型，难以实现需要维护连接状态、计数器、寄存器状态的复杂处理逻辑。
- 控制面与数据面语义不匹配：控制器下发的是"流表"，但硬件实际执行的是流水线阶段，两者之间的映射由厂商驱动完成，行为不透明。
这些局限的本质是：OpenFlow只开放了"表"这一层抽象，而没有开放"如何解析报文、如何组织流水线、如何定义匹配动作"的能力。换句话说，它让网络可编程，但编程的"指令集"是固定的。
可编程数据平面的动机与工程需求
P4（Programming Protocol-independent Packet Processors）的出现正是为了解决上述问题。P4把数据平面的编程能力下沉到"解析器+匹配动作表+逆解析器"这一层，允许工程师用高级语言描述：报文如何解析、按什么字段匹配、匹配后执行什么动作、如何重新封装。编译器再把P4程序映射到目标硬件（ASIC、FPGA、SmartNIC、软件交换机）上。
从工程需求看，可编程数据平面要满足以下几点：
- 协议无关：不绑定任何特定协议，新增协议头只需修改P4解析器，无需更换硬件。
- 目标无关：同一份P4程序可编译到不同目标，便于跨平台部署。
- 线速转发：可编程不等于牺牲性能，流水线仍需在硬件中并行执行，保持Tbps级吞吐。
- 可重配置：支持运行时更新流水线，适应业务变化。
- 可观测：通过寄存器、计数器、镜像等机制，把数据平面内部状态暴露给控制平面。
总结来看，SDN完成了控制与转发的分离，OpenFlow完成了转发表的标准化，而P4把可编程性推进到数据平面的流水线内部。三者是递进关系：SDN是架构思想，OpenFlow是早期实现手段，P4是数据平面可编程的工程化落地。理解这条演进线索，是后续学习P4语言、编译器、目标架构和实际部署的基础。