喜欢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框架本身。
另外我觉得。nf-hipac下课也有它自己的原因。它从来没有做到内核模块化和用户程序即编译即使用,为内核打patch。又一次编译等就会吓退非常多有心者。
近期关于iptables的工作并不在其本身的性能优化。而是代码感观上的优化,比方nftables项目等。
原文:http://www.cnblogs.com/mengfanrong/p/5080321.html