【IT168 报道】最近对OpenVPN产生了不少兴趣，从网上对OpenVPN的评论来看，它的性能似乎并不太好，但却很难找到相应的数据来证明这点，为此我做了一些传输方面的测试，开放出来，也希望对感兴趣者有用。

　　确认OpenVPN的传输效率，看其能否满足常见需要及对资源的使用率。目标数据包括小包（64字节以太网帧）转发速率，中大包（512/1400字节UDP包）转发速率及资源占用率。

　　1，发包工具：一个udp程序，包含客户端和服务端两部分，客户端尽可能快速的发送udp包给服务器并等待回应，然后对数据进行统计，并以图形化方式反映结果。其性能可保证每秒收发80000小包，后面会看到，这个性能对于本测试是足够的。

　　2，确认VPN设备工作在单纯路由模式的性能，即同一硬件在完全不运行OpenVPN，Linux只做IP包转发时的性能。

　　测试过程对丢包的假设是在包发送后1秒钟内如果收不到回应即认为丢包，这个在测试的局域网环境下是适当的，收发包程序本身的检测功能也证明了这个丢包估计时间可行。

　　注意：本文里虽然主机在不同测试中其IP对应的网络段可能不同，但其IP最后一位数字均相同，因而会使用46、56等数字表示机器。

　　下图是该测试程序在无丢包状态下，稳定运行半小时的收发64字节以太网帧（UDP长度18字节）包速率，大概在80000包/秒：

　　测试单纯路由性能的原因是与VPN性能做对比，因为原理上OpenVPN相对于单纯的Linux kernel包转发只是多了一个虚拟网卡，多了两次内核/应用层数据拷贝，网络拓扑如下：

　　在66、68两台主机上打开ip_forwading充当路由器，并在四台主机上适当配置路由策略，保证7网段与8网段经6网段互通。

　　该图显示，通过路由设备后64字节以太网帧的速度只能达到47000左右，比测试程序直连模式下低了40%左右，这种情况表明路由的某种资源已经成为瓶颈从而导致发包程序无法达到全速（80000/s），这是受何种资源所限呢？对路由主机进行分析后，我认为是CPU达到了满载，见下图：

　　该图是充当路由器的66主机上CPU的使用率，其中最后一条垂直红线之后部分对应本次测试，即CPU在90%以上这段连续红线。在整个测试中，充当router的主机CPU使用率总是不能达到100%，这个我有一些其他推测，但这里，我认为CPU是瓶颈。也就是说，这台主机做路由时最多只能每秒转发47000个包。

　　说明一下我推测的CPU不能100%运行的原因：我认为CPU不能达到100%可能是因为网卡和PCI总线之间、内存与内存之间的传输方式引起的，一般来说这种传输采用DMA方式，在传输的这段时间里CPU因为总线被占用，也没有其他工作，因此总是看起来不能到100%。X86的结构比较复杂，这个推测仅供讨论参考。

　　接下来进行OpenVPN的性能测试，使用66、68两台主机分别模拟OpenVPN的服务端、客户端，基本拓扑如下：

　　与router模式相比，66、68两台主机配置成OpenVPN，并且路由不再将7网段的包经由6网段转发到8网段，而是经由10.6.0.*网段转发，这是一个典型的OpenVPN配置例子。

　　一般来说，OpenVPN应用模式是一台专用OpenVPN服务器对多个用户电脑上的OpenVPN客户端，这里为OpenVPN客户端也使用专用主机的原因是尽量减少其他因素的影响。

　　这里使用了AES-128-CBC作为传输加密算法而没有使用OpenVPN默认的blowfish，原因是我对blowfish没有了解。

　　收发包速率降到了1.2万/秒，只相当于纯路由模式的25%，而在该模式下，运行VPN服务器的主机CPU使用率如下图：

　　对应数据是后半段（最后一条垂直红线之后），这段曲线显示VPN主机的CPU使用率已达到90%，也认为是CPU满载。

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

　　这里进行了另一项测试，即在不加密的状态下测试，做法很简单，将OpenVPN配置文件中的cipher段改成cipher none即可。

　　看得出，转发速率略有提高，达到了1.3～1.4万/秒，大约提高了15%左右，但这与直接route测试结果相比仍然有很大差距，因而说，对于小包来说，OpenVPN做加解密的消耗并不是主要的，更多的消耗是因为它的工作机制。

　　此外，我在66主机的系统上测试了CPU加解密能力，使用OpenSSL的speed操作，摘几个我们关心的算法如下：

　　简单的说，加解密算法中AES128的速度是比较快的，接近每秒40兆（64字节），也就是说如果只是要满足百兆网络加解密需要，PIII 1G CPU只需要利用30%即可。

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

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

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

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

　　去掉加解密之后，CPU由90%降到85%，也是符合逻辑的，因为现在只有包转发和内存拷贝（DMA操作）了。

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

　　这次CPU占用有了提升，接近95%，这是因为大量数据压缩更耗CPU，这也说明了一点：PIII 1G CPU是不足以让OpenVPN跑满100M网络的vpn如何看国外网站，即使是1400多字节的大包。

　　最后，还有一个测试，就是试试多CPU对OpenVPN的影响，我将66/68两台主机换成PIII 1Gx2，并且打开Linux的SMP支持，这样OpenVPN会不会性能翻倍呢？

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

　　前面测试了一些OpenVPN的传输性能数据，实际情况中，OpenVPN还有一些需要测试的性能，比如新建连接速率，并发连接率等等，但这些东西需要模拟OpenVPN专用的客户端协议，现在还做不了。而这次测试并没有考虑如正常通信过程中的其他用户新建连接消耗等因素，因而性能可能略高于实际使用情况。

　　1， OpenVPN主要使用的资源是CPU，PIII 1G的CPU并不足以满足百兆网络需求。

　　2， OpenVPN相对于普通Linux路由转发性能下降很多，小包转发能力（12000：47000）只相当于Linux纯路由的25%左右。而中大包对Linux路由器来说瓶颈已经不是CPU，而是百兆网卡了。

　　3，?OpenVPN整体资源消耗中，加解密部分占用部分少，各种大小的包使用与不使用加密算法对应的数据分别为：

　　不同包大小（udp data length）包及不同VPN加解密算法下的OpenVPN包转发性能NoneAES-128-CBC00065004，? 一条与结论3相关的扩展结论是有关加密卡的使用：我并不认为加密卡能大幅提高OpenVPN性能，主要有两点原因：

　　b，厂家支持Linux/OpenSSL的加密卡驱动运行在内核态，使用加密卡意味着更多的内核用户空间内存拷贝，特别对于小包而言，使用加密卡可能比CPU更慢；

　　5，OpenVPN目前缺乏对多CPU支持，因而想使用多CPU来提高VPN性能不可行的，综合3、4、5，想提高OpenVPN性能最简单的办法是提高单个CPU运算能力，比如PIII 1G换P4 3G。

　　6，最后，稳定性，这里没有列出OpenVPN稳定性的测试数据，但据我测试，这个东西做的还好，我连续满负荷运行一个星期至少没有问题。