nftables高吞吐性能源于连接状态前置裁决、哈希查表替代线性扫描、分层链分离、硬件流表卸载及慎用log/counter。established/related包首规则放行,map实现纳秒级匹配,fastpath/policy/fallback三层链各司其职,flowtable将稳定流交由网卡硬件转发,log与counter仅限必要场景。

nftables 在高吞吐量场景下不依赖“通用过滤算法”,而是通过结构化数据路径设计 + 硬件协同加速 + 内核级匹配优化来实现高效流量处理。它的性能核心不在单条规则怎么比,而在于让绝大多数包跳过匹配、绕过内核、甚至不进协议栈。
高吞吐场景下的关键处理机制
连接状态前置裁决(fastpath)
ESTABLISHED/RELATED 连接通常占真实流量的 70%–90%。nftables 将ct state established,related accept放在 input/forward 链最顶端,使这些包在第一条规则就终止匹配——后续所有规则完全不执行。这避免了整条链的遍历开销,是零延迟放行的关键。哈希查表替代线性扫描(map/set)
当需要匹配万级 IP、千级端口或复杂组合时,硬编码规则会触发 O(N) 线性匹配,延迟随条目数直线上升。改用map(如ip saddr @blacklist)后,底层使用内核哈希表,查找时间恒定在纳秒级。注意需预设容量(如size 65536),防止运行时扩容引发抖动。-
分层链分离处理意图
把一条臃肿的 input 链拆成三类子链:-
fastpath:只做 conntrack 状态检查、lo 接口放行、管理网段白名单——80% 流量在此终结 -
policy:挂载 map、concat、动态 set,专注业务维度策略(租户/IP段/服务标签) -
fallback:仅保留drop或limit,无条件兜底,不掺杂判断逻辑,确保最差路径也极简
-
-
硬件卸载绕过内核协议栈(flowtable offload)
对 TCP/UDP 已建立连接,nftables 可将匹配后的流信息同步给支持 flow offload 的网卡(如 Intel E810、Mellanox ConnectX-6)。只要满足:- flowtable 挂在
ingress钩子且priority足够高(如 -200) -
devices = { eth0, eth1 }明确指定物理口(非 bond/vlan) - 网卡已启用
hw-tc-offload和rx-flow-hash,并开启 TSO/GRO/LRO 等底层 offload
就能让稳定流直接由网卡硬件转发,CPU 零参与,延迟压至微秒级。
- flowtable 挂在
-
规避性能陷阱:log 与 counter 的慎用
log触发软中断+日志缓冲+上下文切换;counter每包原子更新内存+缓存行争用。高并发下二者都会成为瓶颈。生产环境应:- log 仅用于临时调试,且加严格条件(如
tcp dport 22 ct state new) - counter 仅保留在限速(
limit)或告警触发点,其余一律移除 - 长期统计改用 eBPF map 或
/proc/net/nf_conntrack接口,脱离规则路径
- log 仅用于临时调试,且加严格条件(如
不复杂但容易忽略











