本篇來聊一下內網穿透中流量轉發的問題
內網穿透和核心邏輯是根據流量的路由信息准確地將公網流量路由到指定的機器端口上，從而完成一次流量的內網穿透。
這里有一個核心問題，路由信息從哪里獲取？
常見的有將路由信息跟內網穿透服務器端口進行綁定的，稱之為端口路由；另外的還有將路由信息放在應用層協議中，由內網穿透服務解析應用層協議，拿到路由信息，這種方式稱之為協議路由。
這兩種路由方式都有哪些特點呢？下面對它們進行展開討論。
端口路由
端口路由，顧名思義，就是將路由信息與端口進行綁定。將這個端口收到的流量統統轉發到指定內網的指定服務器的指定端口。
這種路由方式最大的特點就是協議無關。
不管被代理的服務是常見的Http接口還是Redis、MySQL，或者是RocketMQ等服務，使用方只需要將請求發送到內網穿透-用戶服務端口上，內網穿透服務器都能夠把接收到的流量准確的代理路由到指定的服務端口上。
在使用方式上也很簡單，使用方只需要將真實后端服務ip替換成內網穿透服務ip，原始服務端口替換成內網穿透服務端口即可。
簡單理解端口路由就是內網穿透服務會將用戶端口接收到的流量鏡像到內網指定的ip和端口上。
端口路由的應用場景為真實的服務地址和網絡都不變，只需要簡單的將網絡打通的場景。
如本地開發調試需要連接內網的某個服務（如MySQL、Redis）。
協議路由
協議路由指的是內網穿透服務通過解析應用層協議獲取真實的內網路由數據。
舉一個場景例子，假設有兩個相同的Http服務分別部署到兩個內部網絡中，在公網的服務需要根據不用的業務邏輯將請求打到不同的內網。此時就可以把路由信息放在Http請求的Header上，由內網穿透服務解析Http請求的Header部分，拿到路由信息，從而決定路由到哪個內網的哪個服務上。
協議路由可以在同一個端口根據用戶參數路由到不同的網絡上，靈活性非常好，但是它也犧牲了侵入性，對使用者代碼會有輕微的侵入：使用者需要根據不同的應用層協議開發相應的路由信息解析代碼。
需要根據業務邏輯將流量轉發到不同的網絡是協議路由的主要應用場景。
端口路由 vs 協議路由
總結一下端口路由跟協議路由各自的優缺點：
| 端口路由 | 協議路由 | |
|---|---|---|
| 靈活性 | 差 | 好 |
| 侵入性 | 無侵入 | 有輕微侵入 |
| 安全性 | 無安全校驗 | 可做安全校驗 |
| 接入工作量 | 無 | 有少許代碼改動 |
最后
端口路由犧牲了靈活性，換來了無侵入的好處；而協議路由強調靈活性，在代碼侵入性上做出了妥協。兩種路由方式各有不同適用的應用場景，但是都想要怎么辦？
QuantumTunnel表示沒問題，兩種協議都支持。並且不管是端口路由還是協議路由兩行命令就能夠把內網穿透服務啟動，非常方便。
可以下載jar包通過命令直接啟動：查看最新發布的版本
# 啟動內網穿透服務端
java -jar quantum-tunnel-server.jar -proxy_server_port 9090 -user_server_port 8090
# 啟動內網穿透客戶端
java -jar quantum-tunnel-client.jar -network_id localTest -proxy_server_host 127.0.0.1 -proxy_server_port 9090
服務啟動后，可以訪問百度驗證一下：
curl --location --request GET '127.0.0.1:8090/' \
--header 'Host: www.baidu.com' \
--header 'network_id: localTest' \
--header 'target_host: www.baidu.com' \
--header 'target_port: 80' \
--header 'Cookie: BDSVRTM=11; BD_HOME=1'
倉庫地址
當然也可以clone倉庫進行更加個性化的開發，
歡迎一起打造基於Java最好的內網穿透工具：QuantumTunnel
- Gitee：樂天派 / quantum-tunnel
- GitHub：liumian97/quantum-tunnel
