netfilter，sourceforge，github上有一个凄凉的项目，那就是nf-hipac，这个曾经给Linux firewall设计带来希望的项目早在2005年就停止了更新和维护，而我本人则是在2007年才被曹老师带上道的...知道hipac则是2012年的事，曾经在2.6.13上编译成功，获得了声称的所谓高性能，后来我的工作大部分都在2.6.32上进行，由于2.6.32引入大量2.6.13上没有的机制，也由于版本间隔太多，内核API不兼容，hipac移植到2.6.32上费了不少劲，消耗了好几个本来应该干点别的的夜晚。
       事实上，曾经，我对hipac是很认可，理由之一就是我发现它是“用规则来匹配数据包”的，而不是像iptables那样“用数据包来匹配规则”的，毫无疑问，Cisco和华为等厂商的硬件设备几乎都是使用这种方式来匹配ACL的，当我发现Linux上的hipac可以使用软件来实现类似机制时，当然会兴奋一阵子的。另外一个理由则是，我一直都比较认可多个match的并行匹配，这样可以很好的利用多个CPU核心，现在我认为我的这第二个理由完全是胡扯！cache missing，DCA，DMA且不多说，光是调度开销就已经抵销掉了并行匹配的优势，如果没有专门的硬件来进行matching offload，就不要在软件层面用CPU去做这种转瞬即逝的事情，换句话说，那就是match匹配的粒度太小了，大炮不是用来打蚊子的，CPU是流水化作业的，没有规划好流水线的执行流是不适合CPU来执行的。
       喜欢hipac就只剩下了第一个理由！当我试用了ipset之后，发现hipac真的是个鸡肋项目，并且完全违背了UNIX的原则！怎么说呢？要知道如果我需要禁掉10000个IP地址，用iptables的-s，-d的话，就需要10000条规则，来了一个数据包就需要顺序匹配这10000条规则，注意，是一个一个比对。能不能反过来，让这10000个IP自己发现它们是否包括这个数据包的IP地址呢？这就需要将这10000个IP地址作为一个整体来对待，hipac项目实现的要旨就是这样，内部会将这10000个IP地址组织成一个便于高效查找的数据结构，而不是像iptables那样逐条匹配。然而ipset更适合做这件事，而且更符合UNIX的原则。
       如果我们用诸如hipac的方案，我会这样添加10000个IP地址规则(我使用了iptables的语法)：
hipac -s ip1 -j DROP
...
hipac -s ip10000 -j DROP
写法上和iptables一样，只是内部将这些IP地址组织成了树或者hash表，如果既要匹配源又要匹配目标的话，每条规则只需要稍微复杂一点：
hipac -s ip1 or -d ip1 -j DROP
...
hipac -s ip10000 or -d ip10000 -j DROP
显然，一条规则包含了两个匹配，完成了两件事。如果我用ipset的话，则是完全分开了所有的事情：
ipset create srcset hash:ip
ipset create dstset hash:ip
ipset add srcset ip1
...
ipset add srcset ip10000
ipset add dstset ip1
...
ipset add dstset ip10000
iptables -A FORWARD -m set --match-set srcset src -j DROP
iptables -A FORWARD -m set --match-set dstset dst -j DROP
依然用的是iptables，最后我贴出性能测试的结果后就会发现，iptables本身并不是性能瓶颈，如果说10000条规则确实降低了性能，那么错误在于你添加了10000条规则。完全可以将iptables作为一个机制而不是策略，你需要优化的是match而不是iptables框架本身。

       以下是我的性能测试结果，注意这是一个相对值而不是绝对值，因为我是在虚拟机上跑的。因此我就不贴硬件配置了。另外，我用的是UDP，这样只能从丢包上看性能了，摆脱了TCP的流量控制算法的不同而带来的结果不同。

1.裸跑，没有iptables，没有ipset

2.使用ipset，添加超级多的IP地址

3.使用iptables，添加10000条左右iptables

这个结果足以让nf-hipac下课了。另外我觉得，nf-hipac下课也有它自己的原因，它从来没有做到内核模块化和用户程序即编译即使用，为内核打patch，重新编译等就会吓退很多有心者。
       最近关于iptables的工作并不在其本身的性能优化，而是代码感观上的优化，比如nftables项目等。