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项目等。