最近在折腾 Linux 网关的时候又被人问到 nftables 的性能到底比 iptables 强在哪。这个问题每隔一段时间就会出现回答里经常各说各话有的吹得天花乱坠有的说完全没差别。站在选型的角度看这种两极分化的说法确实让人困惑。这篇文章就从原理、实测和迁移实操三个层面把 nftables 的性能问题一次说透给出一组可复现的测试方法也聊聊我实际迁移中踩过的坑。无论你是在规划宿主机防火墙、容器网络策略还是维护一台长期运行的网关应该都能找到参考价值。1. 先看清楚 nftables 到底改了什么1.1 Netfilter 框架的一次真正换代传统 iptables 背后的内核框架叫 Netfilter但准确地说过去的 iptables 是一套“多套并行”的控制面体系。IPv4 走 ip_tablesIPv6 走 ip6_tablesARP 过滤走 arp_tables桥接过滤走 ebtables。每一套都有各自的规则表结构、用户态命令和内核模块。你写一条 iptables 规则和写一条 ip6tables 规则虽然命令行外观很像内部分发路径完全是两套代码。这种设计有历史原因早期想在一个框架里统一 IPv4 和 IPv6 并不现实但多年下来维护成本高得吓人而且很多一致性、原子性的问题在旧框架里根本无法优雅解决。nftables 是 Netfilter 项目在 2008 年前后启动的替代方案目标是重新设计一套统一的规则处理框架。内核侧用 nf_tables 模块替代多个旧的 xtables 模块用户侧只需要一个 nft 命令就能同时管理 IPv4、IPv6、ARP、桥接以及 netdev 这类更贴近网卡入口的挂载点。这里有一个经常被忽略的重点nftables 不是给 Linux 打了一个补丁而是把防火墙规则的控制模型整个重做了。规则不再是一堆需要用户态拼装后整体塞进内核的“字节包”而是变成了内核里有结构、有名字、可以被反复引用的对象。1.2 和 iptables、firewalld、ufw 的关系不少人以为 nftables 是 firewalld 的一部分或者认为用 nftables 就必须放弃 firewalld其实不是。firewalld 是一个上层服务管理工具负责把复杂配置转换成具体规则然后交给后端的防火墙程序。RHEL 7 时代 firewalld 的后端还是 iptablesRHEL 8 切到 nftables 后你在 firewalld 上看到的所有富规则和区域配置最终都落到 nftables 的规则集里。Debian/Ubuntu 上的 ufw 也在较新版本里加入了 nftables 后端理由一样。所以你在一个默认开启 firewalld 的系统上执行 nft list ruleset通常能看到一大堆规则那不是别人乱写的正是防火墙服务生成的。反过来你执行 iptables -L 看到的规则也可能是通过 iptables-nft 兼容层转译出来的。也就是说iptables 这条老命令并没有马上消失它只是换了个后端继续存在。这个兼容层对迁移非常友善但也带来一个副作用很多人以为自己写了 nftables 规则实际上只是在兼容模式里继续按 iptables 的思维写规则新框架的高级特性一个都没用上。1.3 控制面的变化比想象中大理解 nftables 的性能差异必须先接受一个观点它最大的革命性改变发生在控制面而不是数据面的每个包都变快。旧框架下的 iptables 规则本质上是一个线性排列的匹配序列。每次新增或删除一条规则用户态命令会把整条规则集重新构建再通过内核接口写入。你可以把这种操作想象成在一份很长的文档里每改一行就要保存一次全篇文档短的时候无感文档长的时候操作延迟就会明显变高。nftables 把规则集拆成“表、链、规则、对象”四个层次。表和链是骨架规则是挂在链里的表达式序列而 set、map、counter、quota 是独立对象。规则可以直接引用这些对象。这带来两个好处一是对象可以复用不需要重复定义二是变更可以批量提交。内核收到的是一组事务化操作要么全部生效要么全部回滚不会有中间状态。对于需要动态更新黑名单、做规则编排的自动化平台来说这个改变的价值远大于那点数字上的快。2. 性能优势到底体现在哪几个地方2.1 规则集加载与动态更新从全量重写到批量事务我实际感受最明显的是规则集加载和更新。iptables 时代一套规则集 200 条看起来不多但如果自动化平台要分几十次增删每一次指令都会触发一次内核规则重组。用脚本配合date %s%N测一下就能发现规则到一定规模后单条增删的耗时不再稳定从几百微秒到几十毫秒都可能跳。原因就在于旧接口每次都要把一套规则网重新搬进去。nftables 则完全不同。所有变更通过 netlink 消息批量下发并且支持事务。同一批规则要么全部生效要么一条都不生效。这意味着什么动态黑名单平台在写入 100 个 IP 时可以一次 nft add element 就完成内核只需插入一组元素到 set 里不再需要重建整条链。即便某些场景仍需通过文件方式重载nft -f 也可以把整个规则集作为一个原子事务提交不会出现重启防火墙时那种“规则加载到一半服务已经可见”的空窗。2.2 集合查找把链式遍历变成哈希或区间查找这是 nftables 在数据面上的核心优势。iptables 处理“封禁 500 个 IP”的思路是给一个链塞 500 条-s x.x.x.x -j DROP规则包进来后从第一条开始逐条比对最坏情况要扫完 500 条才能决定丢弃。规则是从前往后有序的这保证了确定性但代价是匹配次数随规则数量线性增长。nftables 通过 named set 解决了这个问题。你可以把 500 个 IP 放进一个 set然后只写一条ip saddr blackhole drop。内核里 set 的实现是哈希表或者基于区间的红黑树匹配时不用再逐条遍历外部链规则。简单说iptables 是在“排队列表”里找目标nftables 是在“通讯录”里直接翻到那一页。规则数量越大这个优势越明显。如果是几十条规则两者几乎没差别如果几千条甚至上万条数据面差距会变得非常直观。2.3 set、map、vmap 让策略成为数据而不是代码除了 setnftables 还有 map 和 vmap它们解决的是“条件映射到动作”的问题。比如网关要做策略路由想根据源 IP 把流量打到不同路由表旧做法是在链里写很多条-s ip -j MARK --set-mark然后再 ACCEPT每条规则一个动作规则条数等于策略条数。nftables 可以用一个 map 把 IP 和 mark 关联起来一条规则完成查找和赋值。vmap 更进一步可以直接把匹配映射成 verdict。语法类似于给一个集合里的每个元素指定独立动作但查找仍然只有一次。这种能力让复杂的多分支策略规则大幅压缩逻辑上更接近现代编程语言里的“路由表”或“策略表”。规则少了匹配路径短了性能自然受益。而且这类对象是可管理的动态增删策略不用改链结构这是 iptables 很难做到的事情。2.4 内存占用与模块精简很多人只看 CPU 和吞吐忽略了内存。iptables 时代如果 IPv4 规则、IPv6 规则、桥接规则都要用系统可能同时加载 ip_tables、ip6_tables、ebtables 等多套模块每套模块维护自己的规则内存结构。nftables 用一套 nf_tables 内核模块管理所有协议族规则对象可以被多个链引用不用重复存同样的地址列表。我实际在管理大量封禁 IP 的网关上观察过iptables 每条规则对应一次完整规则描述占用内存可能不大但规则数上万后内核内存占用会有明显差别。nftables 把 IP 列表集中到一个 set 里元素存储紧凑得多在大规模地址封禁场景能节省出可观的量。当然绝大多数场景内存不是瓶颈但它确实算是一个附加收益。2.5 为什么有些场景感知不到性能差异这里必须泼一盆冷水。nftables 并不是“所有场景都快十倍”的魔法。如果规则只有几条数据面遍历的代价本来就很低无论用 iptables 还是 nftables转发吞吐都受限于网卡和协议栈换框架解决不了瓶颈。真正能体现差距的场景是规则数量大、匹配路径长、控制面操作频繁。也就是说nftables 的收益有明显的“规模依赖”。还有一点容易被忽略很多所谓的性能对比是在大包 TCP 流场景下做的。这类测试里 Netfilter 规则匹配只占很小一部分开销主要耗时在收包、内存拷贝和协议栈处理。想看到防火墙规则的处理能力差异必须用小包和密集规则去压否则测出来的结论只能说明“网卡挺快”不能说明“防火墙框架更快”。3. 实测数据参考我的测试环境、方法与结果3.1 测试环境先交代清楚性能数据一定要和环境挂钩不然就是耍流氓。我用来跑对比测试的是一台虚拟化服务器CPU 是 Intel Xeon E5-2680 v4 分配给虚机 2 个 vCPU内存 4GB网卡是 virtio系统 Ubuntu 22.04内核 5.15。因为我的使用场景是小型网关所以测试主要围绕 NAT 转发和入站过滤没有用专门的网络测试仪工具是 iperf3、hping3以及简单的 shell 计时脚本。这组环境很普通但正好代表很多个人服务器和小型机房的实际配置。测试时要特别注意任何基准结果都有边界。不同的网卡驱动、中断绑定、内核版本、规则结构都会影响最终数字。下面的结果只说明趋势不承诺在你机器上复现完全相同的数据。若想得到自己可用的数据最好保留同一套压测脚本在做规则结构调整前后分别跑用差值判断优化效果。3.2 规则集加载时间对比我用脚本生成了 1000 条 DROP 规则分别保存成 iptables-restore 格式和 nft -f 格式各跑 20 次取中位数。结果如下规则数iptables-restorenft -f耗时比1000约 350 ms约 45 ms7.8 倍5000约 1.6 s约 190 ms8.4 倍旧框架每加载一条规则都要完成一次从用户态到内核的状态切换规则越多这种固定开销的累积越明显。nft 则把所有规则编译成一条 netlink 消息批量下发固定开销大幅摊薄。这个差距在服务启动、防火墙热重载、故障切换场景中直接关系到业务中断时间。比如双机切换时备机需要在极短时间内把规则集拉起来nftables 的批量提交能更快达到稳定状态对业务中断窗口的影响也更小。3.3 转发吞吐与 CPU 占用大包场景差别不大小包才见真章同一条转发路径上我先用 iperf3 测 TCP 吞吐。我的网络环境是千兆基准无防火墙规则时能跑满 941 Mbps。单独加 50 条入站过滤规则iptables 和 nftables 的吞吐都还能维持在 936 Mbps 左右CPU 占用略有不同nftables 稍低一点。这个结果符合预期大流量大包场景下瓶颈在网卡和协议栈收包路径Netfilter 的规则匹配开销占比较小。真正能拉开差距的是小包场景和规则规模。我用 hping3 构造持续的小包流量并在网关上加 2000 条封禁 IP 的规则。iptables 侧是 2000 条独立的-sDROP 规则nftables 侧是一个包含 2000 个元素的 set。结果小包转发时iptables 的 CPU 占用明显升高出现丢包吞吐掉到约 850 Mbpsnftables 虽然也有下降但保持约 930 MbpsCPU 占用低了约 25%。这就是 set 查找与线性遍历在数据面上的真实差距。如果你只跑大包 TCP 流可能完全测不出这种差异这也是网上评测结论互相矛盾的重要原因。3.4 conntrack 依旧是性能大头别把锅全甩给规则不管用 iptables 还是 nftables连接跟踪机制都是内核里 nf_conntrack 模块负责的。在 nat 或 state 场景下框架本身并不会让 conntrack 变得更快。我做的并发短连接测试里5000 个并发连接下两者表现接近起决定作用的不是规则框架而是 conntrack 表的容量和超时参数。如果默认的 nf_conntrack_max 过小新建连接会丢表现为“网络间歇性卡顿”那时你检查 nftables 规则根本看不出问题。这里分享一个我常用的调优参数。把 net.netfilter.nf_conntrack_max 调到 262144把 net.netfilter.nf_conntrack_buckets 调到 65536同时缩小 TCP 超时时间能明显改善高并发短连接场景的稳定性。buckets 参数建议在模块加载时写入用 sysctl 文件持久化也可以。迁移到 nftables 时这一步往往比纠结规则语法更容易被忽略但从压测结果看它才是网关性能的大头。3.5 如何自己在服务器上复现这组对比如果你也想在自家环境里复测方法并不复杂。先写一个循环生成规则文件比如 1000 条 drop 规则分别输出为 iptables-restore 和 nft 两种格式然后用/usr/bin/time记录真实耗时。不要只在终端里看秒表那会混入太多人为误差。吞吐测试建议用 iperf3 双端测试一组测大包一组用小包。小包可以用-l 64参数控制包大小同时观察对端 CPU 和丢包率。hping3 这类打流工具我只建议在隔离的测试网段里使用别在办公网或生产环境里做 flood很容易把对端交换机或主机直接打挂。测试脚本和规则集都留下来后续做任何优化后重新跑一遍用数据确认收益而不是凭感觉说“好像快了”。4. 实操怎么把常见规则平滑迁到 nftables4.1 基础语法对照迁移第一步是熟悉命令。给一个常用对照表场景iptables 写法nftables 写法放行 22 端口iptables -A INPUT -p tcp --dport 22 -j ACCEPTnft add rule inet filter input tcp dport 22 accept封禁来源网段iptables -A INPUT -s 10.0.0.0/8 -j DROPnft add rule inet filter input ip saddr 10.0.0.0/8 drop默认丢弃iptables -P INPUT DROPnft add rule inet filter input drop记录并丢弃iptables -A INPUT -j LOG --log-prefix bad nft add rule inet filter input log prefix bad drop注意 inet family 同时覆盖 IPv4 和 IPv6写ip saddr时才会匹配 v4 地址写ip6 saddr匹配 v6。如果只想管理 IPv4可以用 ip family 单独建表希望 v4/v6 共用一套表用 inet 更省心。这个选择会影响后续规则的匹配语义建议一开始就定好不然后面混着写容易乱。4.2 用 set 替代大量独立规则这是最关键的一步假设你有一个 200 条 IP 的黑名单iptables 里你会看到 200 行-sDROP。迁移到 nftables 时不要逐条翻译而是直接建一个 set。配置示例table inet filter { set blackhole_v4 { type ipv4_addr flags interval elements { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } } chain input { type filter hook input priority filter; policy accept; ip saddr blackhole_v4 drop } }这里flags interval很关键。写上 interval 后元素里才能放 CIDR 网段内核会用区间树去匹配如果只打算放单个 IP可以不写 interval哈希结构更快。动态增删元素用nft add element inet filter blackhole_v4 { 203.0.113.5 } nft delete element inet filter blackhole_v4 { 203.0.113.5 }实际维护黑名单脚本时我的建议是一次性批量提交元素别一条一条敲。批量提交节省控制面开销也能避免脚本半路失败造成规则集前后不一致。如果元素会被频繁改动可以把 set 定义单独放在一个 nft 文件里用nft -f重载整个文件配合备份和校验脚本一起使用。4.3 map 与 vmap一条规则完成策略路由set 解决的是“是否匹配”map 解决的是“匹配后做什么”。举个例子我想根据来源 IP 决定用哪条路由表传统做法是几十条-s x -j MARK --set-mark规则现在可以用 map 直接把 IP 映射成 mark。table ip mangle { map ip2mark { type ipv4_addr : mark elements { 10.0.0.0/8 : 0x1, 192.168.0.0/16 : 0x2 } } chain prerouting { type filter hook prerouting priority mangle; policy accept; ip saddr ip2mark meta mark set ip saddr map ip2mark } }vmap 则直接映射到 verdict。在网关场景里可以用一张 vmap 表定义“哪些 IP 放行、哪些 IP 丢弃、哪些 IP 跳转到某个自定义链”table ip filter { map relay_vmap { type ipv4_addr : verdict elements { 10.0.0.1 : accept, 10.0.0.2 : drop } } chain input { type filter hook input priority filter; policy accept; ip saddr vmap relay_vmap } }这个写法的好处是策略变成数据而不是代码。新增一种处理策略不需要重新编排链只要往 map 里加条目即可。对自动化系统来说这比解析并重写一长串 iptables 规则安全得多。4.4 和 Docker、firewalld 共存的落地技巧迁移中最容易翻车的其实不是 nftables 语法而是现有体系也在写防火墙规则。Docker 默认通过 iptables 链实现端口映射和容器隔离DOCKER-USER链对很多运维同学来说非常熟悉。如果你把系统切到原生 nftables 后直接清空规则集Docker 的网络策略可能会受影响。稳妥做法是先确认 Docker 版本是否支持 nftables 后端或者至少保留一个轻量的 iptables 兼容层通道不要贸然把旧框架的模块卸载。firewalld/ufw 管理的系统同理。firewalld 的规则最终落到 nftables 后你再手动 nft add 一套规则两者可能在同一个 hook 里叠加导致行为难以理解。最好的做法是选一条管理通道要么用 firewalld 的 rich rule 表达复杂策略要么把系统默认防火墙服务停掉改用自己维护的 nftables 规则文件。混合使用不是不行但必须做好优先级规划否则排查问题时会很痛苦。4.5 一个可以直接上生产的最小规则集示例最后放一个我常用的最小规则集模板适合小型服务器和网关入站过滤。先用nft -f加载再根据实际端口和网段调整#!/usr/sbin/nft -f flush ruleset table inet filter { set lan_nets { type ipv4_addr flags interval elements { 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 } } chain input { type filter hook input priority filter; policy drop; ct state established,related accept iifname lo accept ip saddr lan_nets accept ip protocol icmp icmp type echo-request limit rate 5/second accept tcp dport { 22, 80, 443 } accept counter drop } chain forward { type filter hook forward priority filter; policy drop; ct state established,related accept ip saddr lan_nets accept counter drop } chain output { type filter hook output priority filter; policy accept; } }这个模板的意图很直接本机只放行回连状态、环路、内网网段、ICMP 和常用端口其余入站全部计数并丢弃转发链同理只允许内网发起出站。counter drop放在最后一条可以在nft list ruleset里直观看到被拒绝流量的数量排查时很有用。5. 常见问题与性能排查实录5.1 iptables 命令看到的规则和 nft list ruleset 不一致这个问题经常出现在刚迁移又没完全迁移的系统上。原因通常是系统里同时装了 iptables-legacy 和 iptables-nft 两套后端iptables -L默认展示 legacy 后端而nft list ruleset展示的是 nf_tables 对象。两个框架各自维护规则互不覆盖看起来就像防火墙“没生效”或“规则重复”。排查时先执行iptables --version如果输出里有nf_tables说明当前 iptables 命令走的是兼容层如果是legacy说明还在老框架。Ubuntu 上可以通过update-alternatives --config iptables切换。需要特别提醒的是切换前先确认当前桌面或云平台的安全组是否依赖某个特定后端避免切换后连不上机器。我就是因为在这个环节操作太快吃过一次 SSH 断开的亏。5.2 规则已加载但性能没什么提升如果一个系统从 iptables 迁到 nftables 后完全没有性能变化我见过的主要原因就是把 iptables 规则机械翻译成 nft 语法核心优化一个都没做。典型的例子是仍然写 500 条独立 drop 规则而不是封装成 set。这时nft list ruleset会显示一大串相似规则看着没什么问题但在数据面上依然要做线性匹配。另一个原因是只用了 iptables-nft 兼容层命令变了数据面上的规则对象仍然没有用到 set/map 特性。检查方法很简单看规则里有没有set或map引用没有的话性能提升无从谈起。配置管理平台也需要同步更新否则下次同步规则时又会把旧结构推回去白忙一场。5.3 动态更新集合时报错或删除失败黑名单平台经常要重复添加同一个 IPnft 对重复元素的默认行为可能会让你困惑。如果不需要精确控制重复比较省心的方式是先查nft get element inet filter blackhole_v4 { ip }再决定是否添加。删除元素时如果元素不存在命令会报错脚本里可以加|| true容忍。更稳妥的实践是把整个集合定义为独立文件动态脚本修改的是文件内容最后用nft -f原子重载。这样即使操作出错也不会留下半中间状态的规则集。脚本里还要注意转义和换行尤其是元素列表比较长的时候一个多余的分号就可能让整个文件解析失败。5.4 用 counter 和 monitor 定位性能问题排查防火墙性能问题时别靠感觉。nftables 原生支持 counter可以在关键规则后放一个计数器观察命中次数是否和预期一致。例如nft add rule inet filter input ip saddr blackhole_v4 counter drop带 counter 的规则会记录 packets 和 bytesnft list ruleset能看到数值变化。如果某个环节计数器一直不增长说明流量根本没走到这里或者前面规则已经提前处理了。另外nft monitor可以实时打印规则事件的增删改适合在自动化系统修改规则时观察实际状态。注意生产环境不要一直开着 trace 和 monitor这些调试功能本身也有开销尤其在高流量下会放大 CPU 损耗。我的做法是只在压测或者故障处理时临时开确认完立刻关闭。最后说点个人体会。我在自建网关和公司几台边界设备上把一大批 iptables 规则迁到了 nftables最直接的变化不是“每个包都快了”而是每次做规则变更、看计数器、排查策略冲突时都轻松了不少。如果你的规则集只有几十条迁移与否对转发性能的影响可能微乎其微不必为了追赶技术潮流强行重构但如果规则超过百条或者有动态黑名单、策略路由这类需求nftables 的 set、map、事务式提交省下来的时间属于用过就回不去的那种。性能数据永远是场景的注脚先把场景搞明白再决定要不要切换才不会被各种夸张的基准测试带偏。