非常低的TCP OpenVPN吞吐量(100 port端口，低CPU利用率)

Question

我在两个服务器之间经历了极慢的OpenVPN传输速率。对于这个问题，我将调用服务器服务器A和服务器B。

服务器A和服务器B都在运行CentOS 6.6。这两个服务器都位于数据中心，具有100 Both的线路，在OpenVPN之外的两台服务器之间的数据传输速度接近88 88Mbps。

但是，当我试图通过服务器A和服务器B之间建立的OpenVPN连接传输任何文件时，吞吐量大约为6.5Mbps。

iperf的测试结果：

[  4] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49184
[  4]  0.0-10.0 sec  7.38 MBytes  6.19 Mbits/sec
[  4]  0.0-10.5 sec  7.75 MBytes  6.21 Mbits/sec
[  5] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49185
[  5]  0.0-10.0 sec  7.40 MBytes  6.21 Mbits/sec
[  5]  0.0-10.4 sec  7.75 MBytes  6.26 Mbits/sec

除了这些OpenVPN iperf测试之外，这两台服务器实际上都是完全空闲的，负载为零。

服务器A被分配给IP 10.0.0.1，它是OpenVPN服务器。服务器B被分配给IP 10.0.0.2，它是OpenVPN客户端。

服务器A的OpenVPN配置如下：

port 1194
proto tcp-server
dev tun0
ifconfig 10.0.0.1 10.0.0.2
secret static.key
comp-lzo
verb 3

服务器B的OpenVPN配置如下：

port 1194
proto tcp-client
dev tun0
remote 204.11.60.69
ifconfig 10.0.0.2 10.0.0.1
secret static.key
comp-lzo
verb 3

我注意到的：

1.我的第一个想法是，我正在阻塞服务器上的CPU。OpenVPN是单线程的，这两台服务器都运行英特尔Xeon L5520处理器，而这些处理器并不是最快的。但是，我在iperf测试期间运行了一个top命令，并按下1以查看核心的CPU利用率，发现每个内核的CPU负载非常低：

top - 14:32:51 up 13:56,  2 users,  load average: 0.22, 0.08, 0.06
Tasks: 257 total,   1 running, 256 sleeping,   0 stopped,   0 zombie
Cpu0  :  2.4%us,  1.4%sy,  0.0%ni, 94.8%id,  0.3%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.3%st
Cpu3  :  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu8  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu9  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu10 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu11 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu12 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu13 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu14 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu15 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    946768k total,   633640k used,   313128k free,    68168k buffers
Swap:  4192188k total,        0k used,  4192188k free,   361572k cached

2.在OpenVPN隧道运行过程中，Ping次数大大增加。当iperf不运行时，隧道上的ping次数始终为60 is (正常)。但是，当iperf运行并推动繁忙的交通时，平时就变得不稳定了。您可以在下面看到ping时间是如何稳定的，直到我开始iperf测试时的第4次ping：

PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=60.2 ms
** iperf test begins **
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=146 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=114 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=85.6 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=176 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=204 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=231 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=197 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=233 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=152 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=216 ms

3.如上所述，我在OpenVPN隧道外运行iperf，吞吐量是正常的-88 88Mbps。

我尝试过的：

1.我认为压缩可能会污染事物，所以我通过从信任中删除comp-lzo并重新启动OpenVPN来关闭压缩。没有改善。

2.尽管我以前发现CPU利用率很低，但我认为默认密码可能过于密集，系统跟不上。因此，我将cipher RC2-40-CBC添加到两个信任(非常轻量级的密码)中，并重新启动了OpenVPN。没有改善。

3.我在各种论坛上读到了如何调整片段、mssfix和mtu-tun对性能有帮助的文章。我玩了一些变化，如在这篇文章中描述，但同样，没有任何改进。

对于是什么原因导致如此糟糕的OpenVPN性能，有什么想法吗？

Answer 1

