轉自：http://www.2cto.com/net/201201/116793.html

?

NAT(Network Address Translators)，網絡地址轉換：網絡地址轉換是在IP地址日益缺乏的情況下產生的，它的主要目的就是為了能夠地址重用。NAT分為兩大類，基本的NAT和NAPT(Network Address/Port Translator)。 最開始NAT是運行在路由器上的一個功能模塊。
???????? 最先提出的是基本的NAT，它的產生基于如下事實：一個私有網絡（域）中的節點中只有很少的節點需要與外網連接（呵呵，這是在上世紀90年代中期提出的）。那么這個子網中其實只有少數的節點需要全球唯一的IP地址，其他的節點的IP地址應該是可以重用的。
　　因此，基本的NAT實現的功能很簡單，在子網內使用一個保留的IP子網段，這些IP對外是不可見的。子網內只有少數一些IP地址可以對應到真正全球唯一的IP地址。如果這些節點需要訪問外部網絡，那么基本NAT就負責將這個節點的子網內IP轉化為一個全球唯一的IP然后發送出去。(基本的NAT會改變IP包中的原IP地址，但是不會改變IP包中的端口)
關于基本的NAT可以參看RFC 1631
?
　　另外一種NAT叫做NAPT，從名稱上我們也可以看得出，NAPT不但會改變經過這個NAT設備的IP數據報的IP地址，還會改變IP數據報的TCP/UDP端口。
??????? 網絡地址端口轉化NAPT（Network Address Port Translation）是人們比較熟悉的一種轉化方式。NAPT普遍應用于接入設備中，它可以將中小型的網絡隱藏在一個合法的IP地址后面。NAPT與動態地址NAT不同，它將內部連接映射到外部網絡中的一個單獨的IP地址上，同時在該地址上加一個由NAT設備選定的TCP端口號。
??? NAPT使得一組主機可以共享唯一的外部地址，當位于內部網絡中的主機通過NAT設備向外部主機發起會話請求時，NAT設備就會查詢NAT表，看是否有相關的會話記錄，如果有記錄就將內部IP地址及端口同時進行轉換，再轉發出去嗎；如果沒有相關記錄，進行IP地址和端口轉換的同時，還會在NAT表中增加一個該會話的記錄。外部主機接收到數據包后，用接收到的合法公網地址及端口作為目的IP地址及端口來回應，NAT設備接收到外部回來的數據包，再根據NAT表中的記錄把目的地址及端口轉換成對應的內部IP地址及端口，轉發給該內部主機。
NAPT是把內部地址映射到外部網絡的一個IP地址的不同端口上。
基本NAT的設備可能我們見的不多（呵呵，我沒有見到過），NAPT才是我們真正討論的主角?？聪聢D：
Server S1
18.181.0.31:1235
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 155.99.25.11:62000 v |
|
NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 10.0.0.1:1234 v |
|
Client A
10.0.0.1:1234
　　有一個私有網絡10.*.*.*，Client A是其中的一臺計算機，這個網絡的網關（一個NAT設備）的外網IP是155.99.25.11(應該還有一個內網的IP地址，比如10.0.0.10)。如果Client A中的某個進程（這個進程創建了一個UDP Socket,這個Socket綁定1234端口）想訪問外網主機18.181.0.31的1235端口，那么當數據包通過NAT時會發生什么事情呢？
　　首先NAT會改變這個數據包的原IP地址，改為155.99.25.11。接著NAT會為這個傳輸創建一個Session（Session是一個抽象的概念，如果是TCP，也許Session是由一個SYN包開始，以一個FIN包結束。而UDP呢，以這個IP的這個端口的第一個UDP開始，結束呢，呵呵，也許是幾分鐘，也許是幾小時，這要看具體的實現了）并且給這個Session分配一個端口，比如62000，然后改變這個數據包的源端口為62000。所以本來是（10.0.0.1:1234->18.181.0.31:1235）的數據包到了互聯網上變為了（155.99.25.11:62000->18.181.0.31:1235）。
一旦NAT創建了一個Session后，NAT會記住62000端口對應的是10.0.0.1的1234端口，以后從18.181.0.31發送到62000端口的數據會被NAT自動的轉發到10.0.0.1上。（注意：這里是說18.181.0.31發送到62000端口的數據會被轉發，其他的IP發送到這個端口的數據將被NAT拋棄）這樣Client A就與Server S1建立以了一個連接。
?
呵呵，上面的基礎知識可能很多人都知道了，那么下面是關鍵的部分了。
看看下面的情況：
Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235
| |
| |
+----------------------+----------------------+
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 155.99.25.11:62000 v | v 155.99.25.11:62000 v
|
Cone NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
|
Client A
10.0.0.1:1234
　　接上面的例子，如果Client A的原來那個Socket(綁定了1234端口的那個UDP Socket)又接著向另外一個Server S2發送了一個UDP包，那么這個UDP包在通過NAT時會怎么樣呢？
　　這時可能會有兩種情況發生，一種是NAT再次創建一個Session，并且再次為這個Session分配一個端口號（比如：62001）。另外一種是NAT再次創建一個Session，但是不會新分配一個端口號，而是用原來分配的端口號62000。前一種NAT叫做Symmetric NAT，后一種叫做Cone NAT。我們期望我們的NAT是第二種，呵呵，如果你的NAT剛好是第一種，那么很可能會有很多P2P軟件失靈。（可以慶幸的是，現在絕大多數的NAT屬于后者，即Cone NAT）
?
　　好了，我們看到，通過NAT,子網內的計算機向外連結是很容易的（NAT相當于透明的，子網內的和外網的計算機不用知道NAT的情況）。
但是如果外部的計算機想訪問子網內的計算機就比較困難了（而這正是P2P所需要的）。
　　那么我們如果想從外部發送一個數據報給內網的計算機有什么辦法呢？首先，我們必須在內網的NAT上打上一個“洞”（也就是前面我們說的在NAT上建立一個Session），這個洞不能由外部來打，只能由內網內的主機來打。而且這個洞是有方向的，比如從內部某臺主機（比如：192.168.0.10）向外部的某個IP(比如：219.237.60.1)發送一個UDP包，那么就在這個內網的NAT設備上打了一個方向為219.237.60.1的“洞”，（這就是稱為UDP Hole Punching的技術）以后219.237.60.1就可以通過這個洞與內網的192.168.0.10聯系了。（但是其他的IP不能利用這個洞）。
?
　　呵呵，現在該輪到我們的正題P2P了。有了上面的理論，實現兩個內網的主機通訊就差最后一步了：那就是雞生蛋還是蛋生雞的問題了，兩邊都無法主動發出連接請求，誰也不知道誰的公網地址，那我們如何來打這個洞呢？我們需要一個中間人來聯系這兩個內網主機。
現在我們來看看一個P2P軟件的流程，以下圖為例：
?
Server S （219.237.60.1）
|
|
+----------------------+----------------------+
| |
NAT A (外網IP:202.187.45.3)???? NAT B (外網IP:187.34.1.56)
| (內網IP:192.168.0.1)???? |????????????? (內網IP:192.168.0.1)
| |
Client A (192.168.0.20:4000)????? Client B (192.168.0.10:40000)
?
　　首先，Client A登錄服務器，NAT A為這次的Session分配了一個端口60000，那么Server S收到的Client A的地址是202.187.45.3:60000，這就是Client A的外網地址了。同樣，Client B登錄Server S，NAT B給此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。
　　此時，Client A與Client B都可以與Server S通信了。如果Client A此時想直接發送信息給Client B，那么他可以從Server S那兒獲得B的公網地址187.34.1.56:40000，是不是Client A向這個地址發送信息Client B就能收到了呢？答案是不行，因為如果這樣發送信息，NAT B會將這個信息丟棄（因為這樣的信息是不請自來的，為了安全，大多數NAT都會執行丟棄動作）。現在我們需要的是在NAT B上打一個方向為202.187.45.3（即Client A的外網地址）的洞，那么Client A發送到187.34.1.56:40000的信息,Client B就能收到了。這個打洞命令由誰來發呢，呵呵，當然是Server S。
　　總結一下這個過程：如果Client A想向Client B發送信息，那么Client A發送命令給Server S，請求Server S命令Client B向Client A方向打洞。呵呵，是不是很繞口，不過沒關系，想一想就很清楚了，何況還有源代碼呢（侯老師說過：在源代碼面前沒有秘密8）），然后Client A就可以通過Client B的外網地址與Client B通信了。
?
　　注意：以上過程只適合于Cone NAT的情況，如果是Symmetric NAT，那么當Client B向Client A打洞的端口已經重新分配了，Client B將無法知道這個端口（如果Symmetric NAT的端口是順序分配的，那么我們或許可以猜測這個端口號，可是由于可能導致失敗的因素太多，我們不推薦這種猜測端口的方法）。

轉載于:https://www.cnblogs.com/x_wukong/p/5759847.html

總結

以上是生活随笔為你收集整理的UDP穿透NAT原理解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。