P2P 之 UDP穿透NAT的原理與實現

P2P 之 UDP穿透NAT的原理與實現

P2P 之 UDP穿透NAT的原理與實現 摘自DELPHI盒子 http://www.2ccc.com/article.asp?articleid=2048

P2P 之 UDP穿透NAT的原理與實現

原創:shootingstars

參考:http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

論壇上經常有對P2P原理的討論,但是討論歸討論,很少有實質的東西産生(源代碼)。呵呵,在這裏我就用自己實現的一個源代碼來說明UDP

穿越NAT的原理。

首先先介紹一些基本概念:

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

|

^ 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的端口是順序分配的,那麽我們或許可以猜測這個端口號,可是由于可能導致失敗的因素太多,我們不推

薦這種猜測端口的方法)。

下面是一個模擬P2P聊天的過程的源代碼,過程很簡單,P2PServer運行在一個擁有公網IP的計算機上,P2PClient運行在兩個不同的NAT後

(注意,如果兩個客戶端運行在一個NAT後,本程序很可能不能運行正常,這取決于你的NAT是否支持loopback translation,詳見

http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt,當然,此問題可以通過雙方先嘗試連接對方的內網IP來解決,但是這

個代碼只是爲了驗證原理,並沒有處理這些問題),後登錄的計算機可以獲得先登錄計算機的用戶名,後登錄的計算機通過send username

message的格式來發送消息。如果發送成功,說明你已取得了直接與對方連接的成功。

P2P 之 UDP穿透NAT的原理與實現
P2P 之 UDP穿透NAT的原理與實現 P2P 之 UDP穿透NAT的原理與實現 摘自DELPHI盒子 http://www.2ccc.com/article.asp?articleid=2048P2P 之 UDP穿透NAT的原理與實現原創:shootingstars參考:http://midcom-p2p...查看完整版>>P2P 之 UDP穿透NAT的原理與實現
 
P2P之UDP穿透NAT的原理與實現
P2P之UDP穿透NAT的原理與實現 P2P之UDP穿透NAT的原理與實現...查看完整版>>P2P之UDP穿透NAT的原理與實現
 
P2P之UDP穿透NAT的原理與實現
論壇上經常有對P2P原理的討論,但是討論歸討論,很少有實質的東西産生(源代碼)。呵呵,在這裏我就用自己實現的一個源代碼來說明UDP穿越NAT的原理。首先先介紹一些基本概念: NAT(Network Address Translators),...查看完整版>>P2P之UDP穿透NAT的原理與實現
 
P2P 之 UDP穿透NAT的原理與實現(附源代碼)
原創:shootingstars參考:http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt論壇上經常有對P2P原理的討論,但是討論歸討論,很少有實質的東西産生(源代碼)。呵呵,在這裏我就用自己實現的一個源代...查看完整版>>P2P 之 UDP穿透NAT的原理與實現(附源代碼)
 
P2P 之 UDP穿透NAT的原理與實現
摘自DELPHI盒子 P2P 之 UDP穿透NAT的原理與實現原創:shootingstars參考:論壇上經常有對P2P原理的討論,但是討論歸討論,很少有實質的東西産生(源代碼)。呵呵,在這裏我就用自己實現的一個源代碼來說明UDP穿越NAT...查看完整版>>P2P 之 UDP穿透NAT的原理與實現
 
P2P之UDP穿透NAT的原理與C#實現
P2P之UDP穿透NAT的原理與實現聲明:原文來自P2P中國網,C#實現是本人做的,供參考關鍵字:P2P, UDP, NAT, .NET 論壇上經常有對P2P原理的討論,但是討論歸討論,很少有實質的東西産生(源代碼)。呵呵,在這裏我就用自...查看完整版>>P2P之UDP穿透NAT的原理與C#實現
 
P2P之UDP穿透NAT的原理與實現(shootingstars)--增強篇(附源代碼)
源碼下載: P2P之UDP穿透NAT的原理與實現(shootingstars) 文章說明: 關于UDP穿透NAT的中文資料在網絡上是很少的,僅有<<P2P之UDP穿透NAT的原理與實現(shootingstars)>>這篇文章有實際的參考價值。本人近...查看完整版>>P2P之UDP穿透NAT的原理與實現(shootingstars)--增強篇(附源代碼)
 
P2P 之 TCP穿透NAT的原理 【轉】
一般情況下,位于防火牆或者NAT後面的設備是不可能直接建立TCP連接的,大多數情況需要有Server中轉,CMU的牛人門討論了NAT後面的設備之間直接建立連接的方法: 中文翻譯見:原文:本人還在消化中,希望高人來指點指點...查看完整版>>P2P 之 TCP穿透NAT的原理 【轉】
 
穿透Socks5 代理的UDP編程穿透Socks5 代理的UDP編程
網絡編程中,對于數據傳輸實時性要求較高的場合,大家都會選擇UDP來作爲數據傳輸協議,在TCP/IP協議族中UDP協議較TCP協議需要的網絡系統資源更少。然而在企業應用中,由于網絡安全原因等會導致除了特定端口以外的IP數...查看完整版>>穿透Socks5 代理的UDP編程穿透Socks5 代理的UDP編程
 
 
回到王朝網路移動版首頁