折腾了一下午空压机，失败，作罢！作为一个搞IT的，虽然不会去关注怎么修主板，但起码还是会持续关注自己感兴趣的那一面的，比如iptables，Netfilter等，对于空气压缩机，Python，气缸，C++对象模型之类的，不是我的菜啊！
在论坛看到有人吐嘈，简短的一句话：
ipfwadm.. ipchains.. iptables.. nftables... progress sucks. :(
是啊，我也这么觉得！
记 得2006年毕业后的实习，曹老师让我第一次知道有个东西叫做iptables，好几个月，真的是好几个月，我都搞不清楚 table，chain，rule的区别，此后换工作后再也没有遇到过曹老师那样肯不厌其烦教我的人，因此对于iptables的理解也就暂时搁置了，直 到后来知道了Netfilter之后，才真正彻底理解了iptables。对iptables，谈不上什么感觉，我一直把它当成一个基于 Netfilter的工具，并且一直对它的遍历匹配方式不认可。
既然有了iptables，工程师就有了工具，大家都是只是用用而已，加上几年前都是100M网络，它的性能问题基本不是问题，所以iptable也就不 仅仅是用用而已了，简直成了一件利器，直到1000M卡的到来，iptables基本就被排除在高性能网关之外了。那么以前精通iptables的人会受 冷落吗？会的。但是如果你精通Netfilter，那就不会。你可以用ipset，你可以用nf-hipac，你可以用conntrack卸载硬件，它们 都是基于Netfilter的框架实现的，即它们都是对Netfilter的填充。
事实上，懂iptables，甚至精通iptables的人从来都没有懂JAVA或者C++的人吃香，因为iptables并不是编程范畴，注定永远被排 出在程序员圈子之外，对于系统管理范畴，Python，Perl也比Linux上的某个单独的工具比如iptables，snort受关注更普遍，那么对 于网管呢？很显然，Cisco，H3C认证工程师是看不上iptables的。因此iptables就这样被排除了，它和任何职业的挂钩都显得很勉强，它 成了鸡肋。类似的，snort也一样。然而，我却独爱这类小工具，并一直保持着对它们的跟踪，当我深入了解了它们之后，发现，虽然它们可能并不会独自登上 大雅之堂，但是你可以在很多地方发现它们的身影，以及它们的思想。
OpenWRT，这是一个我极端看不上的项目，有点欺世盗名的感觉，但是它却极端成功！也许很多人都知道这个OpenWRT，但是却不知道WRT。 OpenWRT其实就是保留了WRT的功能接口而已，旨在复制一个自由的WRT，那么WRT是什么？它是Cisco公司的Linksys路由器版本。我不 晓得WRT使用了什么技术，但是我知道OpenWRT使用了iptables这类很多人都看不上的小东西。
iptables sucks？yes！ 自 Linux初创，一直都在寻找高效的包分类框架，直到有了Netfilter之后，框架的构建工作才彻底交给了框架的填充者，内核mainline本身只 提供了Netfilter本身之后，再也不过问江湖之事了。一路跌跌撞撞的探索，从BSD的ipfw到ipchains，然后就是iptables，后来 发现iptables结构太不妙，代码不紧凑，于是有了nftables，总之坎坷依然正在进行，但是已经和内核没有关系了。即便和内核没有关系，内核中 不还是有x_tables.c吗？将这部分替换成nftables吗？如何联络这部分的kernel维护人员？这都是问题。
按照Linux模块的开发风格，一般都是一个内核模块外加一个用户utils工具集，也就是说程序的开发者需要提供这两部分的内容。这一点 上，xtables-addons项目做的比较好。然而xtables-addons是在iptables的框架内执行的，它可分离开发的只是 match/target模块而已，iptables的主干却还是不敢伤筋动骨。也就是说，xtables-addons只是iptables的扩展，正 如它的名字所表达的那样。因此nftables替换iptables的进程就不再仅仅是一个模块/utils配对开发的过程，而是一个平滑过渡的过程，兼 容性的支持又一次成了撒旦。
平滑过渡的需求也最终确定了nftables进入内核的过程将是一个漫长的过程。
nftables相比iptables性能有提高吗？能驾驭10G环境吗？no，no，no...这不是nftables的职责范围，它要是能作为一个通 用框架存在，使得nf-hipac这样的好东西不再需要自己注册nf_hook_ops的话，那就是它的成功。它要是能提供一套简单易用的API，可以快 速开发match/target，像xtables-addons一样，那就是它的成功，如果它甚至可以让你自定义匹配方式，比如使用hipac算法，使 用hash tuple算法，或者可以自定义包分类算法，那就是它的成功。
在论坛看到有人吐嘈，简短的一句话：
ipfwadm.. ipchains.. iptables.. nftables... progress sucks. :(
是啊，我也这么觉得！
记 得2006年毕业后的实习，曹老师让我第一次知道有个东西叫做iptables，好几个月，真的是好几个月，我都搞不清楚 table，chain，rule的区别，此后换工作后再也没有遇到过曹老师那样肯不厌其烦教我的人，因此对于iptables的理解也就暂时搁置了，直 到后来知道了Netfilter之后，才真正彻底理解了iptables。对iptables，谈不上什么感觉，我一直把它当成一个基于 Netfilter的工具，并且一直对它的遍历匹配方式不认可。
既然有了iptables，工程师就有了工具，大家都是只是用用而已，加上几年前都是100M网络，它的性能问题基本不是问题，所以iptable也就不 仅仅是用用而已了，简直成了一件利器，直到1000M卡的到来，iptables基本就被排除在高性能网关之外了。那么以前精通iptables的人会受 冷落吗？会的。但是如果你精通Netfilter，那就不会。你可以用ipset，你可以用nf-hipac，你可以用conntrack卸载硬件，它们 都是基于Netfilter的框架实现的，即它们都是对Netfilter的填充。
事实上，懂iptables，甚至精通iptables的人从来都没有懂JAVA或者C++的人吃香，因为iptables并不是编程范畴，注定永远被排 出在程序员圈子之外，对于系统管理范畴，Python，Perl也比Linux上的某个单独的工具比如iptables，snort受关注更普遍，那么对 于网管呢？很显然，Cisco，H3C认证工程师是看不上iptables的。因此iptables就这样被排除了，它和任何职业的挂钩都显得很勉强，它 成了鸡肋。类似的，snort也一样。然而，我却独爱这类小工具，并一直保持着对它们的跟踪，当我深入了解了它们之后，发现，虽然它们可能并不会独自登上 大雅之堂，但是你可以在很多地方发现它们的身影，以及它们的思想。
OpenWRT，这是一个我极端看不上的项目，有点欺世盗名的感觉，但是它却极端成功！也许很多人都知道这个OpenWRT，但是却不知道WRT。 OpenWRT其实就是保留了WRT的功能接口而已，旨在复制一个自由的WRT，那么WRT是什么？它是Cisco公司的Linksys路由器版本。我不 晓得WRT使用了什么技术，但是我知道OpenWRT使用了iptables这类很多人都看不上的小东西。
iptables sucks？yes！ 自 Linux初创，一直都在寻找高效的包分类框架，直到有了Netfilter之后，框架的构建工作才彻底交给了框架的填充者，内核mainline本身只 提供了Netfilter本身之后，再也不过问江湖之事了。一路跌跌撞撞的探索，从BSD的ipfw到ipchains，然后就是iptables，后来 发现iptables结构太不妙，代码不紧凑，于是有了nftables，总之坎坷依然正在进行，但是已经和内核没有关系了。即便和内核没有关系，内核中 不还是有x_tables.c吗？将这部分替换成nftables吗？如何联络这部分的kernel维护人员？这都是问题。
按照Linux模块的开发风格，一般都是一个内核模块外加一个用户utils工具集，也就是说程序的开发者需要提供这两部分的内容。这一点 上，xtables-addons项目做的比较好。然而xtables-addons是在iptables的框架内执行的，它可分离开发的只是 match/target模块而已，iptables的主干却还是不敢伤筋动骨。也就是说，xtables-addons只是iptables的扩展，正 如它的名字所表达的那样。因此nftables替换iptables的进程就不再仅仅是一个模块/utils配对开发的过程，而是一个平滑过渡的过程，兼 容性的支持又一次成了撒旦。
平滑过渡的需求也最终确定了nftables进入内核的过程将是一个漫长的过程。
nftables相比iptables性能有提高吗？能驾驭10G环境吗？no，no，no...这不是nftables的职责范围，它要是能作为一个通 用框架存在，使得nf-hipac这样的好东西不再需要自己注册nf_hook_ops的话，那就是它的成功。它要是能提供一套简单易用的API，可以快 速开发match/target，像xtables-addons一样，那就是它的成功，如果它甚至可以让你自定义匹配方式，比如使用hipac算法，使 用hash tuple算法，或者可以自定义包分类算法，那就是它的成功。
nftables sucks？NO！
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1581339
