ipset高大上性能果断将nf-HiPac逼下课
其实。以前。我对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框架本身。
1.裸跑，没有iptables，没有ipset
2.使用ipset，加入超级多的IP地址
3.使用iptables，加入10000条左右iptables
这个结果足以让nf-hipac下课了。
另外我觉得。nf-hipac下课也有它自己的原因。它从来没有做到内核模块化和用户程序即编译即使用，为内核打patch。又一次编译等就会吓退非常多有心者。
近期关于iptables的工作并不在其本身的性能优化。而是代码感观上的优化，比方nftables项目等。