iptables高性能前端优化 无压力配置1w 条规则

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

                       

产生本文的故事

这显然是个周末，这是一个下雨的周末，这是一个台风登陆的周末…

  上周，有一个很猛的台风“天鸽”，当天红警晚发了两个小时，当发布红警时，几乎所有人都到了公司，当然，除了那些怕西装和皮鞋被雨淋湿的经理。我本来是想特别感谢一下这个台风的，然而它已经造成了重大的人员伤亡，无论如何，我都不能再对它多说一句褒义的话，我是一个喜欢风雨的人，仅诠释我个人。

  在台风“天鸽”将至的那晚，我把一个在暴热和加班中被遗忘搁置的问题重新拿了出来，开始了一番探究…

  就在三天后，台风“帕卡”将至，我写了本文。所以我把本文定位为两个接踵而至的台风刺激下写的一篇技术散文，而不是技术指导，技术指导性的文档需要相当的理性，而我现在只有狂风暴雨，和酒。

动机

又有人咨询我关于几千条iptables规则造成收包性能急剧下降的问题了，iptables再次背了锅。

  自从2009年底开始，就不断有人天天强调基于Linux内核Netfilter的iptables以及Netfilter本身会造成性能下降，这种声音最后一次听是在昨天下午！

  这么多年来，发出这种声音的很多人甚至根本就理不清iptables和Netfilter的关系，更是对其内部原理一无所知，大部分都是人云亦云，也不知道是谁第一个说的，反正后面就跟着把故事流传了下来。也许第一个这么说的是国外一位大牛，针对特定场景提到了这么一个结论，很多人断章取义就认为这是在否定iptables本身…

  我被很多公司面试过，也面试过很多别人，在我被问及关于Netfilter相关的问题时，我知道他们的意思是想知道如何优化它，天啊，你自己可能都不知道Netfilter的问题在哪，何谈优化，不破哪有立…当我面试别人的时候，我也会问关于Netfilter相关的，但我的问题往往是：你觉得Netfilter有问题吗？

…

  我不止一次地强调过，iptables没有错，Netfilter也没有错！

  是的，你可能用“几千条iptables规则确实造成了性能下降”，“一打开conntrack性能就会下降”这种来反驳我，但我马上就能怼回去：这是Netfilter的问题吗？然而这是iptables的问题吗？

  规则配的太多导致性能下降是因为你iptables玩的不精！

  conntrack造成性能下降那是conntrack自己的问题，为什么让Netfilter背锅？！

  我之前写过几篇关于nf-HiPAC的文章，它即使配置20000+条规则也不会造成收包性能下降，然而它也是基于Netfilter的。更具讽刺意义的是，你们可能对APPEX(华夏创新)这个公司有所耳闻，是的，它是做加速的，请注意，我在强调“加速”二字，人家的加速竟然用了Netfilter！虽然彼性能不是此性能，一个是TCP的性能，一个是主机CPU性能，但为了榨取哪怕0.1%的CPU性能，如果Netfilter有大问题，APPEX会用它吗？

  即便你认识到了问题出在iptables而不是Netfilter，你还是有别的选择的，比如你可以试试nf-HiPAC，不过我敢保证你不一定能玩得起来，这玩意儿资料很少，中文的估计也就我那几篇了…另外的选择就是用ipset，这个很常规，也很朴素，它只是一个iptables的模块，在你的match是IP地址的情况下，使用ipset完全可以解决几千条规则导致的性能下降问题。

  我知道你不想重写规则，更不想去编译安装什么nf-HiPAC，ipset之类的新东西，你只想保留你的8347条iptables规则，然后用很有点拿来主义经理的口吻问我：别的我不能动，但是性能下降必须控制在10%以内。

  虽然这并不关我毛事，但还是感觉受到了威胁，还好，感谢台风“天鸽”，“帕卡”，让我有了一个新的思路，解除了威胁。

声明：

1.本文的解决方案是纯iptables方案，不涉及nf-HiPAC和ipset，需要了解这些的请参考下面两篇文章：
《可编译易用的模块化nf-HiPAC移植成功》
《于Linux-2.6.32内核上编译ipset-6.23的坎坷经历》

2.本文不是一个关于新技术的HowTo，它只是一个新想法，有很多TODO。如果问这东西的代码在哪里，那只能等温州皮鞋厂老板了。

已有的优化方案

抛开本文的背景(比如不能修改规则集之类的)，如果你确实觉得iptables性能很不行，然后希望优化的话，你做的第一件事可能就是去google或者去百度，你会发现一系列现成的方案，比如：

• 使用state match

比如你可能会加入下面的一条规则在所有规则最前面：

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
  
  
  

   
1
  

你期望着用流而不是数据包来进行匹配，但你可能不知道的是，流依赖了conntrack机制，而该机制也是饱受诟病的因素之一。

• 使用自定义chain

在很多论坛上，有很多人早就提出了使用-N选项创建不同的chain，然后肉眼归类所有的规则，尽量把具有同一性的规则分配到单独的chain中，这样整个规则集就分层了。
  这正是本文要描述的模型的朴素版本。

• 使用nf-HiPAC或者ipset

这个就不多说了，效果相当好！

• …

这里给出一个关于iptables性能测试的链接，可以关注一下：
《Netfilter Performance Testing》
值得一提的是，在这篇文档中，提及了一些优化手段，其中包括一个叫做Compact Filter (CF)的项目，我觉得是比较有意思的，然而其链接已经失效，后来找到了一篇论文：
《An Interval Decision Diagram Based Firewall》
这个设计正是采用区间匹配来快速定位Action的，跟我将要通篇描述的方案几乎是一致的，感兴趣的可以看一下。

其实，iptables如何优化，方案几乎也就两类：

 

1.重写内核过滤机制

比如nf-HiPAC，ipset之类就属于这类。

 

在用户态优化规则集

比如Compact Filter (CF)，精心设计自定义chain跳转，以及本文描述的n+1模型就属于这类。

  如果上面这些你都觉得太简单或者说已经看过了了解过了，那么本文剩余的部分将要介绍的这个可能是你第一次听说。

优化方案补遗

在我终于完成了这篇冗长的文章后，我顺势google了一下关于iptables优化的一些枝枝蔓蔓，希望能找到一些好玩的东西，如果能找到，那简直是比吃一顿大餐还要更爽的，加上外面狂风暴雨，舒坦地难以言表。

  我还是找到了，我找到了下面这个：
《Optimizing the Interval Decision Diagram Im-plementation in the CF Firewall》
我不得不说，快速扫完了这个之后，我是激动的(在完成本文前，我一直想找到有关Compact Filter (CF)的资料，但没有找到)。这份资料几乎完整地阐述了一个跟我的n+1模型一模一样的方案的优化版本，同时在这份资料的开头表明了Compact Filter (CF)是一个非常大众化的方案，不然的话，为什么大家都往一起想呢？

  虽说这份资料让我希望成为首先提出类似想法的那批人成为了泡影(同样的方案出现于2005年之前！那时我还才刚刚参加完高考…)，然而，令我依然感到欣慰的是，至少我用一个直观的立体几何模型而不是