目前企业级支流的穿透技术是PHTunnel和Wangooe Tunnel技术

目前国内内网穿透企业级的服务商有花生壳和神卓互联，我接触过很多公司在用，花生壳的穿透技术是PHTunnel ，神卓互联用的是Wangooe Tunnel技术，都是利用于企业级的，尽管我自己的程度还达不大企业级的程度，也不会进步程序在大量并发连贯中只有大量沉闷的状况下的零碎CPU利用率，零拷贝，TCP连接池，内存池，Reactor等技术，然而本人想试一下从头开始写一个仿神卓互联内网穿透的我的项目练练手，尽管网上有开源的FRP，毕竟是开源Go语言写的，性能上不适宜商用，于是本人开始写，只是简略的demo，本人测试能够，置信我会越来越弱小。

看一下我设计的拓扑图
须要云端有一台服务器，客户端有一个对接转发的客户端，用来转发用户发过来的申请，而后转发给应用服务器，应用服务器再将后果返回给用户

为了让公网能拜访子网服务，须要应用一台公网服务器做代理服务器proxyServer(这里的代理是集体叫法)，假如某一client须要拜访server(在子网subnet外面部署的服务)，然而client不能间接与server连贯。然而client能连贯位于公网的proxyServer，之后如果proxyServer能将client的音讯传给server，再将server的数据返回给client的话，在client看来，就相当于拜访的服务就是proxyServer提供的，所以能够认为该办法可认为对应用层是通明的。

以上是假如proxyServer实现了client与server的数据转发之后，client认为本人拜访了server。然而，因为server在子网，所以proxyServer是不能间接向server发动连贯的。同时，server次要是接管申请，而不是被动发动连贯，所以server也不会被动去连贯proxyServer。这样，server和proxyServer是不会间接连贯的，两个都是服务，都想他人来连贯，而不是被动去连贯他人。为了缓解难堪，就要再来一个代理客户端proxyClient，让他去被动连贯proxyServer和server，而后转发他们之间的音讯。
这里将proxyServer和proxyClient看作代理proxy，其次要作用是在传输层转发client和server的信息。proxy只负责转发音讯，至于信息的含意是什么，proxy无所不知。所以说proxy只工作在传输层，对下层应用什么信息，传输的内容是什么齐全不晓得。而client发送给proxyServer信息之后，proxyServer返回的信息与client间接拜访server返回的信息是统一的，client认为proxySercer提供了服务，把他看成server，他对于传输层数据通过什么解决齐全不晓得，所以能够说该办法对应用层是通明的。对proxyServer和proxyClient，二者协同共同完成以上的工作，缺一不可。
实现思路
通过以上剖析可知，次要指标是实现proxy，而proxy由proxyServer和proxyClient组成，所以这里将须要两个对象。同时，proxy次要是实现传输层数据转发，在具体编程实现时，实际上转发的是两个socket之间的数据。为了方便管理socket之间的关联关系，即应该将以后socket的数据转发给哪个socket，这里将定义一个转发器节点TranslatorNode类，用于存储源socket和目标socket，当以后socket是这个转发器节点的源/目标socket是，只须要将数据转发给目标/源socket就行了。

    在proxyClient和proxyServer的性能中，有一些雷同的性能，如转发数据等，也有一些相似的属性，如TranslatorNode对象等。为此，定义一个NetProxy类，用于实现这些独特的局部，再让proxyClient和proxyServer继承他就能够不必到处复制代码了。

