用JAVA實現TCP協議的反向代理非常容易，只用不到100行程式碼就能搞定，每一個連線只需兩個Socket，3條執行緒，進行輸入流與輸出流之間互相讀寫就可以了，可以承載所有TCP協議層以上的流量，比如HTTP(s)，FTP，sFTP，郵件，即時通訊等等。其效果和HAProxy或者Nginx的TCP反向代理差不多，而且如果客戶端的併發數比較大的情況，還可以使用JAVA的NIO和AIO框架，降低伺服器資源的開銷。

對於UDP協議來說，它是無連線無狀態的點對點協議，所以與TCP協議比起來會有很大的不同，主要體現在：TCP是有連結協議，所以當有很多個客戶端訪問代理程式時，代理會轉發他們的請求給伺服器端，伺服器響應資料給代理程式後，代理程式清楚的知道這個響應應該發給哪個客戶端，並將資料傳送回去。其邏輯如下

1、客戶端發起一個Socket，繫結埠50000，目標地址為代理伺服器8080。代理程式開啟ServerSocket，繫結埠8080，於是一條客戶端5000到代理端8080的連線就建立起來，客戶端Socket通過OuputStream把資料傳送給代理端的InputStream。

2、服務端監聽到連線建立之後，立即new Socket，繫結51000埠，目標埠為真實伺服器的80埠，於是一條代理伺服器50000到真實伺服器80的連線就建立起來。

3、然後代理伺服器新建兩個執行緒，一條將客戶端的連線的InputStream寫入到真實伺服器連線的OutputStream，另一條執行緒將服務端連線的InputStream寫入到客戶端連線的OutputStream，就完成了一次代理轉發。

在這個過程中，客戶端開放了一個埠50000，代理程式開放兩個埠8080和51000，真實伺服器開放了一個埠80

如果有n個客戶端，那麼每個客戶端也只開放一個埠，代理程式開放1+n個埠，真實伺服器始終開放一個埠。

如果有n個客戶端，每個客戶端建立m條併發連線，那麼每個客戶端開放m個埠，代理程式開放1+m*n個埠，真實伺服器開放一個埠。

從上面可以看出，對於TCP來說，每一條連線使用不同的埠進行區分，當一條連線建立起來時，客戶端會監聽一個49000以上的埠，代理端使用代理埠與其連線，但是代理端建立的與真實伺服器的連線也會在代理端開放一個49000以上的埠，這個埠號和客戶端開放的埠號一般是不同的。這樣一來，在上面的例子中，服務端傳送到代理端51000的資料包很自然的被代理端轉發給客戶端50000埠，一一對映不會出錯。即使再多的客戶端連線也不會混淆。

但是UDP協議是無連線的協議，它也可以仿照TCP協議的轉發方式進行工作，過程如下

1、客戶端發起一個DatagramSocket，繫結埠50000，目標地址為代理伺服器的53埠。代理程式也new 一個 DatagramSocket，監聽53埠。於是客戶端就可以向代理端傳送資料包了。

2、代理端收到資料包之後，有兩個選擇，第一是用接收客戶端資料包的DatagramSocket把這個資料包傳送到真實伺服器，不過這樣就沒法再接收客戶端發來的後續資料包了，所以一般情況下，代理程式會new DatagramSocket，把剛剛收到的DatagramPacket修改一下目標地址傳送給真實的伺服器。

3、現在代理端又有兩個選擇了，由於UDP不像TCP那樣有流的概念，所以我們無法拿到輸入輸出流，只能操作資料包，而且是單向的操作資料包。一個方案是用剛剛向真實伺服器發包的DatagramSocket接收服務端返回的資料包，另一個方案是不接受資料包繼續轉發下一個資料包。

第一個方案我們可以接收到伺服器的返回資料，缺點是沒法再利用這個DatagramSocket傳送第二個資料包了，第二種方案可以流暢的轉發客戶端的資料包到服務端，不過客戶端就收不到服務端的響應了。

所以此時，我們需要根據業務需求制定相關的轉發策略了，這裡我主要分為了兩種型別

1、DNS型轉發：客戶端傳送一個數據包需要服務端馬上返回一個數據包實現業務邏輯，比如DNS。單個數據包最大為65536位元組，某些環境下還會更小。

2、P2P隧道轉發：客戶端向服務端傳送一連串的多個數據包，並且服務端也向客戶端傳送多個數據包，資料包收發並不是一問一答的關係，而是傳送和接收同時進行。