经过大量的谷歌搜索和配置文件的调整，我找到了解决方案。我现在得到了60 60Mbps的持续速度，并突破了80 60Mbps。这比我在VPN之外接收到的传输速率要慢一些，但我认为这将是最好的。

第一步是在服务器和客户端的sndbuf 0配置中设置OpenVPN和rcvbuf 0。

在看到关于在公共论坛帖子 (俄文原文的英文翻译)上这样做的建议后，我做了这个修改，我将在这里引用如下：

现在是2004年7月。发达国家通常的家庭网速为256~1024 Kbit/s，欠发达国家为56 Kbit/s，Linux2.6.7已于不久前发布，2.6.8默认情况下只能在一个月内发布。OpenVPN已经进行了3年的积极开发，2.0版本几乎已经发布。其中一位开发人员决定为套接字缓冲区添加一些代码，我认为应该在OSes之间统一缓冲区大小。在Windows中，如果设置了自定义缓冲区大小，适配器的MTU就会出错，因此最后将其转换为以下代码：

#ifndef WIN32
o->rcvbuf = 65536;
o->sndbuf = 65536;
#endif

如果您使用OpenVPN，您应该知道它可以在TCP和UDP上工作。如果将自定义TCP套接字缓冲区值设置为64 KB，则TCP窗口大小缩放算法不能将窗口大小调整为大于64 KB。那是什么意思？这意味着，如果您通过长胖链接连接到其他VPN站点，即美国到俄罗斯的ping大约100 ms，则在默认的OpenVPN缓冲区设置下，速度不能超过5.12Mbit/S。您需要至少640 KB的缓冲区才能在该链接上获得50 Mbit/s。UDP的工作速度会更快，因为它没有窗口大小，但也不能非常快地工作。正如您可能已经猜到的，最新的OpenVPN版本仍然使用64 KB的套接字缓冲区大小。我们该如何解决这个问题？最好的方法是不允许OpenVPN设置自定义缓冲区大小。您应该在服务器和客户端配置文件中添加以下代码：

sndbuf 0
rcvbuf 0

作者接着描述了如果您自己无法控制客户端配置，如何将缓冲区大小调整推送到客户端。

在进行了这些更改之后，我的吞吐量提高到了20 20Mbps。然后，我看到单个核心的CPU利用率有点高，所以我从客户机和服务器的配置中删除了comp-lzo (压缩)。尤里卡!传输速度提高到60 80Mbps持续和80 80Mbps突发。

我希望这能帮助其他人解决自己的OpenVPN慢问题！

Answer 2

经过几次尝试，我找到了一个很好的解决办法。“就我而言，”埃利奥特的回答没有帮助。在Googling上搜索更多，我发现了这个片段来添加服务器的配置，从而完成了这项工作

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

我有一个小OpenVPN服务器运行在树莓PI3上，现在我有71 Mbps下行链路和16 Mbps上行链路。下载是有限的，因为CPU的能力。现在，我的配置如下：

client-to-client
duplicate-cn
keepalive 10 120
cipher AES-128-CBC
#cipher AES-256-CBC <<<---- lowers the speed to around 50Mbps, still not bad
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
tun-mtu 9000

OpenVPN 2.4.0ARM未知-linux-gnueabihf与OpenSSL 1.0.2l

缓冲区的默认配置仍然存在这样一个问题，这让人感到非常奇怪。

编辑我的client.ovpn文件的结构如下：

client
dev tun
proto tcp
remote SERVER.IP.ADDRESS.HERE
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
tun-mtu 9000
key-direction 1
cipher AES-128-CBC
comp-lzo
verb 1
mute 20
<ca>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
[...]
-----END RSA PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
[...]
-----END OpenVPN Static key V1-----
</tls-auth>

Answer 3

根据Config，您正在使用TCP作为隧道的传输。考虑使用UDP而不是TCP，因为堆叠的TCP连接帐篷在丢包情况下会产生问题。

作为参考参见为什么TCP通过TCP是个坏主意