Linux 内核是一个快速发展的项目，但有时候一些改动的进展仍是出乎意料的缓慢。替换内核数据包过滤子系统(packet-filtering subsystem)的 nftables 项目起源于 2008 年，但仍未被大多数(甚至可能更多)生产系统中的防火墙场景使用起来。不过，正如 8 月 19 日发布的 nftables 1.0.0 所强调的那样，这一变化可能已经越来越近了。
第一个公开的 nftables 版本是由 Patrick McHardy 在 2009 年初发布的。当时，内核有一个以 iptables 这个形式存在的具备类似功能的数据包过滤子系统，当然，它虽然一直被人们广泛使用，但有一些问题促使着人们提出了改动。这些问题包括：内核存在着(并且现在仍然是这样)好几个包过滤机制：一个用于 IPv4，另一个用于 IPv6，还有一个用于 ARP，等等。这些子系统中的每一个基本上都是完全独立的，有很多重复代码。除此之外，iptables 还包含了太多的内置协议相关的信息，并且 API 比较难用，所以很难在不替换整个规则集的情况下来更新其中的一个规则。
nftables 核心理念是要丢弃所有的协议感知(protocol-aware)那些机制，取而代之的是一个可以从用户空间来开发配置的简单的虚拟机。管理员仍然可以写出一些涉及到特定的数据包头字段之类的规则，但用户空间的工具会将这些规则转化为更底层的获取和比较操作，然后将生成的东西加载到内核中去。这样一来数据包过滤引擎就更加小巧灵活了，可能会表现更好。总的来说，一旦能将大量用户过渡过来的话，应该是一件有好处的事情。
nftables 在推出时引起了一些轰动，但后来就陷入困境并从人们的视线中消失了，也许是因为 McHardy 花了更多精力去进行更多的法律诉讼了。不过在 2013 年的时候 Pablo Neira Ayuso 重新启动了这个项目，他的想法是尽快将代码并入主线，在这一点上他成功了，在 2014 年初的时候 nftables 进入了 3.13 内核。
此后的工作一直是在努力填补空缺功能，使 nftables 能具有足够的吸引力让用户愿意迁移过来。编写过滤规则的语言已经获得了许多许多功能，包括有状态跟踪(stateful tracking)、创建地址映射、高效处理地址间隔(address intervals)和大规模的规则链，以及支持了众多协议。当然，还包括文档。nftables 维基页面就有很多信息介绍这一切是如何工作的。
当然，要让大家从 iptables 过渡过来，还有一个很大的阻碍：大量早已部署的、使用 iptables 的防火墙。在许多情况下，重写防火墙规则可能是最好的行动方案，因为许多复杂的过滤配置在新方案中可以更有效地表达出来。但是，对于那些只想让他们之前辛辛苦苦开发出来的防火墙能继续工作的管理员来说，nftables 可能就没有人们想象的那么吸引人了。nftables 的开发者已经开发了一套脚本，将 iptables 防火墙翻译成 nftables 的描述，这应该会有所帮助，但迁移仍是一个很大的变化。
某些情况下，用户可能实际上会在不知不觉中完成这个大转变。Linux 发行版中已经支持 nftables 一段时间了，而且正在努力将红帽的 firewalld 等工具移植到 nftables。这样以来，用户可能一开始接触到的就不是 iptables 规则，因此他足够幸运的话，就完全不会注意到底层机制已经改变了。
这种变化何时会发生呢?还有点难说。2018 年 Netfilter 研讨会宣称，iptables 是“一个过时的工具”，它的日子已经不多了。2019 年的 Debian 10 “buster” 版本中默认切换到了 nftables，而 Ubuntu 直到 21.04 版本才跟进。虽然几乎所有的发行版都搭载了 nftables，但很多还没有默认使用起来。
nftables 1.0.0 的发布可以被看作是一个信号，即现在是那些落伍者需要更认真地考虑进行切换的时候了。虽然 iptables 的支持应该不太可能会很快地被移除掉，但完全可以预料到维护 iptables 的热情会持续减弱。新的功能将会在 nftables 中出现，而用户最终则需要迁移过来才能利用好这些新功能。虽然 只 花了 13 年时间，但这个过渡似乎终于要进入最后阶段了。
不过还有一个有趣的问题。2018 年 BPF 开发者宣布了 bpfilter，一个运行在 BPF 虚拟机上的数据包过滤机制，在当时引起了一些关注。BPF 过去的发展势头非常好(而且现在也保持着)，它做了很多工作来优化虚拟机并使其可以安全地工作。可以说，合理的策略应该是使用它，而不是维护另一个单单只用于包过滤工作的虚拟机。这样就可以去掉一堆代码，把维护工作集中在 BPF 上。
bpfilter 代码在 4.18 内核发布时被包含了进去，并且带来了一个“用户模式 blobs”机制，旨在促进防火墙规则向新方案的转变。然而，从那时起这段代码的开发就停止了。在 2021 年间，net/bpfilter 的代码只有两次(而且都是微不足道)的修改。2020 年 6 月讨论了要不要删除这段代码，但当时它幸存了下来。从那时起，尘封的蛛网只会越积越厚，似乎可以判断说，bpfilter 目前并不是一个在活跃开发的领域，而且它似乎也不太可能很快取代 nftables 了。
还很难说这个判断是否是“正确的”。也许 nftables 所使用的专门用途的虚拟机比起通用用途的 BPF 能更好地解决这个特有领域的问题。或者说，nftables 之所以能够胜出，仅仅是因为它背后的开发者持续活跃着并推动着项目的发展。内核开发成功的关键之一很简单，就是要有持续性。对于像数据包过滤这样关键的子系统来说，这一点更是如此，知道开发人员是长期投入参与进来的，是会让人们非常安心的。
