4. OpenFlow流表：流表匹配流程
聊到OpenFlow流表，很多朋友第一反应就是「匹配-执行」这两个动作。嗯，没错，但实际在OVS内部，这个流程远比想象中复杂。我调试过不少流表异常的问题，说白了，大部分坑都出在匹配流程的理解上。
今天我们就来拆解一下：Table Miss、Table Lookup、优先级、Cookie、硬超时。这几个概念，你搞懂了，流表就算入门了。
4.1 流表匹配流程：Table Lookup 与 Table Miss
每个数据包进入OVS后，会按照流表的编号顺序进行查找。OVS支持多级流表（Pipeline），数据包从Table 0开始，逐级往下匹配。
Table Lookup 就是查找过程。OVS会遍历当前流表中的所有流表项，找到优先级最高的那条匹配项。注意，是「优先级最高」，不是「第一个匹配」。我见过有人以为先匹配先执行，结果调试了半天——其实优先级才是王道。
那如果一条都没匹配上呢？这就引出了 Table Miss。
Table Miss 是什么？
当数据包在当前流表中找不到任何匹配项时，就会触发 Table Miss。OVS会查找该流表中是否存在优先级为0的默认流表项（即 table-miss flow entry）。如果存在，就执行该条目的动作；如果不存在，默认行为是丢弃数据包。
我曾经在项目中遇到过一个诡异的问题：某个业务流量突然不通，但其他流量正常。查了半天，发现是Table 0的默认流表项被人误删了。所有未匹配的流量直接被丢弃。嗯，从那以后，我养成了一个习惯——永远保留一条优先级为0的默认流表项，哪怕只是用来打日志。
举个例子，你可以这样配置一个默认的Table Miss处理：
# 添加一条优先级为0的默认流表项，将未匹配的包送到Controller
ovs-ofctl add-flow br0 "table=0, priority=0, actions=CONTROLLER:65535"
# 或者直接丢弃（默认行为，不添加任何流表项即可）
# 但建议显式添加一条，方便后续排查
4.2 流表优先级：谁说了算？
优先级（Priority）是流表匹配的核心。数值越大，优先级越高。OVS会优先匹配优先级高的流表项。
这里有个容易踩的坑：同一张流表中，如果两条流表项的优先级相同，且匹配域有重叠，OVS的行为是未定义的。说白了，就是看心情。我建议你永远不要依赖这种「巧合」。
举个例子：
# 两条优先级相同的流表项，匹配域重叠
ovs-ofctl add-flow br0 "table=0, priority=100, ip, nw_src=10.0.0.0/24, actions=output:1"
ovs-ofctl add-flow br0 "table=0, priority=100, ip, nw_src=10.0.0.5, actions=output:2"
当源IP为10.0.0.5的包到达时，到底走哪个？OVS可能会选第一个，也可能选第二个。你想想看，这种不确定性在生产环境里多危险。
避坑指南：
我曾经因为这个问题导致线上流量调度异常。后来我强制要求团队：同一张流表中，优先级必须唯一，或者匹配域不能重叠。你可以用不同的优先级来区分精确匹配和模糊匹配。
正确的做法是：
# 精确匹配优先级更高
ovs-ofctl add-flow br0 "table=0, priority=200, ip, nw_src=10.0.0.5, actions=output:2"
ovs-ofctl add-flow br0 "table=0, priority=100, ip, nw_src=10.0.0.0/24, actions=output:1"
4.3 Cookie：流表的「身份证」
Cookie 是流表项的一个64位标识符。它不参与匹配，但可以用来快速定位、批量删除或统计流表项。
我个人习惯用Cookie来标记流表项的「业务归属」。比如：
- Cookie=0x1001：表示来自业务A的流表项
- Cookie=0x2001：表示来自业务B的流表项
- Cookie=0xFFFF：表示系统保留流表项
这样在排查问题时，我可以快速过滤出某个业务的所有流表：
# 查看所有Cookie为0x1001的流表项
ovs-ofctl dump-flows br0 "cookie=0x1001/-1"
# 批量删除某个业务的所有流表
ovs-ofctl del-flows br0 "cookie=0x2001/-1"
Cookie还有一个妙用：配合Controller使用。当Controller下发流表时，可以携带一个唯一的Cookie值。后续如果Controller需要更新或删除这条流表，直接通过Cookie定位，效率极高。
小技巧：
我建议你在设计流表时，把Cookie的高16位作为「业务ID」，低48位作为「流表序号」。这样既方便分类，又保证唯一性。
4.4 硬超时（Hard Timeout）：流表的「生命倒计时」
硬超时，顾名思义，就是流表项从创建开始，到被自动删除的时间。不管这个流表项有没有被匹配到，时间一到，立刻消失。
为什么需要硬超时？我举个例子：
假设你有一条流表项，用来临时转发某个突发流量。如果流量停了，这条流表项就变成了「僵尸流表」，白白占用内存。硬超时就是用来清理这些僵尸的。
配置方式很简单：
# 添加一条硬超时为60秒的流表项
ovs-ofctl add-flow br0 "table=0, priority=100, hard_timeout=60, actions=output:1"
这里要注意：硬超时和空闲超时（Idle Timeout）的区别。
| 类型 | 触发条件 | 典型场景 |
|---|---|---|
| 硬超时（Hard Timeout） | 从创建开始计时，到期即删 | 临时策略、限时转发 |
| 空闲超时（Idle Timeout） | 从最后一次匹配开始计时，到期即删 | 突发流量、短连接 |
我个人习惯：对于Controller下发的动态流表，同时设置硬超时和空闲超时。硬超时作为兜底，防止流表永久残留；空闲超时作为精细控制，流量一停就回收。
# 同时设置硬超时和空闲超时
ovs-ofctl add-flow br0 "table=0, priority=100, hard_timeout=300, idle_timeout=60, actions=output:1"
这样，即使流量持续不断，最多300秒后这条流表也会被清理。如果流量提前停了，60秒内无匹配就会自动删除。
注意：
我曾经在生产环境遇到过一个问题：硬超时设置得太短（比如10秒），导致频繁的流表创建和删除，反而增加了OVS的CPU开销。后来我根据业务流量的平均持续时间，把硬超时调整到了300秒，问题就解决了。所以，超时时间不是越短越好，要结合实际流量模型来调。
4.5 总结一下
好了，我们来捋一捋今天的内容：
- Table Lookup：按优先级匹配，不是按顺序匹配
- Table Miss：没匹配上就走默认流表项，没有就丢包
- 优先级：数值越大越优先，同一优先级不要有重叠匹配域
- Cookie：流表的身份证，用来快速定位和批量操作
- 硬超时：流表的生命倒计时，防止僵尸流表
这些概念，说白了就是流表的基本功。你把这些搞透了，后面再聊性能优化、故障排查，才能听得明白。下一章，我们聊聊流表性能优化——怎么让OVS跑得更快，不丢包。