ipset高大上性能果断将nf-HiPac逼下课

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的流量控制算法的不同而带来的结果不同。

<a href="http://s3.51cto.com/wyfs02/M02/53/76/wKioL1RoLA6Q7fbGAADbuPwrkTY217.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M00/53/76/wKioL1RoLETRlZ2MAAHQCQjm5Y8352.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M00/53/78/wKiom1RoK-zip0rpAABx2FBEWVE656.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M01/53/76/wKioL1RoLGzCqKExAABobSaPyzA485.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M02/53/76/wKioL1RoLHzTyUg0AACrffkth7A598.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M00/53/76/wKioL1RoLI3ARp4iAAHjAK8IdJg524.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M00/53/78/wKiom1RoLDWzh1GNAACDhCJLcC4339.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M01/53/76/wKioL1RoLLTBWO1mAAINl1dLjXs776.jpg" target="_blank"></a>

这个结果足以让nf-hipac下课了。另外我觉得，nf-hipac下课也有它自己的原因，它从来没有做到内核模块化和用户程序即编译即使用，为内核打patch，重新编译等就会吓退很多有心者。

       最近关于iptables的工作并不在其本身的性能优化，而是代码感观上的优化，比如nftables项目等。

 本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1577114