玩转高性能超猛防火墙nf-HiPAC

中华国学，用英文讲的，稀里糊涂听了个大概，不得不佩服西方人的缜密的逻辑思维，竟然把玄之又玄的道家思想说的跟牛顿定律一般，佩服。归家，又收到了邮件，还是关于nf-hipac的，不知不觉就想彻底整理一篇文章说个明白，可是哪有个够啊哪有个够。
       匆匆吃完晚饭，碗也没刷，餐桌狼藉，家人都在看电视，玩手机，小小依然捧着iPad...我的摊子如下：

 

 

       如果说理论分析不足以镇住人，或者说一上来就讲理论可能把人吓跑，还是先来点感官上的体验吧。

0.感官感受

执行下面的命令： 如此一来，系统中添加了将近2000条nf-hipac规则，iperf的测试结果如下：

 

 

二者的对比相当明显，最后我们来看一下既没有iptables又没有nf-hipac规则的时候，iperf的结果：

 

 

显而易见，nf-hipac加载20000个条目的结果和裸奔的结果是几乎一致的，这是多么令人兴奋的一件事啊！

1.如何使用nf-hipac

1.0.确认内核版本

很不幸，nf-hipac并非以一个可加载的内核模块存在，它是内核的一个patch。需要重新配置内核和重新编译内核才能使用它。除此之外，它对内核版本特别挑剔，官网可下载的最新版本早在2005年就终结了，因此它只是在2.6.13内核版本上可用(说是14，15，16，18都可以，我没有试)。因此我不得不退回到Debian4上去，然后在kernel.org上下载一个2.6.13版本的内核并着手nf-hipac的编译工作。
       幸运的是，我已经决定将其做成一个可以加载的内核模块了，并且支持2.6.32以及以上的内核。今晚开始了移植工作，基本分为几块的工作量：
a.适配match/target内核API
b.适配netlink内核API
在还没有完成模块化之前，只能在2.6.13上打patch了。能我相当信心的是，nf-hipac的内核补丁事实上是在net/ipv4/netfilter目录下的一个子目录nf-hipac，所有的文件全部在里面，并未对任何内核关键的数据结构打补丁，因此nf-hipac完全可以作为一个模块进行编译。

1.1.下载它

在网站http://www.hipac.org/上下载最新的nf-hipac-0.9.1.tar.bz2，这个版本是个终结版，此后再也没有更新，不知道作者哪去了。

1.2.编译它

解压缩nf-hipac-0.9.1.tar.bz2，进入user目录，执行make install PREFIX=/usr/local IPT_LIB_DIR=/usr/local/lib/iptables，很容易就编译成功了。

1.3.为内核打patch

进入新下载的2.6.13内核的根目录：

cd /home/kernel/linux-2.6.13

为内核打上patch：

patch -p1 -F3 < /home/kernel/nf-hipac-0.9.1/nf-hipac-0.9.1.patch

配置.config文件，我使用了Debian GNU/Linux 3.1的config文件：

cp /boot/config-2.6.8-4-686-smp /home/kernel/linux-2.6.13/.config

然后make menuconfig：
加入一个版本后缀
General setup  --->  (hipac) Local version - append to kernel release
选中nf-HiPAC
Networking  ---> Networking options  ---> 
    [*] Network packet filtering (replaces ipchains)  ---> 
        IP: Netfilter Configuration  ---> 
            <M>   nf-HiPAC support (High Performance Packet Classification)
            [*]     Single path optimization
保存.config

1.4.编译内核

直接编译：

cd /home/kernel/linux-2.6.13
make -j4
make modules_install
mkinitrd -o /boot/initrd.img-2.6.13hipac /lib/modules/2.6.13hipac
depmod -a 2.6.13hipac

修改/boot/grub/menu.lst，使用新的vmlinuz-2.6.13hipac启动系统
系统启动完成

1.5.执行命令

