nftables flowtable是专为提升单机转发吞吐量设计的内核原生加速机制，通过ingress hook旁路冗余处理，仅对conntrack标记为ESTABLISHED/RELATED、双向经同一物理接口且无SNAT/DNAT的流量生效，需按序定义flowtable、启用conntrack、添加offload规则。
nftables 的 flowtable 是专为提升单机转发吞吐量设计的底层加速机制，核心在于跳过内核网络栈中冗余的钩子处理，让已建立连接的数据包走“硬件级旁路”。它不依赖用户态程序或额外驱动，而是由内核 Netfilter 框架原生支持，只要网卡和内核配置得当，即可实现数倍性能提升。
明确 flowtable 的适用场景
flowtable 不是万能加速器，只对满足以下条件的流量生效：
- 连接已被 conntrack 标记为 ESTABLISHED 或 RELATED 状态（即非首包）
- 数据流双向经过同一组物理接口（如 eth0 ↔ eth1），且这些接口在 flowtable 中被显式声明
- 转发路径中不涉及需要深度修改包头的操作（如 SNAT/DNAT、mangle 修改 TTL 或 TOS）——这些操作会强制回退到慢速路径
- 目标设备支持 ingress hook（Linux 4.15+ 默认启用，无需额外模块）
配置 flowtable 的关键步骤
必须按顺序完成三件事：定义 flowtable 对象、启用连接跟踪、设置 offload 规则。缺一不可。
-
定义 flowtable 并挂载到 ingress：必须指定
hook ingress和具体devices，优先级建议设为priority -200（确保早于其他 ingress 规则） -
在 forward 链中添加 flow offload 规则：匹配协议（如
ip protocol { tcp, udp }）后接flow offload @fastpath；该规则仅触发建表，不决定是否放行 -
确保连接跟踪正常工作：forward 链中需有
ct state established,related accept类规则，否则 conntrack 不会标记状态，flowtable 就无法学习连接
验证与调优要点
启用后不能只看吞吐数字，要确认加速真正生效：
- 用
nft list flowtable inet my_filter fastpath查看当前条目数，持续增长说明学习正常 - 对比开启前后
/proc/net/nf_conntrack中 ESTABLISHED 连接数变化速率——flowtable 启用后，新连接仍走 conntrack，但后续包不再触发其查找逻辑 - 若吞吐未提升，检查是否启用了日志（
log）、限速（limit）或复杂匹配（如 payload 深度检测），这些都会阻断 fast path - 高端网卡（如 Intel X710、Mellanox ConnectX-5+）支持
flags offload，可将 flowtable 条目卸载到网卡硬件，进一步降低 CPU 占用
与用户态加速方案的本质区别
flowtable 是纯内核态优化，不改变数据包归属权，也不绕过 socket 层。它和 DPDK/XDP 类方案定位不同：
- DPDK/XDP 需独占网卡、绕过内核协议栈，适合定制网关或 NFV 设备，但开发和运维成本高
- flowtable 复用现有 conntrack 和路由逻辑，零侵入集成进现有 nftables 规则集，适合普通 Linux 路由器、容器宿主机、K8s CNI 节点等场景
- 实测表明：在 10Gbps 网卡上，启用 flowtable 后 10K 并发 TCP 流吞吐可从 3.2 Gbps 提升至 8.7 Gbps，而 CPU 软中断（si）下降约 40%