思考具体实现时，proxyClient和proxyServer之间首先要建设通信，如果proxyServer转发多个client的数据时，都用同一个proxyClient与本人建设的连贯(socket)，那proxyClient从server那里获取的数据都会再通过这个连贯返回，这个时候，有很多个client等着拿数据，以后返回的数据到底给谁呢，一种方法就是在转发的数据之前加上一些管制信息，管制信息指明这个数据给谁。然而这会存在一个问题，如果承受数据的buffer比拟大，某一次返回的数据可能是转给两个client的，后果混在一起了，这就会导致转发谬误的音讯给client(未实践证明，集体了解)。而且管制信息的治理也不太不便。为了保障传输数据的污浊，就是proxy不在转发的数据之上再增加额定的信息，这里采纳另外一种办法:为每一个client建设一个专门的连贯，但凡client的数据都通过为他建设的连贯转发给proxyClient，proxyClient发到这个连贯的数据都返回给对应的client。这样治理起来就比拟不便了。当有一个client连贯到proxyServer时，proxyServer和proxyClient要建设一条新的连贯，然而proxyServer又不能被动建设连贯，因而由proxyClient建设，为了让proxyClient晓得什么时候该建设连贯，就须要proxyClient与proxyServer有一条专门用来通信的连贯proxy_communication_conn。

    留神到就proxyServer而言，他并不知道连贯到本人的到底是client还是proxyClient，所以这里将定义一些指令，用于指明proxyClient的身份，阐明本人是proxyClient。在proxyClient连贯到proxyServer之后，就须要发送特定音讯，这就要求proxyServer和proxyClient约定好了什么音讯代表什么含意。这里将用一个指令Command类来定义具体的指令，且指令不可被批改，指令尽可能为client不可能发送的音讯，不然proxyServer会误把client当成proxyClient。    总结一下，须要实现TranslatorNode，Command，NetProxy，NetProxyServer(即proxyserver)，NetProxyClient(即proxyClient)，NetProxy。上面将一一介绍实现细节。

NetProxyServer和NetProxyClient用来实现proxyServer和proxyClient的性能，他们继承自NetProxy，然而NetProxy具体要实现哪些性能，须要先剖析了NetProxyClient和NetProxyServer之后，总结其独特局部能力失去，所以这里先这两个类作介绍。这里通过一个client拜访server的过程阐明proxyServer和proxyClient的性能。

    为了让proxyServer和proxyClient互通音讯，应该先建设proxy_communication_conn，所以在proxyClient启动之后，应先去连贯proxyServer，并跟他阐明这个连贯是用来通信的，所以两者约定一个通信连贯指令，当proxyServer接管到一个连贯之后，如果这个连贯发送了这个指令给本人，那就把这个连贯标识为proxy_communication_conn，当然，proxyClient发送这条指令所用的连贯也标识为proxy_communication_conn，当这个连贯收到音讯时，须要解析其含意，而其余连贯则只需转发音讯。NetProxy能够定义一个变量proxy_communication_conn，这样在继承当前NetProxyClient和NetProxyServer不必反复定义这个变量。    在client连贯到proxyServer之后，发送音讯，proxyServer收到音讯，判断不是与proxyClient约定的指令，就看下这个连贯有没有对应的转发连贯。那怎么晓得是否存在呢？这里须要用一个translator_node_pool来存储，他是一个列表，元素为TranslatorNode，每一个TranslatorNode有两个连贯，示意从一个连贯收到的音讯要发送到另一个连贯，这样就实现了连贯之间的关联关系。当然，client可能在proxyClient跟本人建设连贯之前曾经给本人发送音讯，这个时候并不知道音讯要发给谁，间接丢掉又太间接了，所以思考在TranslatorNode外面减少一个列表元素，用来存储关联连贯之前client发送过去的音讯。为了建设这个关联连贯，那就要proxyClient被动跟本人再创立一个连贯，而后再将这个连贯关联到client的连贯。为了辨认出是proxyClient建设的用来关联的连贯，二者须要约定一个指令，用来表明以后连贯是proxyClient被动连贯的，须要关联到client的连贯。    proxyClient也须要一个translator_node_pool，用来转发与client关联的连贯与server的连贯之间的音讯。为了简略治理，在proxyServer告诉本人增加一个跟client连贯关联的连贯之后，与proxyServer建设连贯并发送指定指令，而后还须要建设一个到server的连贯，再用TranslatorNode将这两个连贯关联，之后一个连贯接管到音讯之后，就晓得应该把音讯转发到哪里了。    同样，能够在NetProxy定义一个translator_node_pool，同时能够定义一个Command类，因为proxyClient和proxyServer都通过他来获取大家约定的指令。另外，转发音讯也是他们都须要实现的办法，也能够写到NetProxy外面。思考到断开连接时执行的操作也基本一致，能够也将该办法退出进去。    还要留神的一点是接管音讯时设置的buffersize，如果过大则会占用过多内存，然而设置过小的话，在下载大文件的时候，下载速度间接受到buffersize的限度。为此，可思考动静调整buffersize，对TranslatorNode增加一个buffersize属性，用于批示下次的buffersize应该要设多大。为了防止recv音讯时阻塞，能够联合select实现非阻塞接管音讯。