除了iptables换成nf-hipac之外没有任何别的区别，但是要注意，所有的iptables的match都被nf-hipac支持，但是并不意味着iptables的match可以内置到nf-hipac的dimtree中实现高效匹配，只有nf-hipac内置的match才可以实现高效dimtree匹配，这些match的共同特点就是它们的值域可以“区间化”。下面是一个nf-hipac支持的列表：
Options:
  --proto       -p [!] proto    protocol: by number or name, eg. `tcp‘
  --source      -s [!] address[/mask] or
                       address[:address]
                                source(s) specification
  --destination -d [!] address[/mask] or
                       address[:address]
                                destination(s) specification
  --in-interface -i [!] devname
                                network interface name
  --jump        -j target
                                target for rule
  --numeric     -n              numeric output of addresses and ports
  --out-interface -o [!] devname
                                network interface name
  --verbose     -v              verbose mode
  --line-numbers                print line numbers when listing
  [!] --fragment -f             match second or further fragments only
  --version     -V              print package version.
----------
TCP options:
 --syn                          match when only SYN flag set
 --not-syn                      match when not only SYN flag set
 --source-port [!] port[:port]
 --sport ...
                                match source port(s)
 --destination-port [!] port[:port]
 --dport ...
                                match destination port(s)
----------
UDP options:
 --source-port [!] port[:port]
 --sport ...
                                match source port(s)
 --destination-port [!] port[:port]
 --dport ...
                                match destination port(s)
----------
ICMP options:
 --icmp-type typename           match icmp type
                                (or numeric type or type/code)
                                see also: nf-hipac -h icmp
----------
STATE options:
 --state [!] [INVALID|ESTABLISHED|NEW|RELATED|UNTRACKED|ESTABLISHED,RELATED]
                                State to match
----------
TTL options:
 --ttl   value[:value]          match time to live value(s)
----------
如果nf-hipac命令中出现了iptables的match，比如从/lib/iptables目录加载的libipt_set.so中的ipset match以及任何iptables的match模块，最终都要排在dimtree的叶子节点进行独立的iptables匹配过程。代码里面已经很清晰的表明了这一点。nf-hipac的HOOK函数是hipac_match，该函数首先进行例行的高效的HiPAC算法匹配，然后找到一个叶子节点，该叶子节点可能体现出两种行为：

a.它就是纯粹的nf-hipac的rule，此时叶子指示一个target：

 

if (likely(IS_RULE(t))) {
    return ((struct dt_rule *) t)->spec.action;
}

b.它在nf-hipac规则中夹杂了iptables的match(这些match从/lib/iptables/目录下加载)，此时需要进行iptables的例行匹配，这种匹配不是按照HiPAC算法高效执行的，而是使用iptables的算法慢速遍历的：

/* initialization required to prevent compiler warning */
action = 0;

for (i = 0; i < ((struct dt_elem *) t)->ntm_rules.len; i++) {
    rule = ((struct dt_elem *) t)->ntm_rules.p[i];
    if (HAS_EXEC_MATCH(rule)) {
        for (j = 0; j < rule->exec_match->len; j += 2) {
            // 此处的match_fn就是常规的在一条iptables规则中遍历匹配所有的
            // match，iptables中拥有很多不可区间化的match这是可以理解的
            action = match_fn(packet,
                    rule->exec_match->p[j],
                    rule->exec_match->p[j + 1]);
            if (action != MATCH_YES) {
                break;
            }
        }
        if (action == MATCH_NO) {
            continue;
        }
        if (action == MATCH_HOTDROP) {
            return TARGET_DROP;
        }
...
    }
}

1.6.procfs中的统计信息

nf-hipac模块加载了之后，会在procfs的net目录下注册自己，其中的/proc/net/nf-hipac下的info文件中有下面一行：
nf-hipac is invoked before iptables
如果你想让iptables首先进行匹配，那么请执行：

echo iptables-first> /proc/net/nf-hipac/info

其/proc/net/nf-hipac/statistics目录下有关于hipac规则树的一些统计信息，目前只有3个链被支持。

2.nf-hipac是怎么做到的

nf-hipac相比较iptables，性能那叫一个帅！相比ipset则不相上下，然而nf-hipac在综合效果上则是介于iptables和ipset之间的一个being。它是怎么做到的。
       iptables的规则在内存中是线性排列的，内核的HOOK通过遍历这些规则链进行逐一匹配，这个逐一匹配的顺序内含了优先级的概念，首先加入的rule首先被匹配到。但是除了这个顺序的排列之外，规则之间再也没有了别的关联，因此很难将它们作为一个整体来进行优化。
       ipset将ip地址，端口等统一进行管理，但是同一个集合中的元素只能采取统一的动作，即target，虽然在ip地址的匹配中极端高效，但是使用起来很不灵活，很难做到比如同在set中的ip1和ip2执行不同的-j target动作。ipset是将单一的match统一管理进行优化的，和多条iptables规则没有必然的关系，即它没有将多条iptables规则关联起来。
       除了傻傻的线性排列，除了单一match的hash/tree统一管理，iptables和match，target之间还能有别的关系吗？即它们之间还能有别的排列方式吗？当然有，这就是nf-hipac的方式。nf-hipac采用了另一种排列方式，即将固定的match进行排序，也就是说将每一条规则拆开来，这就就可以化不确定为确定。确定的是match的总的种类，不确定的是规则的数量，最终确定的match的数量决定了树的高度，而这个不确定的规则数量影响的仅仅是树的广度，仅此而已。

       下面的一幅图非常复杂，是我听完嘉定中华国学后在我的餐桌上画的，已经很晚了，无所事事，睡不着，也没喝酒，所以就兴奋了。图示如下：

 

 

拆散了一条条的rule之后，剩下的就是将match和target组成一棵树了，事实上rule并没有被拆散，所谓的rule就是若干的match和一个target，在右边这棵树中体现的就是每一个树节点的match层次，最下层的优先级最高，这就体现了rule的配置顺序，rule的配置顺序体现的就是优先级。
       nf-hipac不更新了，没人维护了，难道是作者因此找到好的工作了，难道是作者结婚了，难道是作者生孩子了...这种判断也太中国化了，反正就是不更新了...单单谈效率，ipset完全可以让nf-hipac下课，但是谈点别的之后，nf-hipac的优势就显现出来了。

3.破除超猛nf-hipac的神话

有破有立，方可不败。
       如果我们结合上面的图仔细分析为何添加了20000条左右的nf-hipac，性能依然不受任何影响，就会发现，nf-hipac的匹配过程最多经过n层的树深度，而n是match的数量，在这20000条规则中，match的数量只有1个！！注意了，这就是关键，1个！如果使用iptables，那么匹配的过程最多经过m个rule。也就是说，nf-hipac将m个rule拆散了之后，将其中所有的match压缩成了n层的树，每一层拥有m个层的区间交集匹配，这些交集仅仅决定其下层树节点的rule交集。照此说来，很多的数据包从第一个match集合(所有rule的第一个match组成的集合)树根开始匹配，一旦rule的match交集变成空，就可以直接下决断“没有匹配的rule”了，所以即便是少数种类的match集合节点，一个数据包也不一定能从树根匹配到最后一个match集合。这就是nf-hipac超猛的根本原因。
       对于nf-hipac树的查找，需要注意的是，如果不是叶子节点，执行流只会碰触到最先配置的那条rule，即最下面的那条，其余的rule被隐藏在该最下面rule的上面，它们的作用仅仅是告诉执行流，该区间的下面的分支树节点是所有这些rule的交集，仅此而已。
       从iptables到nf-hipac的变化是：从遍历m*n次(m为rule的数量，n为每一个rule的match的数量)简化为了遍历n次(n为所有rule中最多match的那一条rule的match的数量)。之所以如此就是因为nf-hipac将所有的rule作为一个整体来优化。那么代价是什么？代价就是插入rule，删除rule的开销。插入一条rule，首先需要将其所有的match拆分开来，然后找出每一个树节点的位置，即rule的插入位置，然后准备将这些match分别插入到那些位置中，是否插入取决于那个位置有没有对应rule的match交集，如果没有，则不予插入，删除的过程类似，也需要进行比较复杂的计算。
       那么有没有什么办法让nf-hipac变得低效呢？很显然，当你了解了nf-hipac的dimtree的构造之后，你就会明白，n的数量越大，效率越低，n是什么？n是match的种类的数量。整个tree的深度就是n，如果自己构造20000种左右的match，那么试试看，仅仅配置一条nf-hipac规则，整个tree的构造将变成深度为2000的倒立的链表...我之所以仅仅设置一条nf-hipac规则是因为如果设置了多条，反而可能由于中途rule的match交集为空而提前退出遍历树。但是幸运的是，对于一个数据包那么多种的match是不必要的。