剖析基于TUN/TAP虚拟网卡游戏加速器原理

       我们知道最强大暴躁的游戏加速器由于某些原因是不能存在的，对于游戏加速器而言基于TUN/TAP虚拟网卡实现是最经济实惠的办法，这是由于基于LSP/NSP的方式会受到杀毒/带保护应用的反抗（inline-hook/driver-protect）导致无法为其进行加速，纵然我们为其打上了七八千上万块钱一年昂贵的 “CA内核EV代码数字证书”，这不见得可以全部通吃，而加速器服务商为了那些应用可以通过，则需要交 “保护费” 过下保护，这简直反自由，有一股回到了90年代黑道社会人猖獗的痛苦年代的感觉，而基于TUN/TAP虚拟网卡基本只要可以装上驱动就可以减少这笔保护费，一分钱不掏是几乎不可能的！！！你必须要坚信这一点，某些不要脸的防毒软件肯定要搞搞事情，不搞搞事，你不会老实买证书，你不买证书它们就没有额外收入，更黑的可能买了证书还要让你在交一波保护费！

      然而我本人绝对不向黑恶势力低头，所以我只会提交发布程序到 Microsoft 安全上面检查，花费很长的时间慢慢确认安全性，因为这是不要钱的，对吧，相信微软总比相信一些流氓更靠谱不是？但是没有办法必须要遇到流氓到底怎么办？要不花钱认栽，要不就用户关防毒或者添加杀毒软件信任。

     国外加速器与国内加速器有很大不同，它们支持UDP/TCP/ICMP这些协议，暴躁的还会支持GRE协议穿透路由（这协议有多神奇就不再累赘BB了）而国内的游戏加速器一般只支持UDP/TCP这两个IP层协议的处理，就像很多家用路由器只支持UDP/TCP穿透相同。

     游戏加速需要分划分为三个部分，1、转发路由，2、NAT节点，3、本地客户端适配器

     我们知道早年南北网络互通那酸爽是非常感人的，虽然今天网络质量大大提高但还是存在一些早年前问题的，不过这不是重点，重点是游戏加速这个行业是越来越难做了，无论是海外游戏还是国内游戏加速都是相同的，海外游戏加速要减少延迟需要部署很多的 “路由节点”，而要显著降低延迟就必须要拉 IPLC，IEPL 专线私有网络，这成本之酸爽我就不提了，阿里云 4M 新加坡-广东 IPLC 专线要1200RMB一个月，而全国各地每个省都需要单独进行优化，这就必须要进行实地考察每个省的家宽，不同运营商家庭网络带宽路由跳板的路径，在到最佳的省/市铺设路由节点，在通过路由节点跳到更短路径到达目的 IP 的路径的路由或者节点，总之成本不会很低，而且我们还要算一下一个用户在线会用到多少带宽，不精打细算那就是在耍流氓，玩一个 CS:GO 游戏的国际服，大约每秒钟从服务器到本地端要 512Kbps 带宽，这还不算丢包造成的带宽损失还有 “封装帧头”，这也就是说 4Mbps 带宽满打满算至多可以支撑 8 个玩家在线，一个玩家应当花多少钱才能让游戏加速器服务商回本？玩上一个大天大约需要 2~3GB 的流量，整个服务器流量损坏至少是 2+N 倍流量的损耗。

     转发路由有两种类型，1、处理IP层报文的软路由，2、基于应用的TCP/UDP路由，做法上面各有所不同，第（1）类转发路由同时支持的连接并发性会比第（2）类好很多倍（难以想象的差距）但是缺点非常明显 “链路连接流速” 非常的慢，这是由于 “客户端/目的服务器” 的网络传输层拥塞控制算法导致的，客户端的RTT往返延迟等于（本地客户端 + 转发路由1+N + NAT节点 + 目的主机节点）* 2，而且它无法在转发路由服务器上面配置 “BBR/锐速” 等TCP单边加速工具进行减少重传因子超发加速，而且这也会增加一定UDP报文的顿挫性，会有一定的时延上的增加，虽然最终表现上面很细微就是了，但是把第（2）类转发路由就真的万事大吉了嘛？从游戏加速的角度上来说缺点会更加的致命一些，第（2）类路由解决不了TCP/IP链接并发性的问题且无法解决 “链接” 即时性的问题，走第（1）类路由的方式，客户端TCP/IP虽然流速不高，但至少收到报文的即时速度会较为稳定即时，但是走 “第（2）类” 路由这就必须要考虑到非常的多因素了，首先每个路由节点之间是不是都是开了 “TCP/IP Nagle” 算法？每个路由节点与另一个节点之间交换数据有没有出现丢包，出现一次丢包就会放大延迟，而 “TCP/IP Nagle” 算法的开启，则会显著影响客户端收到报文的及时性，另外是每个路由/节点接收客户端的套接字的效率，在反过来链接下一个路由/节点，那边在重复类似的一些行为，效率是非常非常低的，此时还要考虑客户端握手上的开销带来的时间开销，而第（1）类路由没有这样的致命的问题，但第（2）类路由它并不是一无是处，它的带来的 “每秒流速” 是第（1）类的路由永远也无法达到的。

     NAT节点的架构基本与转发路由的架构差不多，唯一不同的是该节点必须要与客户端之间握手鉴权，从握手之中获取到访问目的主机的 “IP地址与端口” 我们一般称为 Destination IPEndPoint（目的IP地址端口点）术语，之后在与目的主机之间建立连接转发来自本地客户端与目的主机之间的数据（第（2）类会参与双方连接建立过程，第（1）类是客户端穿透路由与目的之间建立连接），而对于UDP/ICMP协议的加速这基本都是是在 “NAT-节点” 服务器上面应用 NAT/P-NAT 实现的，为了游戏延迟更低游戏加速器研发与设计者们绞尽脑汁！！！但如果考虑到 TCP/UDP/ICMP 游戏延迟一定要低且稳定，那必须选应用 “第（1）类” 路由/节点架构技术的游戏加速器，它的网络质量与效果是几乎最好且无可挑剔的，虽然TCP/IP流速会很慢，但是有句古话叫做 “鱼和掌不可兼得，有得才有失”！

     上面提到了关于 “路由/NAT-节点” 的原理，那么本地客户端呢？实际上这所有的技术难点核心主要集中在 “本地客户端适配器” 上面，上面提到的，除了第（1）类是把技术难度集中在 “NAT-节点” 上面，第（2）类 “节点/路由” 实现只要不是脑子有点毛病，一个才出来搞一两年的 “服务器工程师”，在有个 “服务器主程” 指点指点，基本商自己一个人就能搞定这套东西，What？... 耗费大量时间都难以搞出来？或者一大堆各种句柄/内存泄露，哎呀！！！有点点感到没法说话话，或许，可能，相对适合做点 Web 后端之类东西吧！！这似乎是一条可以快速成就大佬的道路！！！

      目前新出的某些个游戏加速器，它们是基于 “tun2socks” 的原理实现的，笑~~~把某些个似乎叫做的开源项目 “V2/SS” Android & IOS 基于 VpnService 实现的适配器，自己求快快的小改协议就整出来的东西，但还是逃脱不了 “tun2socks” 底层的套路，醒醒，这东西不适合游戏加速，只有真 “NAT” 才是游戏加速的王道。

      难道不考虑 TCP/IP 的游戏加速了吗？你这么搞不加还好，一加延迟更高网络更差劲了，上面提到那几个东东的 “tun2socks” 还有 “学术性魔法” 现象问题，连接稳定性差老容易被阻断，不考虑玩家们玩着基于 UDP/IP 的游戏，玩着玩着正 hi 正 happy 时，突然那么一下短线带来的 “撕心裂肺” 、“痛哭流涕” 的悲惨痛苦了吗？？？也不考虑才进游戏可能 UDP/IP 不通还是压制报文造成 “时延” 的问题？？，虽然走专线网络会好点，但是不走专线网络的岂不是得一首凉凉送给自己吗？这类加速器让我感到了一种 “低级趣味的科学” 的感觉~笑：XD，似乎可以学学它们用 OpenVPN 那一套东西的代码来改 UDP 加速器报文承载协议办法，那是个游戏加速的好办法。

       1、NAT 类型的 “客户端/服务器” 实现可以看这个开源项目，虽然是实验性质的但代码足够少，对你理解第（1）类型的基于 TUN/TAP 的游戏加速器会有显著的帮助，如果你感到兴趣，那么你需要深入的理解这些代码：https://github.com/liulilittle/SkylakeNAT

       2、Tun2socks 客户端实现可以看这个开源项目，它也是实验性质的当然是上面跟这个都稳定版本，不过是没有开源的不要过多的指望咯，想白嫖是不可能的，抵制任何形式的白白伸手党，如果你感到兴趣就深入了解此代码：https://github.com/liulilittle/SkylakeNAT

            tun2socks 的实现是本人在 VC++ 2015 x86 结合 LWIP 协议栈实现的，Go 语言有类似的实现是基于 google/netstack 实现的，但原理大同小异，即在应用层内部托管运行一个TCP/IP网络协议栈来处理来自TUN/TAP输入的TCP/IP报文，然后在把它转换成 Socks5 / TCP连接代理，实现上面没有想象中的那么复杂，除了会相对较为麻烦一点，不过，如果你要自己实现一个可用且稳定的 TCP/IP 协议栈那就是另当别论了。

            但是 tun2socks 的实现其实还有别的办法，就是通过 “内核套链路重叠” 的办法也称为 “网络连接桥接” 的办法，某些人可能喜欢把这种方法说为 “二次NAT” 这样的叫法，这种实现原理是 “基于虚拟网卡，设一个虚拟主机，一般是虚拟网卡的网关，之后把发向外网的报文修改IP/PORT后转发到这个虚拟主机监听接受的应用套接字上面，在转发给 Socks5 代理服务器，回程与去程相同”，下面给出大致的处理流程图，整体NAT处理的流程大致为：111.27.24.125:7000(目的主机) -> 198.18.0.0:34125 (网关虚拟主机) ->  198.18.0.24:57123(本地映射套接字) -> 192.168.0.24:1080 (Socks5代理) -> 111.27.24.125:7000(目的主机）。

            上述流程，各个IP所代表的主机含义解释：111.27.24.125 目的主机，198.18.0.0 虚拟网卡网关，198.18.0.24 虚拟网卡IP，192.168.0.24 SOCKS5代理服务器，当然还有其它的办法可以实现，但这些办法都较为复杂需要单独的写网络驱动才可以办到，而上面的这种办法是应用层可以实现的最几个办法之一。

      那么有没有在内核层工作的网游加速器呢？其实早年这种游戏加速器是非常多的，当然现在都全部完蛋凉凉了，在内核层工作的固然速度快，但是大的缺点就是不容易维护调试与更新，在加上现在的硬件的性能都非常的强大，而且游戏加速器并不需要那么高的网络性能，只要保证游戏的延迟低下就可以了，所以我们才会看到几乎所有的游戏加速器（支持虚拟网卡）都是基于 TUN/TAP 虚拟网卡的。

      基于 TUN/TAP 虚拟网卡的游戏加速器，早年由于某些游戏加速器没有考虑到专业用户的一些骚操作，导致某些加速器出现了可以提供 “低级趣味科学” 访问的能力，虽然后面都修复了这样的设计上的漏洞，但造成了各种风险与问题还是不可挽回，该漏洞其实很简单就是通过，修改系统的IP路由，让其走游戏加速器的虚拟网卡出站流量，故达到这些用户 “不可告人” 的秘密，当然解决这个办法很简单，直接锁IP范围就可以修复这个问题。

      游戏加速器客户端适配器的核心原理吧，这玩意没有那么神奇，它只是相对比较高一点点的技术门槛，对人的要求要比普通的其它东东要求会高点罢了，除非要做一个很复杂的加速器网络协议处理底层，那是真的需要足够的技术，这不是任何人都有资格有能力可以做到的，没有多年的技术的沉淀，这几乎不太现实，这比如 “快速发包/仿真技术/动静隧道技术” 很多人可能都不太理解这是什么东西，更别谈如何去实现这些加速器的功能了，而本文上述也只是提到了 “TUN/TAP” 层面的大致实现原理，算是抛砖引玉，但是具体如何做，这还是需要取决于开发者自己或者团体的选择。