由于Oracle之前推出了always free（虽不知这个always会是多久）的云服务器，带宽限制在单台45Mbps左右，在白天电信国际出口不怎么拥塞的时候，还算是不错的一个选择，可以用来节省自己bwg cn2 gia线路为数不多的500G流量（按双向计费的规则来算，实则只有250G）。
由于我在外地是以vmess普通协议接入家中的软路由，软路由上的v2ray再中转统一走ws+tls的方式去科学上网，由于Oracle的机器有两台的免费额度，因此如果能并发用起来，效果应该还是不错的。
然而根据周末的测试结果来看，在软路由上，分别测试Oracle两台机器往家里软路由打的带宽总是超不过50Mbps，这让我觉得有点诡异，思考其中原因，应该是：
由于我的软路由性能一般，且pppoe拨号后，使得网卡的rss机制实际上是无法工作的，因为报文有一层pppoe封装，使得网卡无法看到pppoe里ppp封装的ip报文，因而无法进行多queue处理，查了内核rps的功能，似乎也没有这个功能。因而所有入方向即通常我们从外网的下载流量，都只能由单个cpu核心处理，如果没有做好cpu隔离的话，就会影响到性能。
基于这个思考，且考虑到家里的电信支持多拨，马上在软路由上拨出来别外一个ppp接口，将另外一台云服务器的路由配置到此ppp接口上去。果不其然，并发流量直接搞到了100Mbps，这样从家里内网使用Oracle线路下载文件时，会被v2ray负载分担到两条云主机上，且通过不同的ppp接口出去，下载速度自然会dobule，实为物尽其用也。
写到这些，也谈谈我对负载均衡的理解，我觉得，负载均衡实际上来自于对于一个业务的拆解，比如从http协议的角度来说，http本身的处理，渲染页面实际是比较占cpu的，那么，通过前置一个4层proxy，让这个proxy主要负责tcp的报文中转，就可以将一堆http服务器置于这个proxy的后面，由于proxy只需要处理tcp报文中转，是可以实现比较高的性能的，并且可以通过硬件能力堆上去来scale up提高处理性能，而proxy则可以通过多台scale out来实现匹配到proxy的转发能力，从而提高整体集群的处理能力。
当然，如果在proxy前，再放一台三层交换机，来做下三层的ecmp，这样就又可以实现proxy一层的scale out，整个集群的能力就越来越强了。
附：
1、v2ray的负载均衡文档见：https://toutyrater.github.io/routing/balance2.html 这是该文档作者后来更新的负载均衡版本，先前他给出的方案并不好用，所以作者用了v2ray提供的新方案，我自己也是用这个模式配置的。
2、看起来这内核的维护者似乎也意识到ppp这种封装使得rps无效了？http://vger.kernel.org/~davem/davem_spain10.pdf