一.引子

别的就不多说什么了，前面的文章说过，Open×××有两个瓶颈，一个是tap网卡，另一个是加密/解密，然而不可否认，Open×××的客户端和服务器端处于一个“虚拟网段”，抛开虚拟不谈，只要是一个网段的，我们就可以说它们属于一个局域网(当然前提是使用tcp/ip网络)，既然属于一个局域网，那么它要么是广播的，要么是点对点的，不管怎样，两端都有确定的三层地址(IP地址)，所有的数据包都是通过这个三层地址来传输到对端的，因此为了使得路径畅通，我们只关心路由即可。
     既然是链路层网络(即使它是虚拟的，我们称为EoTAP-Ethernet Over Tap)，我们就可以使用链路层的端口聚合来增加带宽或者加强稳定性，类似一个局域以太网的两台机器可以直连或者通过交换机间接相连，Open×××的服务器和客户端也可以被认为是通过tap网卡连接的“虚拟局域网”，那么它们之间的连接也可以使用端口聚合。
     对于Open×××来讲，×××链路的“虚拟物理链路”其实就是两个Open×××进程(Open×××客户端和服务器)之间的真实物理链路(我们知道，从tap网卡发出的数据进入了tap字符设备，然后进入Open×××进程，随着Open×××进程间的真实物理链路到达对端，然后进入tap字符设备，最终被tap接收...)，因此我们完全可以将4个Open×××进程绑成两个虚拟链路通道。
     对于负载均衡策略来讲，同一链路层(不管是点对点网络还是广播网络)网段使用端口聚合的方式，而网络层的负载均衡需要使用分割网段的方式。对于Open×××连接的两端，不管它们跨越了多少物理链路层网段，由于存在于同一个虚拟链路层网段，它们就适合用端口聚合的方式进行负载均衡，这里的“端口”就是Open×××进程。
     如果你的机器拥有16核的cpu或者16个cpu以及8257X或者8259X的网卡芯片，对端也拥有同样的配置，仅开启一对Open×××进程的话，大量的资源将被无情浪费，这是Open×××本身造成的，它是单进程单线程程序，无法利用多核cpu，tap网卡一帧一帧的处理方式和物理网卡芯片的能力严重不匹配，由于tap的处理方式，物理网卡也要一帧一帧发送(这些帧和tap出来的帧的区别仅仅在于它将数据加密处理后加了一层tcp/ip协议栈的封装)，因此何不启用16对Open×××进程，一个cpu上绑一个，然后在每一端将16个Open×××进程打开的tap网卡全部绑定在一起，这样不就相当于16个端口聚和了吗？
