本篇來聊一下內網穿透中流量轉發的問題
內網穿透和核心邏輯是根據流量的路由資訊準確地將公網流量路由到指定的機器埠上，從而完成一次流量的內網穿透，
這里有一個核心問題，路由資訊從哪里獲取？
常見的有將路由資訊跟內網穿透服務器埠進行系結的，稱之為埠路由；另外的還有將路由資訊放在應用層協議中，由內網穿透服務決議應用層協議，拿到路由資訊，這種方式稱之為協議路由，
這兩種路由方式都有哪些特點呢？下面對它們進行展開討論，
埠路由
埠路由，顧名思義，就是將路由資訊與埠進行系結，將這個埠收到的流量統統轉發到指定內網的指定服務器的指定埠，
這種路由方式最大的特點就是協議無關，
不管被代理的服務是常見的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
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/353107.html
標籤：Java
上一篇：Spring Security OAuth2 單點登錄
下一篇：資料庫設計的 10 個最佳實踐！