有感于netfilter的转发效率(ZZ)

本文档的Copyleft归yfydz所有，使用GPL发布，可以自由拷贝，转载，转载时请保持文档的完整性，严禁用于任何商业用途。msn: 来源：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后性能被砍一半。