解析：为何OpenVPN相对于单纯路由性能下降很多?

    OpenVPN相对于单纯路由来说，性能下降很多，那么主要的因素是什么呢？相对于单纯路由功能，OpenVPN主要是添加了：

　　1，虚拟网卡TUN到应用层再由UDP发送的过程。
　　2，传输加解密部分。
    这里进行了另一项测试，即在不加密的状态下测试，做法很简单，将OpenVPN配置文件中的cipher段改成cipher none即可。
    新的传输数据如下图：

    看得出，转发速率略有提高，达到了1.3～1.4万/秒，大约提高了15%左右，但这与直接route测试结果相比仍然有很大差距，因而说，对于小包来说，OpenVPN做加解密的消耗并不是主要的，更多的消耗是因为它的工作机制。
    此外，我在66主机的系统上测试了CPU加解密能力，使用OpenSSL的speed操作，摘几个我们关心的算法如下：

　　type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
　　des ede3          7831.31k     7924.27k     7958.27k     7972.18k     7981.74k
　　blowfish cbc     32325.64k    34821.07k    35421.81k    35609.51k    35388.90k
　　aes-128 cbc      28142.41k    37398.85k    40835.93k    41901.40k    42246.14k

    简单的说，加解密算法中AES128的速度是比较快的，接近每秒40兆（64字节），也就是说如果只是要满足百兆网络加解密需要，PIII 1G CPU只需要利用30%即可。
    然后我们再来看一下这个模式下VPN所在主机的CPU消耗：

    依然是从最后一条垂直短红线处开始，CPU占用率85%，还是CPU作为瓶颈。

    最后，我再来测试中等长度包（udp 512）对VPN的要求，这里依然使用AES128，如下图所示：
   

    发包速率在1万左右，换算成流量大概是5Mbytes。对VPN主机的CPU消耗如下图（从最后一条垂直红线处开始）：

    再来试一下中等包时候，加密操作对OpenVPN的影响，下图是无加解密时对OpenVPN进行udp 512字节包测试数据：

    发包速率到了1.2万左右，相对加密模式，提高了20%左右，比64字节测试的同比提升率高，这也是很容易解释的，随着包变大，流量变大，因而加解密操作所消耗的CPU也变高。

    同样，看一下这时候VPN主机的CPU使用率：

    去掉加解密之后，CPU由90%降到85%，也是符合逻辑的，因为现在只有包转发和内存拷贝（DMA操作）了。
    再来看看udp数据长度为1400的大包，如图：

    发包速率降到了6000～7000/秒，但流量却到了9.5Mbytes上下。再来看看VPN主机的CPU占用率：
   

    这次CPU占用有了提升，接近95%，这是因为大量数据压缩更耗CPU，这也说明了一点：PIII 1G CPU是不足以让OpenVPN跑满100M网络的，即使是1400多字节的大包。
    最后，还有一个测试，就是试试多CPU对OpenVPN的影响，我将66/68两台主机换成PIII 1Gx2，并且打开Linux的SMP支持，这样OpenVPN会不会性能翻倍呢？

    发包数据如下图：

    不幸的是，发包速率几乎没有任何变化，那么OpenVPN对双CPU的利用率如何呢？见下图：

    VPN CPU利用率保持在52%左右，也就是说，实际上有一个CPU是几乎空闲的，这也说明目前的OpenVPN并不支持多路CPU（我看到过OpenVPN好像有实验性的多线程支持，但不知道怎么打开，将来不排除OpenVPN将来会对多CPU的支持）。