?
論壇上經(jīng)常有對P2P原理的討論，但是討論歸討論，很少有實(shí)質(zhì)的東西產(chǎn)生（源代碼）。呵呵，在這里我就用自己實(shí)現(xiàn)的一個源代碼來說明UDP穿越NAT的原理。
首先先介紹一些基本概念：
NAT(Network Address Translators)，網(wǎng)絡(luò)地址轉(zhuǎn)換：網(wǎng)絡(luò)地址轉(zhuǎn)換是在IP地址日益缺乏的情況下產(chǎn)生的，它的主要目的就是為了能夠地址重用。NAT分為兩大類，基本的NAT和NAPT(Network Address/Port Translator)。
最開始NAT是運(yùn)行在路由器上的一個功能模塊。
最先提出的是基本的NAT，它的產(chǎn)生基于如下事實(shí)：一個私有網(wǎng)絡(luò)（域）中的節(jié)點(diǎn)中只有很少的節(jié)點(diǎn)需要與外網(wǎng)連接（呵呵，這是在上世紀(jì)90年代中期提出的）。那么這個子網(wǎng)中其實(shí)只有少數(shù)的節(jié)點(diǎn)需要全球唯一的IP地址，其他的節(jié)點(diǎn)的IP地址應(yīng)該是可以重用的。
因此，基本的NAT實(shí)現(xiàn)的功能很簡單，在子網(wǎng)內(nèi)使用一個保留的IP子網(wǎng)段，這些IP對外是不可見的。子網(wǎng)內(nèi)只有少數(shù)一些IP地址可以對應(yīng)到真正全球唯一的IP地址。如果這些節(jié)點(diǎn)需要訪問外部網(wǎng)絡(luò)，那么基本NAT就負(fù)責(zé)將這個節(jié)點(diǎn)的子網(wǎng)內(nèi)IP轉(zhuǎn)化為一個全球唯一的IP然后發(fā)送出去。(基本的NAT會改變IP包中的原IP地址，但是不會改變IP包中的端口)
關(guān)于基本的NAT可以參看RFC 1631
另外一種NAT叫做NAPT，從名稱上我們也可以看得出，NAPT不但會改變經(jīng)過這個NAT設(shè)備的IP數(shù)據(jù)報(bào)的IP地址，還會改變IP數(shù)據(jù)報(bào)的TCP/UDP端口。基本NAT的設(shè)備可能我們見的不多（呵呵，我沒有見到過），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
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 10.0.0.1:1234 v |
|
Client A
10.0.0.1:1234
有一個私有網(wǎng)絡(luò)10.*.*.*，Client A是其中的一臺計(jì)算機(jī)，這個網(wǎng)絡(luò)的網(wǎng)關(guān)（一個NAT設(shè)備）的外網(wǎng)IP是155.99.25.11(應(yīng)該還有一個內(nèi)網(wǎng)的IP地址，比如10.0.0.10)。如果Client A中的某個進(jìn)程（這個進(jìn)程創(chuàng)建了一個UDP Socket,這個Socket綁定1234端口）想訪問外網(wǎng)主機(jī)18.181.0.31的1235端口，那么當(dāng)數(shù)據(jù)包通過NAT時會發(fā)生什么事情呢？
首先NAT會改變這個數(shù)據(jù)包的原IP地址，改為155.99.25.11。接著NAT會為這個傳輸創(chuàng)建一個Session（Session是一個抽象的概念，如果是TCP，也許Session是由一個SYN包開始，以一個FIN包結(jié)束。而UDP呢，以這個IP的這個端口的第一個UDP開始，結(jié)束呢，呵呵，也許是幾分鐘，也許是幾小時，這要看具體的實(shí)現(xiàn)了）并且給這個Session分配一個端口，比如62000，然后改變這個數(shù)據(jù)包的源端口為62000。所以本來是（10.0.0.1:1234->18.181.0.31:1235）的數(shù)據(jù)包到了互聯(lián)網(wǎng)上變?yōu)榱耍?/span>155.99.25.11:62000->18.181.0.31:1235）。
一旦NAT創(chuàng)建了一個Session后，NAT會記住62000端口對應(yīng)的是10.0.0.1的1234端口，以后從18.181.0.31發(fā)送到62000端口的數(shù)據(jù)會被NAT自動的轉(zhuǎn)發(fā)到10.0.0.1上。（注意：這里是說18.181.0.31發(fā)送到62000端口的數(shù)據(jù)會被轉(zhuǎn)發(fā)，其他的IP發(fā)送到這個端口的數(shù)據(jù)將被NAT拋棄）這樣Client A就與Server S1建立以了一個連接。
呵呵，上面的基礎(chǔ)知識可能很多人都知道了，那么下面是關(guān)鍵的部分了。
看看下面的情況：
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發(fā)送了一個UDP包，那么這個UDP包在通過NAT時會怎么樣呢？
這時可能會有兩種情況發(fā)生，一種是NAT再次創(chuàng)建一個Session，并且再次為這個Session分配一個端口號（比如：62001）。另外一種是NAT再次創(chuàng)建一個Session，但是不會新分配一個端口號，而是用原來分配的端口號62000。前一種NAT叫做Symmetric NAT，后一種叫做Cone NAT。我們期望我們的NAT是第二種，呵呵，如果你的NAT剛好是第一種，那么很可能會有很多P2P軟件失靈。（可以慶幸的是，現(xiàn)在絕大多數(shù)的NAT屬于后者，即Cone NAT）
好了，我們看到，通過NAT,子網(wǎng)內(nèi)的計(jì)算機(jī)向外連結(jié)是很容易的（NAT相當(dāng)于透明的，子網(wǎng)內(nèi)的和外網(wǎng)的計(jì)算機(jī)不用知道NAT的情況）。
但是如果外部的計(jì)算機(jī)想訪問子網(wǎng)內(nèi)的計(jì)算機(jī)就比較困難了（而這正是P2P所需要的）。
那么我們?nèi)绻霃耐獠堪l(fā)送一個數(shù)據(jù)報(bào)給內(nèi)網(wǎng)的計(jì)算機(jī)有什么辦法呢？首先，我們必須在內(nèi)網(wǎng)的NAT上打上一個“洞”（也就是前面我們說的在NAT上建立一個Session），這個洞不能由外部來打，只能由內(nèi)網(wǎng)內(nèi)的主機(jī)來打。而且這個洞是有方向的，比如從內(nèi)部某臺主機(jī)（比如：192.168.0.10）向外部的某個IP(比如：219.237.60.1)發(fā)送一個UDP包，那么就在這個內(nèi)網(wǎng)的NAT設(shè)備上打了一個方向?yàn)?/span>219.237.60.1的“洞”，（這就是稱為UDP Hole Punching的技術(shù)）以后219.237.60.1就可以通過這個洞與內(nèi)網(wǎng)的192.168.0.10聯(lián)系了。（但是其他的IP不能利用這個洞）。
呵呵，現(xiàn)在該輪到我們的正題P2P了。有了上面的理論，實(shí)現(xiàn)兩個內(nèi)網(wǎng)的主機(jī)通訊就差最后一步了：那就是雞生蛋還是蛋生雞的問題了，兩邊都無法主動發(fā)出連接請求，誰也不知道誰的公網(wǎng)地址，那我們?nèi)绾蝸泶蜻@個洞呢？我們需要一個中間人來聯(lián)系這兩個內(nèi)網(wǎng)主機(jī)。
現(xiàn)在我們來看看一個P2P軟件的流程，以下圖為例：
Server S （219.237.60.1）
|
|
+----------------------+----------------------+
| |
NAT A (外網(wǎng)IP:202.187.45.3) NAT B (外網(wǎng)IP:187.34.1.56)
| (內(nèi)網(wǎng)IP:192.168.0.1) | (內(nèi)網(wǎng)IP:192.168.0.1)
| |
Client A (192.168.0.20:4000) Client B (192.168.0.10:40000)
首先，Client A登錄服務(wù)器，NAT A為這次的Session分配了一個端口60000，那么Server S收到的Client A的地址是202.187.45.3:60000，這就是Client A的外網(wǎng)地址了。同樣，Client B登錄Server S，NAT B給此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。
此時，Client A與Client B都可以與Server S通信了。如果Client A此時想直接發(fā)送信息給Client B，那么他可以從Server S那兒獲得B的公網(wǎng)地址187.34.1.56:40000，是不是Client A向這個地址發(fā)送信息Client B就能收到了呢？答案是不行，因?yàn)槿绻@樣發(fā)送信息，NAT B會將這個信息丟棄（因?yàn)檫@樣的信息是不請自來的，為了安全，大多數(shù)NAT都會執(zhí)行丟棄動作）。現(xiàn)在我們需要的是在NAT B上打一個方向?yàn)?/span>202.187.45.3（即Client A的外網(wǎng)地址）的洞，那么Client A發(fā)送到187.34.1.56:40000的信息,Client B就能收到了。這個打洞命令由誰來發(fā)呢，呵呵，當(dāng)然是Server S。
總結(jié)一下這個過程：如果Client A想向Client B發(fā)送信息，那么Client A發(fā)送命令給Server S，請求Server S命令Client B向Client A方向打洞。呵呵，是不是很繞口，不過沒關(guān)系，想一想就很清楚了，何況還有源代碼呢（侯老師說過：在源代碼面前沒有秘密 8）），然后Client A就可以通過Client B的外網(wǎng)地址與Client B通信了。
注意：以上過程只適合于Cone NAT的情況，如果是Symmetric NAT，那么當(dāng)Client B向Client A打洞的端口已經(jīng)重新分配了，Client B將無法知道這個端口（如果Symmetric NAT的端口是順序分配的，那么我們或許可以猜測這個端口號，可是由于可能導(dǎo)致失敗的因素太多，我們不推薦這種猜測端口的方法）。
下面是一個模擬P2P聊天的過程的源代碼，過程很簡單，P2PServer運(yùn)行在一個擁有公網(wǎng)IP的計(jì)算機(jī)上，P2PClient運(yùn)行在兩個不同的NAT后（注意，如果兩個客戶端運(yùn)行在一個NAT后，本程序很可能不能運(yùn)行正常，這取決于你的NAT是否支持loopback translation，詳見http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt，當(dāng)然，此問題可以通過雙方先嘗試連接對方的內(nèi)網(wǎng)IP來解決，但是這個代碼只是為了驗(yàn)證原理，并沒有處理這些問題），后登錄的計(jì)算機(jī)可以獲得先登錄計(jì)算機(jī)的用戶名，后登錄的計(jì)算機(jī)通過send username message的格式來發(fā)送消息。如果發(fā)送成功，說明你已取得了直接與對方連接的成功。
程序現(xiàn)在支持三個命令：send , getu , exit
send格式：send username message
功能：發(fā)送信息給username
getu格式：getu
功能：獲得當(dāng)前服務(wù)器用戶列表
exit格式：exit
功能：注銷與服務(wù)器的連接（服務(wù)器不會自動監(jiān)測客戶是否吊線）
代碼很短，相信很容易懂，如果有什么問題，可以給我發(fā)郵件zhouhuis22@sina.com 或者在CSDN上發(fā)送短消息。同時，歡迎轉(zhuǎn)發(fā)此文，但希望保留作者版權(quán)8-）。http://blog.sina.com.cn/u/4994d22f010002yy
1關(guān)于udp的穿越 ?
? 參考文獻(xiàn)?《UDP穿透NAT的原理與實(shí)現(xiàn)》 ?
? 2 ? 關(guān)于tcp的穿越 ?
? 由于tcp是面向連接的，socket需要連接之后才能發(fā)送信息，所以不能等同于udp處理。
? 參考《TCP ? Connections ? for ? P2P ? Apps: ? A ? Software ? Approach ? to ? Solving ? the ? NAT ? Problem》 ?
? 可以這樣處理： ?
? 每一個客戶端建立三個socket: ?
? socket1：可以是TCP，也可以是UDP，用于客戶端和服務(wù)器交換信息，本圖中使用UDP. ?
? Socket2：TCP連接的socket ?
? Socket3：TCP連接的socket，并且和socket2復(fù)用同一個IP地址和端口 ?
? 發(fā)送方需要4個socket ?
? socket4：TCP連接的socket，用于監(jiān)聽用戶的連接，和socket2復(fù)用同一個地址 ?
? ? 圖中，Initiator和Recipient都是客戶端，只是Initiator需要從Recipient上獲得所需要的東西，Initiator和Recipient都位于NAT設(shè)備后面，NAT設(shè)備分別是NATI和NATR。Broker是服務(wù)器，Initiator和Recipient都需要先注冊在服務(wù)器上。 ?
? 1．客戶端內(nèi)部地址R:T，經(jīng)過轉(zhuǎn)換后的地址NR:U，建立socket1，連接服務(wù)器的B:V進(jìn)行注冊。 ?
? 2．服務(wù)器在socket1返回注冊信息。 ?
? 3．客戶端Initiator內(nèi)部地址I:X，經(jīng)過轉(zhuǎn)換后的地址NI:Y，建立socket2，連接服務(wù)器的B:Z，發(fā)送一個請求。服務(wù)器返回的是一個公網(wǎng)的地址，用于Initiator連接后獲取內(nèi)容（第10步） ?
? 4．服務(wù)器收到Initiator的請求，查看到Initiator可以從Recipient上獲得內(nèi)容，使用socket1告訴Recipient有人需要連接。 ?
? 5． Recipient使用內(nèi)部地址R:J，經(jīng)過轉(zhuǎn)換后的地址NR:K，建立socket2，連接到服務(wù)器的B:Z，告訴服務(wù)器它的公網(wǎng)地址。（用于判斷Recipient是否處于NAT后面，是否需要打洞，本例中肯定是需要打洞了。） ?
? 6．服務(wù)器使用socket2返回給Recipient需要連接的用戶的公網(wǎng)地址NI:Y。 ?
? 7． Recipient使用socket3連接NI:Y，用于打一個洞。socket3和socket2地址完全一樣，使用了端口復(fù)用技術(shù)（代碼：bool ? buse ? = ? true; ? setsockopt(sock, ? SOL_SOCKET, ? SO_REUSEADDR, ? (char*)&buse, ? sizeof(buse));） ?
? 8．返回的結(jié)果肯定錯誤，怎么能連通那？ ?
? 9．可以使用socket1告訴服務(wù)器，socket4已經(jīng)處于監(jiān)聽狀態(tài)了，并且告訴服務(wù)器公網(wǎng)地址。 ?
? 10．服務(wù)器使用socket2告訴Initiator處于監(jiān)聽狀態(tài)的公網(wǎng)地址 ?
? 11． Initiator向公網(wǎng)連接。?
?