首先先介紹一些基本概念：
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端口。基本NAT的裝置可能我們見的不多（呵呵，我沒有見到過），NAPT才是我們真正讨論的主角。看下圖：
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
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
v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
接上面的例子，如果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的端口是順序配置設定的，那麼我們或許可以猜測這個端口号，可是由于可能導緻失敗的因素太多，我們不推薦這種猜測端口的方法）。
另一篇文章接上：
下面解釋一下上面的文章中沒有提及或者說我覺得比較欠缺的地方.
私有位址/端口和公有位址/端口:我們知道,現在大部分網絡采用的都是NAPT(Network Address/Port Translator)了,這個東東的作用是一個對外的對話在經過NAT之後IP位址和端口号都會被改寫,在這裡把一次會話中客戶自己認為在使用的IP位址和端口号成為私有位址/端口,而把經過NAPT之後被改寫的IP位址和端口号稱為公有位址/端口.或者可以這麼了解,私有位址/端口是你家裡人對你的昵稱而公有位址/端口則是你真正對外公開的名字.如何獲得使用者的私用位址/端口号,這個很簡單了,而要得到公有位址/端口号就要在連接配接上另一台機器之後由那台機器看到的IP位址和端口号來表示.
如果明白了上面的東西,下面進入我們的代碼,在這裡解釋一下關鍵部分的實作:
用戶端首先得到自己的私有位址/終端,然後向server端發送登陸請求,server端在得到這個請求之後就可以知道這個client端的公有位址/終端,server會為每一個登陸的client儲存它們的私有位址/端口和公有位址/端口.
OK,下面開始關鍵的打洞流程.假設client A要向client B對話,但是A不知道B的位址,即使知道根據NAT的原理這個對話在第一次會被拒絕,因為client B的NAT認為這是一個從沒有過的外部發來的請求.這個時候,A如果發現自己沒有儲存B的位址,或者說發送給B的會話請求失敗了,它會要求server端讓B向A打一個洞,這個B->A的會話意義在于它使NAT B認為A的位址/端口是可以通過的位址/端口,這樣A再向B發送對話的時候就不會再被NAT B拒絕了.打一個比方來說明打洞的過程,A想來B家做客,但是遭到了B的管家NAT B的拒絕,理由是:我從來沒有聽我家B提過你的名字,這時A找到了A,B都認識的朋友server,要求server給B報一個信,讓B去跟管家說A是我的朋友,于是,B跟管家NAT B說,A是我認識的朋友,這樣A的通路請求就不會再被管家NAT B所拒絕了.簡而言之,UDP打洞就是一個通過server儲存下來的位址使得彼此之間能夠直接通信的過程,server隻管幫助建立連接配接,在建立間接之後就不再介入了.
下面是一個模拟P2P聊天的過程的源代碼，過程很簡單，P2PServer運作在一個擁有公網IP的計算機上，P2PClient運作在兩個不同的NAT後（注意，如果兩個用戶端運作在一個NAT後，本程式很可能不能運作正常，這取決于你的NAT是否支援loopback
username message的格式來發送消息。如果發送成功，說明你已取得了直接與對方連接配接的成功。
程式現在支援三個指令：send , getu , exit
send格式：send username message
功能：發送資訊給username
getu格式：getu
功能：獲得目前伺服器使用者清單
exit格式：exit
功能：登出與伺服器的連接配接（伺服器不會自動監測客戶是否吊線）
或者在CSDN上發送短消息。同時，歡迎轉發此文，但希望保留作者版權8-）。
_05/04052509317298.rar"
另一篇介紹打洞技術的（補充）
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來牽線搭橋了。(這就是所謂的打洞技術)！