邏輯上來說第一種方式是第二種方式的子集，只不過為了節約資源開銷，第一種方式在服務端返回資料包以後立即關閉Socket，從而節約記憶體和網路資源。有些應用比如OpenVPN的udp模式就沒有應答的概念，而是輸入和輸出像流一樣同時進行。從程式碼實現上來說，第二種方式比較容易實現一些，首先建立兩個DatagramSocket，一個監聽在本地埠，用於接收客戶端發來的資料包並轉發真實伺服器的響應；另一個把目的地址指向真實伺服器，用於向真實伺服器傳送和接收資料包。在代理端的DatagramSocket通過receive()方法收到一個DatagramPacket之後，新建兩個執行緒，一個負責接收客戶端的資料包並向真實伺服器傳送資料包，另一個負責接收伺服器發的資料包並修改目的地址傳送給客戶端。如此一來，通過兩個DatagramSocket兩個執行緒就實現了一個P2P的UDP轉發隧道。

注意，UDP報文是沒有FIN這種識別符號的，所以代理伺服器無法知道連線是否被主動關閉，只能通過超時時間去判斷，所以為了連線保活，需要客戶端定時傳送心跳包。另外，如果埠是固定的話也可以讓代理伺服器建立永久的轉發通道，只不過這樣資源開銷比較大，不適合高併發的場景。

上面的兩種方式都面臨一個問題，就是併發訪問的問題。所謂併發訪問就是代理伺服器反向代理了一個埠，然後有不止一個客戶端連結這個埠，或者一個客戶端呼叫了多個程式併發訪問該埠，那麼如果程式碼上不做處理就會引起UDP資料包傳遞的混亂。

舉個例子，比如客戶端A向DNS反向代理髮送了一個DNS請求，還沒收到返回訊息的時候客戶端B也發出了一個DNS請求，這時代理伺服器收到了真實伺服器發來的客戶端A請求的響應，由於UDP是無連線協議，所以此時代理伺服器並不知道應該把資料包發到哪去。不向TCP那樣獲取到Socket之後直接寫流就可以了。所以需要我們用JAVA程式碼去維護一個路由表。也就是說，當用戶A請求DNS的時候，記錄下A的源IP和埠號，然後new DatagramSocket向真實伺服器發出請求，然後再用這個DatagramSOcket的receive()去接收返回資料包，然後按照剛才記錄的A的ip和埠把資料傳送回去，同理如果多個客戶端來請求，那麼就需要new 多個DatagramSOcket並記錄每個請求的源IP和埠。如果多個客戶端複用同一個DatagramSocket向真實伺服器傳送訊息，雖然可以把資料包傳送出去，但是收到響應以後你就無從獲知是哪個客戶端請求的了，所以這樣做就會導致資料包錯發的問題，會出現把客戶端A請求DNS的響應錯發給B，B本來請求的是www.csdn.com的IP，但是代理卻發給它www.baidu.com的IP，這是和TCP最大的區別。如下圖黃色圖示標出的請求和相應資訊，就發生了這種錯亂：

總結一下過程如下

1、一個客戶端發出一個DNS請求到代理伺服器53埠，開放埠50000監聽返回值。代理端使用兩個DatagramSocket，一個監聽53埠，與客戶端收發資料，另一個開放51000埠用來與真實伺服器收發資料。真實伺服器只開放一個53埠

2、n個客戶端各發出一個DNS請求，每個客戶端都開放50000埠監聽返回資料，代理端使用1+n個DatagramSocket，開放53和另外n個UDP埠，並在記憶體中記錄好每個客戶端的源IP和埠，第一個DatagramSocket用來和所有客戶端收發資料，後n個用來和真實伺服器收發資料。

3、n個客戶端都同時發出m個DNS請求，每個客戶端開放50000，50001，50002...接收返回資料，代理端使用1+m*n個DatagramSocket，開放53和m*n個UDP埠，記錄好每一個請求的源IP和埠，第一個DatagramSocket用來和所有客戶端收發資料，後m*n個用來和真實伺服器收發資料。

總的來說，有一點很重要，那就是同一會話使用同一個DatagramSocket,不同的會話使用不同的DatagramSocket，每一個UDP有兩個會話，其中客戶端和代理伺服器的會話是所有客戶端公用一個DatagramSocket，就像TCP裡面的ServerSocket，代理伺服器和真實伺服器之間每個會話使用不同DatagramSocket，就像TCP裡面為每個連線new的SOcket物件。當真實伺服器響應了資料之後，一定要弄清楚該資料是發給哪個客戶端的，而辨別的要點就是埠號，將代理端開放的埠和客戶端傳送的埠做一一對映的關係表，就不會錯亂了。

打成Jar包並且把Main.java設為主類，然後執行下面語句（JRE 1.7以上版本）

單個數據包收發（一發必有一收）

java -jar tcptunnel-0.1.0.jar 53 8.8.8.8 53 --udp-dns

java -jar tcptunnel-0.1.0.jar 7000 xxx.xxx.xxx.xxx 9999 --udp-tun