UDP打洞技術2

這篇文章主要要研究的，就是非常有名的"UDP打洞技術"，UDP打洞技術依賴於由公用防火牆和cone NAT，允許適當的有計劃的端對端應用程式通過NAT"打洞"，即使當雙方的主機都處於NAT之後。這種技術在 RFC3027的5.1節[NAT PROT] 中進行了重點介紹，並且在Internet[KEGEL]中進行了非正式的描敘，還應用到了最新的一些協議，例如[TEREDO,ICE]協議中。不過，我們要注意的是，"術"如其名，UDP打洞技術的可靠性全都要依賴於UDP。 這裡將考慮兩種典型情境，來介紹串連的雙方應用程式如何按照計劃的進行通訊的，第一種情境，我們假設兩個用戶端都處於不同的NAT之後；第二種情境，我們假設兩個用戶端都處於同一個NAT之後，但是它們彼此都不知道(他們在同一個NAT中)。
 處於不同NAT之後的用戶端通訊 

我們假設 Client A 和 Client B 都擁有自己的私人IP地址，並且都處在不同的NAT之後，端對端的程式運行於 CLIENT A,CLIENT B,S之間，並且它們都開放了UDP連接埠1234。 CLIENT A和CLIENT B首先分別與S建立通訊會話，這時NAT A把它自己的UDP連接埠62000分配給CLIENT A與S的會話，NAT B也把自己的UDP連接埠31000分配給CLIENT B與S的會話。如所示：

 

 

假如這個時候 CLIENT A 想與 CLIENT B建立一條UDP通訊直連，如果 CLIENT A只是簡單的發送一個UDP資訊到CLIENT B的公網地址138.76.29.7:31000的話，NAT B會不加考慮的將這個資訊丟棄（除非NAT B是一個 full cone NAT），因為 這個UDP資訊中所包含的地址資訊，與CLIENT B和伺服器S建立串連時儲存在NAT B中的伺服器S的地址資訊不符。同樣的，CLIENT B如果做同樣的事情，發送的UDP資訊也會被 NAT A 丟棄。

 

假如 CLIENT A 開始發送一個 UDP 資訊到 CLIENT B 的公網地址上，與此同時，他又通過S中轉寄送了一個邀請資訊給CLIENT B，請求CLIENT B也給CLIENT A發送一個UDP資訊到 CLIENT A的公網地址上。這時CLIENT A向CLIENT B的公網IP(138.76.29.7:31000)發送的資訊導致 NAT A 開啟一個處於 CLIENT A的私人地址和CLIENT B的公網地址之間的新的通訊會話，與此同時，NAT B 也開啟了一個處於CLIENT B的私人地址和CLIENT A的公網地址(155.99.25.11:62000)之間的新的通訊會話。一旦這個新的UDP會話各自向對方開啟了，CLIENT A和CLIENT B之間就可以直接通訊，而無需S來牽線搭橋了。(這就是所謂的打洞技術)！