背景

最近工作中有公网访问内网服务的需求，便了解了内网穿透相关的知识。发现原理和实现都不复杂，遂产生了设计一个内网穿透的想法。

名字想好了，就叫QuantumTunnel，量子隧道，名字来源于量子纠缠现象。

两个处于量子纠缠的粒子，无论处于多么远的距离，当其中一个粒子状态改变时，另外一个粒子也会做出相应的改变。

QuantumTunnel也取意于此，希望把公网发出来的请求，完整的同步到内网，就像在内网发出的请求，打破网络的限制。

什么是内网穿透

什么是内网穿透？摘自百度百科

内网穿透，也即 NAT 穿透，进行 NAT 穿透是为了使具有某一个特定源 IP 地址和源端口号的数据包不被 NAT 设备屏蔽而正确路由到内网主机。

通俗易懂一点就是一个公网内的机器与不能被公网访问的机器进行数据交换。
这个不能被公网访问的机器有可能在某个机房，也有可能在家。

示意图

首先，摆在面前的问题是如何让公网与内网通信。内网的机器不能被公网访问但是一般都能够访问公网（没有访问公网能力的场景不在讨论范围内）。可以利用这一点，让内网机器主动与公网的服务器建立双向通信连接，这样公网服务器就具备了往内网服务器发送数据的能力；
其次，要思考怎么才能让用户请求到达这个双向通信通道。此时就需要一个用户侧的服务器，专门处理来自用户的请求，并将其转发到双向通信通道；
上面两个步骤完成后，用户请求就来到了内网，此时需要一个客户端代替用户进行真正的请求，拿到返回结果。

归纳总结一下。为了实现内网穿透能力，内网穿透服务中应该有的几个角色：

按照上述思路，内网穿透的架构应该是这样的：
架构图

我们再次梳理一下参与到内网穿透服务的各个角色：

顺着这个思路，我们来画一下时序图。

内网穿透时序图

时序图分为两部分：

首先，代理服务器和代理客户端建立了一条长连接，用于数据的传输，这个很关键。
因为代理服务器（公网）无法直接访问代理客户端，必须由代理客户端主动向代理服务器发起连接请求，从而建立一条可以双向通信的连接通道，利用双向通信的能力实现代理服务器主动向代理客户端发送请求的能力
然后是一次内网穿透请求的流程。
要注意的是对raw request（response）的处理：raw request -> proxy request ->; raw request，经历了从原始请求到代理请求再到原始请求的封装和解析过程。
为什么要有这个协议转换过程？要实现协议无侵入（如http、ws）的目标，只能在现有协议上扩展请求。如内网穿透http协议，可以把目标地址和目标端口放在header中进行扩展，内网穿透-用户服务器再把相关的参数给解析出来，从而知道目标地址和端口是什么。这样处理的好处也显而易见，在原来的框架、代码不变的情况下，增加几个参数就可以用上内网穿透服务。

大家可以了解一下这两个内网穿透的实现，natx和毒刺，我在设计实现过程中参考了他们的一些实现。