1.3 OpenFlow 核心概念：流表、通道与控制器
1.3 OpenFlow 核心概念：流表、通道与控制器
本节摘要：OpenFlow 的世界只有三个主角——交换机里的流表、连接控制器与交换机的安全通道、发号施令的控制器。本节给出三者的精确定义，并且刻意多做一步：每个概念都标出它在报文里的对应物，让概念从第 2 章起就能在抓包里被"指认"出来。
学习目标
阅读完本节，你应当能够：
- 精确定义流表、流条目、安全通道、控制器
- 说出每个概念对应哪类 OpenFlow 消息
- 复述一个数据包在 OpenFlow 交换机里的完整旅程
三个主角
**流表（Flow Table）**是交换机里的一张"匹配—动作"规则表。每个流条目包含六要素：匹配字段、优先级、计数器、指令、超时、Cookie。数据包进来查表，命中就按指令办，全表不命中就走 Table-Miss。
**安全通道（Secure Channel）**是控制器与交换机之间的逻辑连接，底层是 TCP，端口 6653（旧实现用 6633），可套 TLS。所有 OpenFlow 消息都在这条通道上跑——它是解剖台上最主要的"血管"。
**控制器（Controller）**通过通道读写流表、应答未知流量，是网络逻辑的唯一作者。控制器不是一台特定设备，而是一个软件角色（Ryu、OpenDaylight、ONOS 都是它的实现）。
概念与报文的对应关系
流条目六要素速写
先用伪结构把流条目的字段列出来，2.3 节再逐字段展开：
FlowEntry { match: 匹配字段，如入端口、MAC、IP、端口 priority: 整数，越大越先匹配 counters: 命中包数、字节数 instructions: APPLY_ACTIONS / GOTO_TABLE / METER ... timeout: idle 空闲超时， hard 总超时 cookie: 控制器自定义的标识，供批量管理 }
三个容易混的点提前说清：
- 优先级不是顺序号：两条规则都能匹配时，数值大的赢；相同优先级则视为冲突，交换机可拒绝安装
- 超时是两个独立的钟：idle 计"多久没流量"，hard 计"条目活了多久"，谁先到期谁触发删除
- Cookie 不参与匹配：它是控制器给自己的规则贴的标签，删规则时可以按 Cookie 批量清理
控制器的"应答式"工作模式
OpenFlow 交换机是被动方：未知流量上来（Packet-In），控制器算出路径，再下发规则（Flow-Mod）。这个"问一句、答一条"的节奏是整个协议的心跳，也是抓包时最常见到的消息对。
⚠️ 常见坑：以为控制器时刻指导每个包的转发。实际上首次交互之后，流量全部在交换机本地消化，控制器只在"新流出现、拓扑变化、规则过期"时才被唤醒。把控制器当成每次都插手的角色，会误判性能模型。
动手：让超时机制自己开口说话
idle 与 hard 两只钟的差别，背定义不如让交换机演示一遍。下面在解剖台上装一条带 idle_timeout 的规则，然后分别用"持续打流"与"静默等待"两种方式观察它的生死：
# 装一条 5 秒无流量即失效的规则 sudo ovs-ofctl -O OpenFlow13 add-flow s1 \ "table=0,priority=50,ip,nw_src=10.0.0.1,idle_timeout=5,actions=NORMAL" # 持续打流：mininet> h1 ping -i 1 h2 （每秒一个包，间隔小于 5 秒） sudo ovs-ofctl -O OpenFlow13 dump-flows s1 | grep priority=50 # 停止打流，静默 6 秒后再查 sudo ovs-ofctl -O OpenFlow13 dump-flows s1 | grep priority=50 # （无输出）条目已被交换机本地删除，全程未惊动控制器
注意 idle_age 这个字段：它是距离上次命中的秒数，是判断"规则为什么还在"的第一线索。排障时一条 duration 很长但 n_packets 为零的规则，多半是匹配条件写错导致从未命中，idle 钟迟早把它收走——如果你期望它常驻，要么去掉 idle_timeout，要么修正匹配字段。反过来，控制器若依赖 Flow-Removed 同步自身状态，就必须在下发时置 send_flow_rem 标志，否则条目悄悄消失，控制器内存里的"影子规则"越积越多，这是真实部署里排过无数次的经典泄漏。
概念辨析：流表不是路由表
把流表当路由表理解，会在三处摔跟头。其一，路由表按最长前缀匹配，流表按最高优先级匹配——前缀长度在流表里只是匹配字段的一个维度，优先级才是裁决者，且同优先级的两条规则被视为配置冲突。其二，路由表的条目来自协议分发，天然趋同；流表的条目来自一个控制器，可以随时表达完全非对称的策略（比如只允许 A 到 B、不允许 B 到 A），这种表达力是传统协议给不了的。其三，路由表项没有内置的死亡机制，流表项天生自带两只钟。理解了第三点，就理解了 SDN 应用的状态管理为什么必须围绕"条目会死"来设计：要么靠超时自动回收，要么靠控制器显式删除并用 Flow-Removed 对账。
再补一个通道层面的常见误认：安全通道不是为"安全"而加密的通道，Security Channel 里的 security 是历史用词，指这条通道是控制器与交换机之间的专属通路，明文 TCP 也算。真正的机密性要叠加 TLS，而 TLS 是可选项——这解释了为什么实验环境里抓包能看到全部明文，也解释了为什么 6.1 节要把通道加密单独立为一条防线。另外，通道的 TCP 连接通常由交换机主动发起（控制器监听 6653），这意味着 NAT 或防火墙隔断的环境里，"谁连谁"的方向问题要在部署设计里提前想清楚，反方向连接的变体协议与配置是真实部署的高频障碍。
本节要点回顾
- 流表：匹配—动作规则表，报文对应物是 Flow-Mod
- 安全通道：TCP 6653 + 可选 TLS，解剖台的主血管
- 控制器：软件角色，网络逻辑的唯一作者
- 工作节奏：Packet-In 问，Flow-Mod 答，之后本地消化
- 流条目六要素：match、priority、counters、instructions、timeout、cookie
解剖台本身还没搭——下一节动手。