闲聊：Android 平台网络游戏加速器·一（科普文）
我们知道 “游戏加速器” 底层通常是基于隧道代理转换技术的，无论是走 Windows 平台上面得 LSP（分层服务）还是走 tuntap 虚拟网卡得形式。
至少从技术门槛上还是要点东西得，Windows 基于 LSP 技术难度相对不难，Android 上面实现稳定可靠的 “游戏加速器” 是个令人头疼的东西，平心而论。
Android 有哪些实现方式：【Non ROOT】
1、Android 10 提供允许配置 HTTP正向代理服务
可应用HTTP/S正向代理类游戏，一般为网页游戏
2、Android 5 提供 V*NService，可创建、读写 tuntap 字符驱动
面向整个设备上以IP协议传输数据得应用及系统层实现
好了，我们重点说第二条，Android 10 + 这条看看搞笑就行了，Android 平台上游戏加速器是不可能采用此方案得。
Android 平台上基于 V*NService 实现游戏加速器流派，大约为以下列出两类：
1、tun2socks（类似）
2、FULL NAT（类似 OpenV*N）
两套技术实现各有千秋，整体而言考虑对 “网络延迟加速效果”，FULL NAT技术是最好的，所以很多人瞎琢磨一些 “游戏加速器” 大厂 “Android apk”，会看到 “OpenV*N” 的 so 库的原因。
RTT公式：
tun2socks = 本地主机 + 协议栈 + 远程隧道代理 + 协议栈 + 目的主机
FULL NAT = 本地主机 + 远程虚拟路由交换机 + 目的主机
似乎看上去相同，但这是错误的，tun2socks 延迟永远都会比 FULL NAT 更大，除了单位连接吞吐速度够快，几乎毫无是处。
tun2socks 涉及到多次向内核协议栈换入换出会增大 RTT，并且还受到多个TCP状态机及 Nagle 选项的影响，想要优化其 TCP/IP栈尽快发包是很麻烦的。
具体细节就不过多累赘，tun2socks 这套东西得实现最初是在 BadV*P 项目开源的，基于 LwIP C TCP/IP Stack 得封装，本质上它并不是为了 “游戏网络加速” 而设计的，有句话叫做术有专攻。
tun2socks 解决了一个 FULL NAT（传统 V*P）技术最大的缺点，客户端适配器 - 远程路由交换机 - 目的主机服务器，之间RTT过大，单位传输带宽吞吐量过低。
另外一个优势是TCP/IP协议栈单/双边吞吐加速，FULL NAT若要提供单/双吞吐加速需要自行实现TCP/IP加速算法进行吞吐量加速。
但除了优势就没有劣势吗？显然是有最直接的就是：Final RTT时间变得相对更加不可控，而且难以正确计算，对于 CPU/RAM 资源的负担加重多倍。
FULL NAT需要非常好的线路 + 极低RTT，才能让设备可以跑上GE口，但换为 tun2socks 技术，50RTT仍可以拉满GE口带宽吞吐量（这造就各种宣扬吊打 V*N 的沙雕的精神及谜之信仰支柱，总结：没文化真可怕！）
注意：单位传输带宽吞吐量低不等于 RTT 时间高，RTT时间低不意味着单位传输带宽吞吐量高。
目前据我们了解多数 tun2socks-android 实现基本都是从 Linux 开源项目上移植编译而来，某个17年被铁窗泪喝凉茶的哥们开源项目 android 平台客户端适配器实现，某S*S-android，后面各种山寨开源产品，隔三岔五搞个看上不同但没什么区别的东西出来，比如某V*R*Y-NG、clash x android。
我为什么提这个东西？答案是：现在真的多了一大堆所谓的 “游戏加速器”，都是这些玩意的换皮魔改版本。
S*S-android 是依赖于开源 tun2socks 的实现，这个东西现在实现的人多了，可选方案还是比较多的，比如用的最多的 BadV*P 提供的实现，但基本都是跟这个流派差不多的，反正就是抄抄抄，搞了一抹多，基本都是 LwIP implement tun2socks，Golang 这块基于 Google 开源的 netstack，抄 蓝D 一部分代码来实现 golang tun2socks，大概这个东西行情就是这么回是。
又有很多已经把 libtun2socks.so NDK四个指令集平台的程序编出来，后面入手的人都不需要在去研究怎么编译代码了，套到程序就能跑起来，这算不算是时代的一个进步？
IOS/Mac 平台那边也有类似实现开源的东西，实现方式一个路子，LwIP impl tun2socks，不过多了一个封装的稍微多点的开源库实现 NEKit。
FULL NAT类的技术话，相对冷门的多，基本现有实现就是：“OpenV*P”、“SoftEth**”、“WG”，这些东西。
=========================废话说太多了，打住！=========================
Android 平台基于 Google 提供的 V*NService 提供的可用户编程接口，上其实是有一定限制的，但对游戏加速器来说无所谓。
主要限制就是：IP路由表这块不可以随意控制，只能在构建V*P连接的时候显示的添加配置进去，或者就是特定那些应用走加速器，那些应用不走游戏加速器。
看上去好像后面这条很OK呀，小伙子小妹子们不要急，这东西的坑马上都出来了，的确我们配置那些应用走加速器，那些应用不走游戏加速器，咋看没问题，但是这又涉及到另外一个东西，IP路由表配置问题。
假设：配置游戏加速器配置IP路由为 0.0.0.0/0，也就是所有流量走 “游戏加速器” 通过。
那么：当被加速流量到达加速器协议栈那么首先就需要 protect 一下到可以访问外网的 network（netId）上面，否则就会造成本地环路。
OK，那么上面解决了不环路的问题，又带来的全新的问题，因为现在IP路由配置是全局走加速器，这也导致只要没有添加不走加速器的应用进去，要出人生重大问题了，没有被添加进入禁止走加速器的应用，可以通过加速器的网络自由访问某些不可名状的东西，造成不可名状的后果，小伙子/小妹子，还有贵公司老板准备好改天进去望破铁窗，好好改造，饭管饱，一二十年后还是一个好汉/好女/好老板。
《铁窗泪》、《一步一步走出监狱大门》、《狱中望月》都是非常映射此情此景的传唱经典音乐。
那么如何解决这个问题？答案：千万千万不要配置全局IP路由表，要加速的游戏与服务器之间的IP抓出来，还有如果需要游戏网站也加速，那么也单独抓出来IP，合并在一起单独配置路由表，保险起见，游戏加速器服务器的童靴们，最好对流通的所有流量要做审查与限制，人生要稳一点，稳稳才能更健康，Android 平台这个坑爹玩意是不可以在 build 之后添加/删除那些应用走加速器的，想秀操作的可以放弃不切实际的幻想了，如果想要害人害己，快快快！身份证+电话发我，我先举报个充个业绩。
那么就算是把所有的添加/禁止走加速器规则做进去能规避，人生重大风险吗？这是，不可能的！小小操作轻轻松松绕过，我们举个例子：
我先打开你的游戏加速器，对XXX游戏进行网络加速，然后重新装一个新的 Web 网站浏览器，然后你是IP全局路由走游戏加速器，并且 Android 平台上面只要你不重启并重新配置的情况下，那么你猜猜，我现在是不是可以无所欲为？务必要慎重，要稳重一点啊！
...........今天先这样，改天继续摆！