有感于netfilter的转发效率

本文档的Copyleft归yfydz所有,使用GPL发布,可以自由拷贝,转载,转载时请保持文档的完整性,严禁用于任何商业用途。
msn: [email protected]
来源: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.★
	

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


猜你喜欢

转载自cxw06023273.iteye.com/blog/867072