OpenVPN之所以性能不尽人意是因为数据包在协议栈和OpenVPN应用程序中绕来绕去的，经过了许多的“门”，每一个门都有自己的宽度限制，即使不考虑门的宽度，单单是进进出出就是性能损耗点。典型的门如下：
1.加密/解密：一个明文数据块进入加密引擎，出来密文，一块密文数据进入解密引擎，出来明文。
2.OpenVPN的socket通信：socket通讯必须使用系统调用，而系统调用的开销在数据量很小的时候则是很大的。
3.数据包的分段：受限于网卡的MTU，凡是超过MTU的数据都要被分段，OpenVPN的MTU限制有两个：虚拟网卡的MTU以及OpenVPN socket使用的物理网卡的MTU。
OpenVPN性能有待提高说的是OpenVPN针对上面的几个门，都有提高性能的希望。总的思想就是提高单位路径的吞吐量，降低门开销的比重，实际上只要增加了虚拟网卡的MTU，加密/解密，socket系统调用等开销就会跟着降低，因为后面两个因素直接受制于从虚拟网卡进来的数据的大小，最后物理网卡的MTU限制如今已经不是问题了，因为几乎所有的千兆网卡都有TSO的功能。总之，让CPU一次尽可能久一些地去做一件事是核心的核心，也许把这叫做“记忆CACHE”比较好，正比如你连续写10个“你”，再连续写10个“好”，要比连续写10个“你好”要快一样，因为不仅仅数据本身有cache可以提速，更重要的是，思维的转换需要消耗一定的计算周期，连续写10个“你”再连续写10个“好”只需要转换一次，而连续写10个“你好”却需要转换20次。
测试结果：
OpenVPN配置：
IP地址：服务端(物理地址，虚拟地址)/客户端(物理地址，虚拟地址)：4.4.4.2，12.0.0.1/4.4.4.1，12.0.0.2
虚拟网卡的MTU：50000
使用协议：TCP(82574L的Linux驱动[芯片？]不支持UFO，为了体现TSO，使用了TCP)
额外配置：mssfix设置为0，这样就可以让OpenVPN可是直接送入虚拟网卡的mtu这么大的数据到加/解密引擎
网卡：82574L Gigabit
千兆卡直连网络基准数据：
iperf -c 4.4.4.2
------------------------------------------------------------
Client connecting to 4.4.4.2, TCP port 5001
TCP window size: 27.9 KByte (default)
------------------------------------------------------------
[ 4] local 4.4.4.1 port 16618 connected with 4.4.4.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 6.6 sec 784 MBytes 992 Mbits/sec
测试1：
cipher：BF-CBC
auth：MD5
测试1结果：
iperf -c 12.0.0.1 -F /lib/init/rw/big
------------------------------------------------------------
Client connecting to 12.0.0.1, TCP port 5001
TCP window size: 148 KByte (default)
------------------------------------------------------------
[ 4] local 12.0.0.2 port 23921 connected with 12.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 677 MBytes 568 Mbits/sec
测试2：
cipher：BF-CBC
auth：none
测试2结果：
iperf -c 12.0.0.1 -F /lib/init/rw/big
------------------------------------------------------------
Client connecting to 12.0.0.1, TCP port 5001
TCP window size: 148 KByte (default)
------------------------------------------------------------
[ 4] local 12.0.0.2 port 23923 connected with 12.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 9.6 sec 784 MBytes 687 Mbits/sec
测试3：
cipher：none
auth：none
测试3结果：
iperf -c 12.0.0.1
------------------------------------------------------------
Client connecting to 12.0.0.1, TCP port 5001
TCP window size: 148 KByte (default)
------------------------------------------------------------
[ 4] local 12.0.0.2 port 23925 connected with 12.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 7.1 sec 784 MBytes 923 Mbits/sec
以上结论可以看出，使用BF-CBC算法不验证摘要的情况下，千兆环境的性能几乎达到了满载性能的70%，，若不加密，基本逼近裸带宽，十分可观！可见OpenVPN的瓶颈30%在加解密，将近70%在MTU导致的数据块太小！到此为止，我们对待加密解密还仅仅是尽可能的一次性送入足够多的数据，如果能有针对加解密本身的优化就更好了，这就需要使用诸如加密卡之类的东西了。
通过上面的测试，我们得到了可观的性能数据，然而当把OpenVPN作为路由时，50000这么大的MTU值实际上是没有什么用的，因为事实上几乎没有这么大的数据包在网上通行。只有在本机出发的数据包经过虚拟网卡时，这个超大的MTU才能更好的发挥作用。事到如今，性能问题已经不是OpenVPN的错了，而是物理链路的容量问题了，通过调整物理网卡的MTU，还是可以达到上述那个可观的性能数据的，然而在端到端的意义上，中间的链路很大程度上是我们不能触动的。虽然现在不是OpenVPN的错，但是你要知道，OpenVPN是调整了MTU之后才提升了本身的性能的，要想端到端的性能提高，必须让所有链路设备配合提高MTU，而这是不现实的。因此，本文所展示的OpenVPN的性能极限没有可实施的意义，在物理链路MTU瓶颈不问题被解决前，本文仅仅是纸上谈兵，到了物理链路真的不再是问题的时候，调整虚拟网卡MTU才会有现实意义，目前，OpenVPN的性能瓶颈还是在加密/解密的效率上，在你无法一次送入大块数据的时候，唯一的方法就是提高单位加解密的效能了。
总结：
0.在OpenVPN作为路由节点部属的时候：
1.当OpenVPN虚拟网卡的MTU很低的时候，瓶颈在系统调用次数多，加解密块太小；
2.当OpenVPN虚拟网卡的MTU很大的时候，瓶颈在端到端链路中间最小MTU太小；
3.既然OpenVPN虚拟网卡MTU不能太大也不能太小，那就不要设置它；
4.如果有条件，那就使用加密卡或者使用支持加密的CPU提高单位加解密速度；
5.等到链路最小MTU很大的时候，再把OpenVPN虚拟网卡的MTU提升，总之，虚拟网卡MTU要保持和最小MTU一致。
1.加密/解密：一个明文数据块进入加密引擎，出来密文，一块密文数据进入解密引擎，出来明文。
2.OpenVPN的socket通信：socket通讯必须使用系统调用，而系统调用的开销在数据量很小的时候则是很大的。
3.数据包的分段：受限于网卡的MTU，凡是超过MTU的数据都要被分段，OpenVPN的MTU限制有两个：虚拟网卡的MTU以及OpenVPN socket使用的物理网卡的MTU。
OpenVPN性能有待提高说的是OpenVPN针对上面的几个门，都有提高性能的希望。总的思想就是提高单位路径的吞吐量，降低门开销的比重，实际上只要增加了虚拟网卡的MTU，加密/解密，socket系统调用等开销就会跟着降低，因为后面两个因素直接受制于从虚拟网卡进来的数据的大小，最后物理网卡的MTU限制如今已经不是问题了，因为几乎所有的千兆网卡都有TSO的功能。总之，让CPU一次尽可能久一些地去做一件事是核心的核心，也许把这叫做“记忆CACHE”比较好，正比如你连续写10个“你”，再连续写10个“好”，要比连续写10个“你好”要快一样，因为不仅仅数据本身有cache可以提速，更重要的是，思维的转换需要消耗一定的计算周期，连续写10个“你”再连续写10个“好”只需要转换一次，而连续写10个“你好”却需要转换20次。
测试结果：
OpenVPN配置：
IP地址：服务端(物理地址，虚拟地址)/客户端(物理地址，虚拟地址)：4.4.4.2，12.0.0.1/4.4.4.1，12.0.0.2
虚拟网卡的MTU：50000
使用协议：TCP(82574L的Linux驱动[芯片？]不支持UFO，为了体现TSO，使用了TCP)
额外配置：mssfix设置为0，这样就可以让OpenVPN可是直接送入虚拟网卡的mtu这么大的数据到加/解密引擎
网卡：82574L Gigabit
千兆卡直连网络基准数据：
iperf -c 4.4.4.2
------------------------------------------------------------
Client connecting to 4.4.4.2, TCP port 5001
TCP window size: 27.9 KByte (default)
------------------------------------------------------------
[ 4] local 4.4.4.1 port 16618 connected with 4.4.4.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 6.6 sec 784 MBytes 992 Mbits/sec
测试1：
cipher：BF-CBC
auth：MD5
测试1结果：
iperf -c 12.0.0.1 -F /lib/init/rw/big
------------------------------------------------------------
Client connecting to 12.0.0.1, TCP port 5001
TCP window size: 148 KByte (default)
------------------------------------------------------------
[ 4] local 12.0.0.2 port 23921 connected with 12.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 677 MBytes 568 Mbits/sec
测试2：
cipher：BF-CBC
auth：none
测试2结果：
iperf -c 12.0.0.1 -F /lib/init/rw/big
------------------------------------------------------------
Client connecting to 12.0.0.1, TCP port 5001
TCP window size: 148 KByte (default)
------------------------------------------------------------
[ 4] local 12.0.0.2 port 23923 connected with 12.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 9.6 sec 784 MBytes 687 Mbits/sec
测试3：
cipher：none
auth：none
测试3结果：
iperf -c 12.0.0.1
------------------------------------------------------------
Client connecting to 12.0.0.1, TCP port 5001
TCP window size: 148 KByte (default)
------------------------------------------------------------
[ 4] local 12.0.0.2 port 23925 connected with 12.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 7.1 sec 784 MBytes 923 Mbits/sec
以上结论可以看出，使用BF-CBC算法不验证摘要的情况下，千兆环境的性能几乎达到了满载性能的70%，，若不加密，基本逼近裸带宽，十分可观！可见OpenVPN的瓶颈30%在加解密，将近70%在MTU导致的数据块太小！到此为止，我们对待加密解密还仅仅是尽可能的一次性送入足够多的数据，如果能有针对加解密本身的优化就更好了，这就需要使用诸如加密卡之类的东西了。
通过上面的测试，我们得到了可观的性能数据，然而当把OpenVPN作为路由时，50000这么大的MTU值实际上是没有什么用的，因为事实上几乎没有这么大的数据包在网上通行。只有在本机出发的数据包经过虚拟网卡时，这个超大的MTU才能更好的发挥作用。事到如今，性能问题已经不是OpenVPN的错了，而是物理链路的容量问题了，通过调整物理网卡的MTU，还是可以达到上述那个可观的性能数据的，然而在端到端的意义上，中间的链路很大程度上是我们不能触动的。虽然现在不是OpenVPN的错，但是你要知道，OpenVPN是调整了MTU之后才提升了本身的性能的，要想端到端的性能提高，必须让所有链路设备配合提高MTU，而这是不现实的。因此，本文所展示的OpenVPN的性能极限没有可实施的意义，在物理链路MTU瓶颈不问题被解决前，本文仅仅是纸上谈兵，到了物理链路真的不再是问题的时候，调整虚拟网卡MTU才会有现实意义，目前，OpenVPN的性能瓶颈还是在加密/解密的效率上，在你无法一次送入大块数据的时候，唯一的方法就是提高单位加解密的效能了。
总结：
0.在OpenVPN作为路由节点部属的时候：
1.当OpenVPN虚拟网卡的MTU很低的时候，瓶颈在系统调用次数多，加解密块太小；
2.当OpenVPN虚拟网卡的MTU很大的时候，瓶颈在端到端链路中间最小MTU太小；
3.既然OpenVPN虚拟网卡MTU不能太大也不能太小，那就不要设置它；
4.如果有条件，那就使用加密卡或者使用支持加密的CPU提高单位加解密速度；
5.等到链路最小MTU很大的时候，再把OpenVPN虚拟网卡的MTU提升，总之，虚拟网卡MTU要保持和最小MTU一致。