源碼下載: http://www.ppcn.net/upload/2005_08/05080112299104.rar 參考： http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
P2P之UDP穿透NAT的原理與實現(xiàn)(shootingstars)
文章說明:
關(guān)于UDP穿透NAT的中文資料在網(wǎng)絡(luò)上是很少的，僅有<<P2P之UDP穿透NAT的原理與實現(xiàn)(shootingstars)>>這篇文章有實際的參考價值。本人近兩年來也一直從事P2P方面的開發(fā)工作，比較有代表性的是個人開發(fā)的BitTorrent下載軟件 - FlashBT(變態(tài)快車). 對P2P下載或者P2P的開發(fā)感興趣的朋友可以訪問軟件的官方主頁: http://www.hwysoft.com/chs/ 下載看看，說不定有收獲。寫這篇文章的主要目的是懶的再每次單獨回答一些網(wǎng)友的提問, 一次性寫下來, 即節(jié)省了自己的時間，也方便了對于P2P的UDP穿透感興趣的網(wǎng)友閱讀和理解。對此有興趣和經(jīng)驗的朋友可以給我發(fā)郵件或者訪問我的個人Blog留言: http://hwycheng.blogchina.com. 您可以自由轉(zhuǎn)載此篇文章，但是請保留此說明。
再次感謝shootingstars網(wǎng)友的早期貢獻. 表示謝意。
NAT(The IP Network Address Translator) 的概念和意義是什么?
NAT, 中文翻譯為網(wǎng)絡(luò)地址轉(zhuǎn)換。具體的詳細信息可以訪問RFC 1631 - http://www.faqs.org/rfcs/rfc1631.html, 這是對于NAT的定義和解釋的最權(quán)威的描述。網(wǎng)絡(luò)術(shù)語都是很抽象和艱澀的，除非是專業(yè)人士，否則很難從字面中來準確理解NAT的含義。
要想完全明白NAT 的作用，我們必須理解IP地址的兩大分類，一類是私有IP地址，在這里我們稱作內(nèi)網(wǎng)IP地址。一類是非私有的IP地址，在這里我們稱作公網(wǎng)IP地址。關(guān)于IP地址的概念和作用的介紹參見我的另一篇文章: http://hwycheng.blogchina.com/2402121.html
內(nèi)網(wǎng)IP地址: 是指使用A/B/C類中的私有地址, 分配的IP地址在全球不懼有唯一性，也因此無法被其它外網(wǎng)主機直接訪問。公網(wǎng)IP地址: 是指具有全球唯一的IP地址，能夠直接被其它主機訪問的。
NAT 最初的目的是為使用內(nèi)網(wǎng)IP地址的計算機提供通過少數(shù)幾臺具有公網(wǎng)的IP地址的計算機訪問外部網(wǎng)絡(luò)的功能。NAT 負責將某些內(nèi)網(wǎng)IP地址的計算機向外部網(wǎng)絡(luò)發(fā)出的IP數(shù)據(jù)包的源IP地址轉(zhuǎn)換為NAT自己的公網(wǎng)的IP地址，目的IP地址不變, 并將IP數(shù)據(jù)包轉(zhuǎn)發(fā)給路由器，最終到達外部的計算機。同時負責將外部的計算機返回的IP數(shù)據(jù)包的目的IP地址轉(zhuǎn)換為內(nèi)網(wǎng)的IP地址，源IP地址不變，并最終送達到內(nèi)網(wǎng)中的計算機。
圖一: NAT 實現(xiàn)了私有IP的計算機分享幾個公網(wǎng)IP地址訪問Internet的功能。
隨著網(wǎng)絡(luò)的普及，IPv4的局限性暴露出來。公網(wǎng)IP地址成為一種稀缺的資源，此時NAT 的功能局限也暴露出來，同一個公網(wǎng)的IP地址，某個時間只能由一臺私有IP地址的計算機使用。于是NAPT(The IP Network Address/Port Translator)應(yīng)運而生，NAPT實現(xiàn)了多臺私有IP地址的計算機可以同時通過一個公網(wǎng)IP地址來訪問Internet的功能。這在很大程度上暫時緩解了IPv4地址資源的緊張。
NAPT 負責將某些內(nèi)網(wǎng)IP地址的計算機向外部網(wǎng)絡(luò)發(fā)出的TCP/UDP數(shù)據(jù)包的源IP地址轉(zhuǎn)換為NAPT自己的公網(wǎng)的IP地址，源端口轉(zhuǎn)為NAPT自己的一個端口。目的IP地址和端口不變, 并將IP數(shù)據(jù)包發(fā)給路由器，最終到達外部的計算機。同時負責將外部的計算機返回的IP數(shù)據(jù)包的目的IP地址轉(zhuǎn)換內(nèi)網(wǎng)的IP地址，目的端口轉(zhuǎn)為內(nèi)網(wǎng)計算機的端口，源IP地址和源端口不變，并最終送達到內(nèi)網(wǎng)中的計算機。
圖二: NAPT 實現(xiàn)了私有IP的計算機分享一個公網(wǎng)IP地址訪問Internet的功能。
在我們的工作和生活中, NAPT的作用隨處可見，絕大部分公司的網(wǎng)絡(luò)架構(gòu)，都是通過1至N臺支持NAPT的路由器來實現(xiàn)公司的所有計算機連接外部的Internet網(wǎng)絡(luò)的。包括本人在寫這篇文章的時候，也是在家中使用一臺IBM筆記本通過一臺寬帶連接的臺式機來訪問Internet的。我們本篇文章主要討論的NAPT的問題。
NAPT(The IP Network Address/Port Translator) 為何阻礙了P2P軟件的應(yīng)用?
通過NAPT 上網(wǎng)的特點決定了只能由NAPT內(nèi)的計算機主動向NAPT外部的主機發(fā)起連接，外部的主機想直接和NAPT內(nèi)的計算機直接建立連接是不被允許的。IM(即時通訊)而言，這意味著由于NAPT內(nèi)的計算機和NAPT外的計算機只能通過服務(wù)器中轉(zhuǎn)數(shù)據(jù)來進行通訊。對于P2P方式的下載程序而言，意味著NAPT內(nèi)的計算機不能接收到NAPT外部的連接，導(dǎo)致連接數(shù)用過少，下載速度很難上去。因此P2P軟件必須要解決的一個問題就是要能夠在一定的程度上解決NAPT內(nèi)的計算機不能被外部連接的問題。
NAT(The IP Network Address Translator) 進行UDP穿透的原理是什么?
TCP/IP傳輸時主要用到TCP和UDP協(xié)議。TCP協(xié)議是可靠的，面向連接的傳輸協(xié)議。UDP是不可靠的，無連接的協(xié)議。根據(jù)TCP和UDP協(xié)議的實現(xiàn)原理，對于NAPT來進行穿透，主要是指的UDP協(xié)議。TCP協(xié)議也有可能，但是可行性非常小，要求更高，我們此處不作討論，如果感興趣可以到Google上搜索，有些文章對這個問題做了探討性的描述。下面我們來看看利用UDP協(xié)議來穿透NAPT的原理是什么:
圖三: NAPT 是如何將私有IP地址的UDP數(shù)據(jù)包與公網(wǎng)主機進行透明傳輸?shù)摹?
UDP協(xié)議包經(jīng)NAPT透明傳輸?shù)恼f明:
NAPT為每一個Session分配一個NAPT自己的端口號，依據(jù)此端口號來判斷將收到的公網(wǎng)IP主機返回的TCP/IP數(shù)據(jù)包轉(zhuǎn)發(fā)給那臺內(nèi)網(wǎng)IP地址的計算機。在這里Session是虛擬的，UDP通訊并不需要建立連接，但是對于NAPT而言，的確要有一個Session的概念存在。NAPT對于UDP協(xié)議 包的透明傳輸面臨的一個重要的問題就是如何處理這個虛擬的Session。我們都知道TCP連接的Session以SYN包開始，以FIN包結(jié)束，NAPT可以很容易的獲取到TCP Session的生命周期，并進行處理。但是對于UDP而言，就麻煩了，NAPT并不知道轉(zhuǎn)發(fā)出去的UDP協(xié)議包是否到達了目的主機，也沒有辦法知道。而且鑒于UDP協(xié)議的特點，可靠很差，因此NAPT必須強制維持Session的存在，以便等待將外部送回來的數(shù)據(jù)并轉(zhuǎn)發(fā)給曾經(jīng)發(fā)起請求的內(nèi)網(wǎng)IP地址的計算機。NAPT具體如何處理UDP Session的超時呢？不同的廠商提供的設(shè)備對于NAPT的實現(xiàn)不近相同，也許幾分鐘，也許幾個小時，些NAPT的實現(xiàn)還會根據(jù)設(shè)備的忙碌狀態(tài)進行智能計算超時時間的長短。
圖四: NAPT 將內(nèi)部發(fā)出的UDP協(xié)議包的源地址和源端口改變傳輸給公網(wǎng)IP主機。
圖五: NAPT 將收到的公網(wǎng)IP主機返回的UDP協(xié)議包的目的地址和目的端口改變傳輸給內(nèi)網(wǎng)IP計算機現(xiàn)在我們大概明白了NAPT如何實現(xiàn)內(nèi)網(wǎng)計算機和外網(wǎng)主機間的透明通訊。現(xiàn)在來看一下我們最關(guān)心的問題，就是NAPT是依據(jù)什么策略來判斷是否要為一個請求發(fā)出的UDP數(shù)據(jù)包建立Session的呢？主要有一下幾個策略:
A. 源地址(內(nèi)網(wǎng)IP地址)不同，忽略其它因素, 在NAPT上肯定對應(yīng)不同的Session B. 源地址(內(nèi)網(wǎng)IP地址)相同，源端口不同，忽略其它的因素，則在NAPT上也肯定對應(yīng)不同的Session C. 源地址(內(nèi)網(wǎng)IP地址)相同，源端口相同，目的地址(公網(wǎng)IP地址)相同，目的端口不同，則在NAPT上肯定對應(yīng)同一個Session D. 源地址(內(nèi)網(wǎng)IP地址)相同，源端口相同，目的地址(公網(wǎng)IP地址)不同，忽略目的端口，則在NAPT上是如何處理Session的呢？
D的情況正式我們關(guān)心和要討論的問題。依據(jù)目的地址(公網(wǎng)IP地址)對于Session的建立的決定方式我們將NAPT設(shè)備劃分為兩大類:
Symmetric NAPT: 對于到同一個IP地址，任意端口的連接分配使用同一個Session; 對于到不同的IP地址, 任意端口的連接使用不同的Session. 我們稱此種NAPT為 Symmetric NAPT. 也就是只要本地綁定的UDP端口相同， 發(fā)出的目的IP地址不同，則會建立不同的Session.
圖六: Symmetric 的英文意思是對稱。多個端口對應(yīng)多個主機，平行的，對稱的!
Cone NAPT: 對于到同一個IP地址，任意端口的連接分配使用同一個Session; 對于到不同的IP地址，任意端口的連接也使用同一個Session. 我們稱此種NAPT為 Cone NAPT. 也就是只要本地綁定的UDP端口相同， 發(fā)出的目的地址不管是否相同， 都使用同一個Session.
圖七: Cone 的英文意思是錐。一個端口對應(yīng)多個主機，是不是像個錐子?
現(xiàn)在絕大多數(shù)的NAPT屬于后者，即Cone NAT。本人在測試的過程中，只好使用了一臺日本的Symmetric NAT。還好不是自己的買的，我從不買日貨, 希望看這篇文章的朋友也自覺的不要購買日本的東西。Win9x/2K/XP/2003系統(tǒng)自帶的NAPT也是屬于 Cone NAT的。這是值的慶幸的，因為我們要做的UDP穿透只能在Cone NAT間進行，只要有一臺不是Cone NAT，對不起，UDP穿透沒有希望了，服務(wù)器轉(zhuǎn)發(fā)吧。后面會做詳細分析!
下面我們再來分析一下NAPT 工作時的一些數(shù)據(jù)結(jié)構(gòu)，在這里我們將真正說明UDP可以穿透Cone NAT的依據(jù)。這里描述的數(shù)據(jù)結(jié)構(gòu)只是為了說明原理，不具有實際參考價值，真正感興趣可以閱讀Linux的中關(guān)于NAT實現(xiàn)部分的源碼。真正的NAT實現(xiàn)也沒有利用數(shù)據(jù)庫的，呵呵，為了速度！
Symmetric NAPT 工作時的端口映射數(shù)據(jù)結(jié)構(gòu)如下:
內(nèi)網(wǎng)信息表:
[NAPT 分配端口] [ 內(nèi)網(wǎng)IP地址 ] [ 內(nèi)網(wǎng)端口 ] [ 外網(wǎng)IP地址 ] [ SessionTime 開始時間 ]
PRIMARY KEY( [NAPT 分配端口] ) -> 表示依據(jù)[NAPT 分配端口]建立主鍵，必須唯一且建立索引，加快查找. UNIQUE( [ 內(nèi)網(wǎng)IP地址 ], [ 內(nèi)網(wǎng)端口 ] ) -> 表示這兩個字段聯(lián)合起來不能重復(fù). UNIQUE( [ 內(nèi)網(wǎng)IP地址 ], [ 內(nèi)網(wǎng)端口 ], [ 外網(wǎng)IP地址 ] ) -> 表示這三個字段聯(lián)合起來不能重復(fù).
映射表:
[NAPT 分配端口] [ 外網(wǎng)端口 ]
UNIQUE( [NAPT 分配端口], [ 外網(wǎng)端口 ] ) -> 表示這兩個字段聯(lián)合起來不能重復(fù).
Cone NAPT 工作時的端口映射數(shù)據(jù)結(jié)構(gòu)如下:
內(nèi)網(wǎng)信息表:
[NAPT 分配端口] [ 內(nèi)網(wǎng)IP地址 ] [ 內(nèi)網(wǎng)端口 ] [ SessionTime 開始時間 ]
PRIMARY KEY( [NAPT 分配端口] ) -> 表示依據(jù)[NAPT 分配端口]建立主鍵，必須唯一且建立索引，加快查找. UNIQUE( [ 內(nèi)網(wǎng)IP地址 ], [ 內(nèi)網(wǎng)端口 ] ) -> 表示這兩個字段聯(lián)合起來不能重復(fù).
外網(wǎng)信息表:
[ wid 主鍵標識 ] [ 外網(wǎng)IP地址 ] [ 外網(wǎng)端口 ]
PRIMARY KEY( [ wid 主鍵標識 ] ) -> 表示依據(jù)[ wid 主鍵標識 ]建立主鍵，必須唯一且建立索引，加快查找. UNIQUE( [ 外網(wǎng)IP地址 ], [ 外網(wǎng)端口 ] ) -> 表示這兩個字段聯(lián)合起來不能重復(fù).
映射表: 實現(xiàn)一對多，的
[NAPT 分配端口] [ wid 主鍵標識 ]
UNIQUE( [NAPT 分配端口], [ wid 主鍵標識 ] ) -> 表示這兩個字段聯(lián)合起來不能重復(fù). UNIQUE( [ wid 主鍵標識 ] ) -> 標識此字段不能重復(fù).
看完了上面的數(shù)據(jù)結(jié)構(gòu)是更明白了還是更暈了？ 呵呵! 多想一會兒就會明白了。通過NAT,內(nèi)網(wǎng)計算機計算機向外連結(jié)是很容易的，NAPT會自動處理，我們的應(yīng)用程序根本不必關(guān)心它是如何處理的。那么外部的計算機想訪問內(nèi)網(wǎng)中的計算機如何實現(xiàn)呢？我們來看一下下面的流程：
c 是一臺在NAPT后面的內(nèi)網(wǎng)計算機，s是一臺有外網(wǎng)IP地址的計算機。c 主動向 s 發(fā)起連接請求，NAPT依據(jù)上面描述的規(guī)則在自己的數(shù)據(jù)結(jié)構(gòu)中記錄下來，建立一個Session. 然后 c 和 s 之間就可以實現(xiàn)雙向的透明的數(shù)據(jù)傳輸了。如下面所示:
c[192.168.0.6:1827] <-> [priv ip:
192.168.0.1]NAPT[pub ip: 61.51.99.86:9881] <-> s[61.51.76.102:8098]
由此可見，一臺外網(wǎng)IP地址的計算機想和NAPT后面的內(nèi)網(wǎng)計算機通訊的條件就是要求NAPT后面的內(nèi)網(wǎng)計算機主動向外網(wǎng)IP地址的計算機發(fā)起一個UDP數(shù)據(jù)包。外網(wǎng)IP地址的計算機利用收到的UDP數(shù)據(jù)包獲取到NAPT的外網(wǎng)IP地址和映射的端口，以后就可以和內(nèi)網(wǎng)IP的計算機透明的進行通訊了。
現(xiàn)在我們再來分析一下我們最關(guān)心的兩個NAPT后面的內(nèi)網(wǎng)計算機如何實現(xiàn)直接通訊呢? 兩者都無法主動發(fā)出連接請求，誰也不知道對方的NAPT的公網(wǎng)IP地址和NAPT上面映射的端口號。所以我們要靠一個公網(wǎng)IP地址的服務(wù)器幫助兩者來建立連接。當兩個NAPT后面的內(nèi)網(wǎng)計算機分別連接了公網(wǎng)IP地址的服務(wù)器后，服務(wù)器可以從收到的UDP數(shù)據(jù)包中獲取到這兩個NAPT設(shè)備的公網(wǎng)IP地址和這兩個連接建立的Session的映射端口。兩個內(nèi)網(wǎng)計算機可以從服務(wù)器上獲取到對方的NAPT設(shè)備公網(wǎng)IP地址和映射的端口了。
我們假設(shè)兩個內(nèi)網(wǎng)計算機分別為A和B，對應(yīng)的NAPT分別為AN和 BN， 如果A在獲取到B對應(yīng)的BN的IP地址和映射的端口后，迫不急待的向這個IP 地址和映射的端口發(fā)送了個UDP數(shù)據(jù)包，會有什么情況發(fā)生呢？依據(jù)上面的原理和數(shù)據(jù)結(jié)構(gòu)我們會知道，AN會在自己的數(shù)據(jù)結(jié)構(gòu)中生成一條記錄，標識一個新Session的存在。BN在收到數(shù)據(jù)包后，從自己的數(shù)據(jù)結(jié)構(gòu)中查詢，沒有找到相關(guān)記錄，因此將包丟棄。B是個慢性子，此時才慢吞吞的向著AN的IP地址和映射的端口發(fā)送了一個UDP數(shù)據(jù)包，結(jié)果如何呢？當然是我們期望的結(jié)構(gòu)了，AN在收到數(shù)據(jù)包后，從自己的數(shù)據(jù)結(jié)構(gòu)中查找到了記錄，所以將數(shù)據(jù)包進行處理發(fā)送給了A。A 再次向B發(fā)送數(shù)據(jù)包時，一切都時暢通無阻了。OK, 大工告成！且慢，這時對于Cone NAPT而言，對于Symmetric NAPT呢？呵呵，自己分析一下吧...
NAPT(The IP Network Address/Port Translator) 進行UDP穿透的具體情況分析!
首先明確的將NAPT設(shè)備按照上面的說明分為: Symmetric NAPT 和 Cone NAPT, Cone NAPT 是我們需要的。Win9x/2K/XP/2003 自帶的NAPT也為Cone NAPT。
第一種情況, 雙方都是Symmetric NAPT:
此情況應(yīng)給不存在什么問題，肯定是不支持UDP穿透。
第二種情況, 雙方都是Cone NAPT:
此情況是我們需要的，可以進行UDP穿透。
第三種情況, 一個是Symmetric NAPT, 一個是Cone NAPT:
此情況比較復(fù)雜，但我們按照上面的描述和數(shù)據(jù)機構(gòu)進行一下分析也很容易就會明白了, 分析如下,
假設(shè): A -> Symmetric NAT, B -> Cone NAT
1. A 想連接 B, A 從服務(wù)器那兒獲取到 B 的NAT地址和映射端口, A 通知服務(wù)器，服務(wù)器告知 B A的NAT地址和映射端口, B 向 A 發(fā)起連接，A 肯定無法接收到。此時 A 向 B 發(fā)起連接， A 對應(yīng)的NAT建立了一個新的Session，分配了一個新的映射端口， B 的 NAT 接收到UDP包后，在自己的映射表中查詢，無法找到映射項，因此將包丟棄了。
2. B 想連接 A, B 從服務(wù)器那兒獲取到 A 的NAT地址和映射端口, B 通知服務(wù)器, 服務(wù)器告知 A B的NAT地址和映射端口,A 向 B 發(fā)起連接, A 對應(yīng)的NAT建立了一個新的Session，分配了一個新的映射端口B肯定無法接收到。此時 B 向 A 發(fā)起連接, 由于 B 無法獲取 A 建立的新的Session的映射端口，仍是使用服務(wù)器上獲取的映射端口進行連接， 因此 A 的NAT在接收到UDP包后，在自己的映射表中查詢，無法找到映射項, 因此將包丟棄了。
根據(jù)以上分析，只有當連接的兩端的NAT都為Cone NAT的情況下，才能進行UDP的內(nèi)網(wǎng)穿透互聯(lián)。
NAPT(The IP Network Address/Port Translator) 進行UDP穿透如何進行現(xiàn)實的驗證和分析!
需要的網(wǎng)絡(luò)結(jié)構(gòu)如下:
三個NAT后面的內(nèi)網(wǎng)機器，兩個外網(wǎng)服務(wù)器。其中兩臺Cone NAPT，一臺 Symmetric NAPT。
驗證方法:
可以使用本程序提供的源碼，編譯，然后分別運行服務(wù)器程序和客戶端。修改過后的源碼增加了客戶端之間直接通過IP地址和端口發(fā)送消息的命令，利用此命令，你可以手動的驗證NAPT的穿透情況。為了方便操作，推薦你使用一個遠程登陸軟件，可以直接在一臺機器上操作所有的相關(guān)的計算機，這樣很方便，一個人就可以完成所有的工作了。呵呵，本人就是這么完成的。歡迎有興趣和經(jīng)驗的朋友來信批評指正，共同進步。