有感于netfilter的转发效率

本文档的Copyleft归yfydz所有，使用GPL发布，可以自由拷贝，转载，转载时请保持文档的完整性，严禁用于任何商业用途。
msn: yfydz_no1@hotmail.com
来源：http://yfydz.cublog.cn

一个数据包进入netfilter后，首先组碎片，组完后就得查一遍当前的连接表(第一个表，HASH链表结构)，虽然是HASH的，但数量一大每个链表里节点还是不少；如果如果查不到，得先分配内存建立连接信息，然后查期待子连接列表(第二个表，链表)，这个表是单一线性表，一般情况下这个表倒是不太长，找到发现是子连接的话要和主连接绑一下，最后根据各个IP协议的处理检查一下数据包的合法性，这才完成数据包的前期操作，这个是在用户层不可控，由netfilter自动完成的；然后就得查目的NAT表(第3个表，数组结构)，匹配了的话进行目的NAT，否则进行一个空绑定，每个后续包都要到这个绑定函数里操作一番，然后进行路由表查找(涉及的路由表和路由cache，也需要查表，但和netfilter无关)；然后或者转发，或者进入本机；如果转发，需要查转发链的规则表(第4个表，数组结构)进行过滤；然后数据包进入POSTROUTING点，和PREROUTING的目的NAT 类似，这里是进行源NAT，同样要查源NAT规则表(第5个表，数组结构)，有规则的按规则转换，没规则的进行地址不变的转换，然后再次进行绑定操作，最后发出。

有此可见，一个包进了netfilter要查至少5个表，其中连接状态表是数量最大的，所以也用HASH形式处理，其次应该属于转发链的过滤表，如果不把状态检查规则放前面的话，每个后续包检查的规则也不会少，尤其是作流量控制；另外前后两次NAT绑定操作也是特别费性能的操作，而且如果本身不进行NAT，也得进行空绑定操作，空绑定时所有流程也走一遍，并没简化，校验和又都白算一遍，浪费。综合种种，难怪内核加了netfilter后性能被砍一半。

发表于： 2006-09-04，修改于： 2006-09-04 08:47，已浏览3167次，有评论4条 推荐 投诉
	网友： Godbach 	时间：2008-08-05 17:52:23 IP地址：219.238.94.★


因此，如果说部使用NAT的功能时，是不是可以考虑用一个内核模块实现iptables和静态表的功能，而不用内核现成的呢。


	网友： Godbach 	时间：2008-08-05 18:03:33 IP地址：211.100.11.★


端木兄的这篇文章其实也相当于把netfilter对数据包的处理进行了流程性的分析，对我很有帮助，谢谢。


	网友： Godbach 	时间：2008-08-05 18:13:10 IP地址：211.100.11.★


一个包进了netfilter要查至少5个表

-------------------------------------

这个地方应该是最多查5个表吧。如果是发往本机的包，则不需要FOWARD和POSTROUTING。所查的表应该少于5个吧。


	网友： Godbach 	时间：2008-08-05 20:46:14 IP地址：219.238.94.★


惭愧。没看清楚题目，题目本来就是说的转发的效率。