背景

最近作業中有公網訪問內網服務的需求，便了解了內網穿透相關的知識，發現原理和實作都不復雜，遂產生了設計一個內網穿透的想法，

名字想好了，就叫QuantumTunnel，量子隧道，名字來源于量子糾纏現象，

兩個處于量子糾纏的粒子，無論處于多么遠的距離，當其中一個粒子狀態改變時，另外一個粒子也會做出相應的改變，

QuantumTunnel也取意于此，希望把公網發出來的請求，完整的同步到內網，就像在內網發出的請求，打破網路的限制，

什么是內網穿透

什么是內網穿透？摘自百度百科

內網穿透，也即 NAT 穿透，進行 NAT 穿透是為了使具有某一個特定源 IP 地址和源埠號的資料包不被 NAT 設備屏蔽而正確路由到內網主機，

通俗易懂一點就是一個公網內的機器與不能被公網訪問的機器進行資料交換，
這個不能被公網訪問的機器有可能在某個機房，也有可能在家，

示意圖

首先，擺在面前的問題是如何讓公網與內網通信，內網的機器不能被公網訪問但是一般都能夠訪問公網（沒有訪問公網能力的場景不在討論范圍內），可以利用這一點，讓內網機器主動與公網的服務器建立雙向通信連接，這樣公網服務器就具備了往內網服務器發送資料的能力；
其次，要思考怎么才能讓用戶請求到達這個雙向通信通道，此時就需要一個用戶側的服務器，專門處理來自用戶的請求，并將其轉發到雙向通信通道；
上面兩個步驟完成后，用戶請求就來到了內網，此時需要一個客戶端代替用戶進行真正的請求，拿到回傳結果，

歸納總結一下，為了實作內網穿透能力，內網穿透服務中應該有的幾個角色：

按照上述思路，內網穿透的架構應該是這樣的：
架構圖

我們再次梳理一下參與到內網穿透服務的各個角色：

順著這個思路，我們來畫一下時序圖，

內網穿透時序圖

時序圖分為兩部分：

首先，代理服務器和代理客戶端建立了一條長連接，用于資料的傳輸，這個很關鍵，
因為代理服務器（公網）無法直接訪問代理客戶端，必須由代理客戶端主動向代理服務器發起連接請求，從而建立一條可以雙向通信的連接通道，利用雙向通信的能力實作代理服務器主動向代理客戶端發送請求的能力
然后是一次內網穿透請求的流程，
要注意的是對raw request（response）的處理：raw request -> proxy request ->; raw request，經歷了從原始請求到代理請求再到原始請求的封裝和決議程序，
為什么要有這個協議轉換程序？要實作協議無侵入（如http、ws）的目標，只能在現有協議上擴展請求，如內網穿透http協議，可以把目標地址和目標埠放在header中進行擴展，內網穿透-用戶服務器再把相關的引數給決議出來，從而知道目標地址和埠是什么，這樣處理的好處也顯而易見，在原來的框架、代碼不變的情況下，增加幾個引數就可以用上內網穿透服務，

大家可以了解一下這兩個內網穿透的實作，natx和毒刺，我在設計實作程序中參考了他們的一些實作，