二.环境
1.服务器端的Open×××配置文件server1/2.cfg：
dev tun
proto tcp
tls-server
cipher BF-CBC
keepalive 10 60
mode server
server 172.16.0.0 255.255.0.0
local 0.0.0.0
lport 1194
dh dh1024.pem.dh
ca ca.pem
cert server.pem
key  server.key
配置文件2仅将lport改为1195即可
2.客户端Open×××配置文件client1/2.cfg：
client
float
dev tun
proto tcp
remote 192.168.1.22 1194
ca ca.pem
cert client.pem
key  client.key
cipher BF-CBC
3.内核为2.6.32，bonding支持sysfs的配置方式
4.备注：
4.1.之所以使用tun模式而不是tap模式是因为Open×××服务器进程作为一个虚拟的交换机对arp有所过滤，因此需要修改一些Open×××的代码后才能更好更稳定的支持bonding，否则只能使用bonding的active-backup模式，且fail_over_mac参数也要设置。tun模式就不存在这个问题，它不发arp，只是点对点，有路由即可。
4.2.多个Open×××服务器的虚拟ip必须一致，且保证这些Open×××服务器一对一的分配给同一台机器的所有Open×××客户端的虚拟也必须一致，因为Open×××服务器要验证客户端ip地址的，bonding了之后，所有的客户端将统一于唯一的一个ip地址。
配置文件2仅将remote的端口改为1195即可
4.3.为何使用2.6.32的内核，实际上如果使用2.6.8这么老的内核用本文的方式是配不通的，因为老的内核没有使用sysfs配置bonding，而是使用了ioctl，这样的话，由于tap网卡驱动不支持bonding相关的ioctl参数，那一切都是没有意义，这里也体现了ioctl地狱是真实存在的。需要各方面联合才行，为了支持bonding，不得不修改tap驱动，增加其ioctl参数。
三.配置
1.在服务器上启动两个Open×××：
root@zyxx:~/***# open*** --config server1.cfg
root@zyxx:~/***# open*** --config server2.cfg
2.在客户端上启动两个Open×××：
root@zyxx:~/***# open*** --config client1.cfg
root@zyxx:~/***# open*** --config client2.cfg
3.配置服务器端bonding：
3.1.载入bonding模块
root@zyxx:~/***#modprobe bonding
3.2.配置bond0：
root@zyxx:~/***#echo +bond0 > /sys/class/net/bonding_masters
3.3.首先down掉所有的tap网卡：
root@zyxx:~/***# ifconfig tun0 down
root@zyxx:~/***# ifconfig tun1 down
3.4.将所有的tap网卡加入bond0：
root@zyxx:~/***# echo +tun0 > /sys/class/net/bond0/bonding/slaves
root@zyxx:~/***# echo +tun1 > /sys/class/net/bond0/bonding/slaves
3.5.配置mode及miimon链路检测：
root@zyxx:~/***# echo 0 > /sys/class/net/bond0/bonding/mode
root@zyxx:~/***# echo 100 > /sys/class/net/bond0/bonding/miimon
将mode设置成了简单round-robin负载均衡模式。
3.6.配置bond0的ip：
root@zyxx:~/***# ifconfig bond0 172.16.0.1/16
3.7.删除冲突路由，仅仅保留bond0的路由：
root@zyxx:~/***# route del -host 172.16.0.2 dev tun0
root@zyxx:~/***# route del -host 172.16.0.2 dev tun1
root@zyxx:~/***# route del -host 172.16.0.6 dev tun0
root@zyxx:~/***# route del -host 172.16.0.6 dev tun1
root@zyxx:~/***# route add -host 172.16.0.6 dev bond0
这里假设分配给拥有client.pem这个证书的客户端的ip是172.16.0.6
3.8.OK
4.配置客户端的bonding：
同3
四.感受
1.和没有使用bonding相比，找一个测速工具看一下通过bonding之后的Open×××是否速度加倍了，答案是效果可能不明显；
2.效果不明显可能因为你的机器配置不是很好，Open×××并没有明显的降速，也就是说，通过Open×××链路和通过物理链路的速率相差不大。那样的话就在客户端启动的时候加上--shape参数，手工将单个Open×××虚拟链路的速率降低，这样效果就明显了；
3.我使用：open*** --config client1/2.cfg --shaper 5000启动Open×××客户端，wget的速率达到了6k/s左右(Open×××服务器和客户端之间属于不同的VLAN)，而使用单个Open×××链路的话速率仅仅是2.5k~3k/s左右。
4.目前Open×××还不支持直接配置bonding，期待有人做相关的修改，使之可以bonding。这个修改很简单，不需要修改驱动，其实只需要将上述的配置过程写成自动化的即可，也就是增加几个参数的工作量，如果有人觉得有趣，不妨试一下，如果没有人试，没有人试就算了...
五.后记
前一段时间，工作原因需要测试Open×××的性能，我对此工作任务非常感兴趣，期待最终能得到一个结果，虽然我对Open×××的ssl+tap架构十分满意，然而却对它的单线程架构，每帧传输实在不敢恭维，多核当道的今天，网卡芯片普遍offload的今天，Open×××好像是十几年前的家伙...
     我并不期待得到的结果一定是好的，实际上我需要的quick success或者quick failure，二者都令我满意，最重要的是在工作过程中得到了锻炼，这个过程不管对个人还是对公司都是一个很有意义的东西。期间，我百度，google了很多资料，大多数都是关于Open×××本身参数配置的，很少有关于修改tap驱动在降低些许延迟的小代价下提高吞吐量的，也几乎没有将tap网卡做bonding的，甚至连加密算法对Open×××性能的影响的资料都是少之又少，因此我就我的经验写了几篇文章，发表在CSDN上，这几篇文章都是以《Open×××性能》为主标题，副标题根据文章内容而变化，分享给需要的人们，希望以后有谁遇到类似的问题再google和百度的时候，能得到一些新鲜的东西。同时也小小呼吁一下分享精神，当然前提是不泄露公司和个人的隐私哦...