源碼下載: http://www.ppcn.net/upload/2005_08/05080112299104.rar 參考： http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

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

文章說明:

關于UDP穿透NAT的中文資料在網絡上是很少的，僅有<<P2P之UDP穿透NAT的原理與實現(shootingstars)>>這篇文章有實際的參考價值。本人近兩年來也一直從事P2P方面的開發工作，比較有代表性的是個人開發的BitTorrent下載軟件 - FlashBT(變態快車). 對P2P下載或者P2P的開發感興趣的朋友可以訪問軟件的官方主頁: http://www.hwysoft.com/chs/ 下載看看，說不定有收獲。寫這篇文章的主要目的是懶的再每次單獨回答一些網友的提問, 一次性寫下來, 即節省了自己的時間，也方便了對于P2P的UDP穿透感興趣的網友閱讀和理解。對此有興趣和經驗的朋友可以給我發郵件或者訪問我的個人Blog留言: http://hwycheng.blogchina.com. 您可以自由轉載此篇文章，但是請保留此說明。

再次感謝shootingstars網友的早期貢獻. 表示謝意。

NAT(The IP Network Address Translator) 的概念和意義是什么?

NAT, 中文翻譯為網絡地址轉換。具體的詳細信息可以訪問RFC 1631 - http://www.faqs.org/rfcs/rfc1631.html, 這是對于NAT的定義和解釋的最權威的描述。網絡術語都是很抽象和艱澀的，除非是專業人士，否則很難從字面中來準確理解NAT的含義。

要想完全明白NAT 的作用，我們必須理解IP地址的兩大分類，一類是私有IP地址，在這里我們稱作內網IP地址。一類是非私有的IP地址，在這里我們稱作公網IP地址。關于IP地址的概念和作用的介紹參見我的另一篇文章: http://hwycheng.blogchina.com/2402121.html

內網IP地址: 是指使用A/B/C類中的私有地址, 分配的IP地址在全球不懼有唯一性，也因此無法被其它外網主機直接訪問。公網IP地址: 是指具有全球唯一的IP地址，能夠直接被其它主機訪問的。

NAT 最初的目的是為使用內網IP地址的計算機提供通過少數幾臺具有公網的IP地址的計算機訪問外部網絡的功能。NAT 負責將某些內網IP地址的計算機向外部網絡發出的IP數據包的源IP地址轉換為NAT自己的公網的IP地址，目的IP地址不變, 并將IP數據包轉發給路由器，最終到達外部的計算機。同時負責將外部的計算機返回的IP數據包的目的IP地址轉換為內網的IP地址，源IP地址不變，并最終送達到內網中的計算機。

圖一: NAT 實現了私有IP的計算機分享幾個公網IP地址訪問Internet的功能。

隨著網絡的普及，IPv4的局限性暴露出來。公網IP地址成為一種稀缺的資源，此時NAT 的功能局限也暴露出來，同一個公網的IP地址，某個時間只能由一臺私有IP地址的計算機使用。于是NAPT(The IP Network Address/Port Translator)應運而生，NAPT實現了多臺私有IP地址的計算機可以同時通過一個公網IP地址來訪問Internet的功能。這在很大程度上暫時緩解了IPv4地址資源的緊張。

NAPT 負責將某些內網IP地址的計算機向外部網絡發出的TCP/UDP數據包的源IP地址轉換為NAPT自己的公網的IP地址，源端口轉為NAPT自己的一個端口。目的IP地址和端口不變, 并將IP數據包發給路由器，最終到達外部的計算機。同時負責將外部的計算機返回的IP數據包的目的IP地址轉換內網的IP地址，目的端口轉為內網計算機的端口，源IP地址和源端口不變，并最終送達到內網中的計算機。

圖二: NAPT 實現了私有IP的計算機分享一個公網IP地址訪問Internet的功能。

在我們的工作和生活中, NAPT的作用隨處可見，絕大部分公司的網絡架構，都是通過1至N臺支持NAPT的路由器來實現公司的所有計算機連接外部的Internet網絡的。包括本人在寫這篇文章的時候，也是在家中使用一臺IBM筆記本通過一臺寬帶連接的臺式機來訪問Internet的。我們本篇文章主要討論的NAPT的問題。

NAPT(The IP Network Address/Port Translator) 為何阻礙了P2P軟件的應用?

通過NAPT 上網的特點決定了只能由NAPT內的計算機主動向NAPT外部的主機發起連接，外部的主機想直接和NAPT內的計算機直接建立連接是不被允許的。IM(即時通訊)而言，這意味著由于NAPT內的計算機和NAPT外的計算機只能通過服務器中轉數據來進行通訊。對于P2P方式的下載程序而言，意味著NAPT內的計算機不能接收到NAPT外部的連接，導致連接數用過少，下載速度很難上去。因此P2P軟件必須要解決的一個問題就是要能夠在一定的程度上解決NAPT內的計算機不能被外部連接的問題。

NAT(The IP Network Address Translator) 進行UDP穿透的原理是什么?

TCP/IP傳輸時主要用到TCP和UDP協議。TCP協議是可靠的，面向連接的傳輸協議。UDP是不可靠的，無連接的協議。根據TCP和UDP協議的實現原理，對于NAPT來進行穿透，主要是指的UDP協議。TCP協議也有可能，但是可行性非常小，要求更高，我們此處不作討論，如果感興趣可以到Google上搜索，有些文章對這個問題做了探討性的描述。下面我們來看看利用UDP協議來穿透NAPT的原理是什么:

圖三: NAPT 是如何將私有IP地址的UDP數據包與公網主機進行透明傳輸的。

UDP協議包經NAPT透明傳輸的說明:

NAPT為每一個Session分配一個NAPT自己的端口號，依據此端口號來判斷將收到的公網IP主機返回的TCP/IP數據包轉發給那臺內網IP地址的計算機。在這里Session是虛擬的，UDP通訊并不需要建立連接，但是對于NAPT而言，的確要有一個Session的概念存在。NAPT對于UDP協議 包的透明傳輸面臨的一個重要的問題就是如何處理這個虛擬的Session。我們都知道TCP連接的Session以SYN包開始，以FIN包結束，NAPT可以很容易的獲取到TCP Session的生命周期，并進行處理。但是對于UDP而言，就麻煩了，NAPT并不知道轉發出去的UDP協議包是否到達了目的主機，也沒有辦法知道。而且鑒于UDP協議的特點，可靠很差，因此NAPT必須強制維持Session的存在，以便等待將外部送回來的數據并轉發給曾經發起請求的內網IP地址的計算機。NAPT具體如何處理UDP Session的超時呢？不同的廠商提供的設備對于NAPT的實現不近相同，也許幾分鐘，也許幾個小時，些NAPT的實現還會根據設備的忙碌狀態進行智能計算超時時間的長短。

圖四: NAPT 將內部發出的UDP協議包的源地址和源端口改變傳輸給公網IP主機。

圖五: NAPT 將收到的公網IP主機返回的UDP協議包的目的地址和目的端口改變傳輸給內網IP計算機現在我們大概明白了NAPT如何實現內網計算機和外網主機間的透明通訊。現在來看一下我們最關心的問題，就是NAPT是依據什么策略來判斷是否要為一個請求發出的UDP數據包建立Session的呢？主要有一下幾個策略:

A. 源地址(內網IP地址)不同，忽略其它因素, 在NAPT上肯定對應不同的Session B. 源地址(內網IP地址)相同，源端口不同，忽略其它的因素，則在NAPT上也肯定對應不同的Session C. 源地址(內網IP地址)相同，源端口相同，目的地址(公網IP地址)相同，目的端口不同，則在NAPT上肯定對應同一個Session D. 源地址(內網IP地址)相同，源端口相同，目的地址(公網IP地址)不同，忽略目的端口，則在NAPT上是如何處理Session的呢？

D的情況正式我們關心和要討論的問題。依據目的地址(公網IP地址)對于Session的建立的決定方式我們將NAPT設備劃分為兩大類:

Symmetric NAPT: 對于到同一個IP地址，任意端口的連接分配使用同一個Session; 對于到不同的IP地址, 任意端口的連接使用不同的Session. 我們稱此種NAPT為 Symmetric NAPT. 也就是只要本地綁定的UDP端口相同， 發出的目的IP地址不同，則會建立不同的Session.

圖六: Symmetric 的英文意思是對稱。多個端口對應多個主機，平行的，對稱的!

Cone NAPT: 對于到同一個IP地址，任意端口的連接分配使用同一個Session; 對于到不同的IP地址，任意端口的連接也使用同一個Session. 我們稱此種NAPT為 Cone NAPT. 也就是只要本地綁定的UDP端口相同， 發出的目的地址不管是否相同， 都使用同一個Session.

圖七: Cone 的英文意思是錐。一個端口對應多個主機，是不是像個錐子?

現在絕大多數的NAPT屬于后者，即Cone NAT。本人在測試的過程中，只好使用了一臺日本的Symmetric NAT。還好不是自己的買的，我從不買日貨, 希望看這篇文章的朋友也自覺的不要購買日本的東西。Win9x/2K/XP/2003系統自帶的NAPT也是屬于 Cone NAT的。這是值的慶幸的，因為我們要做的UDP穿透只能在Cone NAT間進行，只要有一臺不是Cone NAT，對不起，UDP穿透沒有希望了，服務器轉發吧。后面會做詳細分析!

下面我們再來分析一下NAPT 工作時的一些數據結構，在這里我們將真正說明UDP可以穿透Cone NAT的依據。這里描述的數據結構只是為了說明原理，不具有實際參考價值，真正感興趣可以閱讀Linux的中關于NAT實現部分的源碼。真正的NAT實現也沒有利用數據庫的，呵呵，為了速度！

Symmetric NAPT 工作時的端口映射數據結構如下:

內網信息表:

[NAPT 分配端口] [ 內網IP地址 ] [ 內網端口 ] [ 外網IP地址 ] [ SessionTime 開始時間 ]

PRIMARY KEY( [NAPT 分配端口] ) -> 表示依據[NAPT 分配端口]建立主鍵，必須唯一且建立索引，加快查找. UNIQUE( [ 內網IP地址 ], [ 內網端口 ] ) -> 表示這兩個字段聯合起來不能重復. UNIQUE( [ 內網IP地址 ], [ 內網端口 ], [ 外網IP地址 ] ) -> 表示這三個字段聯合起來不能重復.

映射表:

[NAPT 分配端口] [ 外網端口 ]

UNIQUE( [NAPT 分配端口], [ 外網端口 ] ) -> 表示這兩個字段聯合起來不能重復.

Cone NAPT 工作時的端口映射數據結構如下:

內網信息表:

[NAPT 分配端口] [ 內網IP地址 ] [ 內網端口 ] [ SessionTime 開始時間 ]

PRIMARY KEY( [NAPT 分配端口] ) -> 表示依據[NAPT 分配端口]建立主鍵，必須唯一且建立索引，加快查找. UNIQUE( [ 內網IP地址 ], [ 內網端口 ] ) -> 表示這兩個字段聯合起來不能重復.

外網信息表:

[ wid 主鍵標識 ] [ 外網IP地址 ] [ 外網端口 ]

PRIMARY KEY( [ wid 主鍵標識 ] ) -> 表示依據[ wid 主鍵標識 ]建立主鍵，必須唯一且建立索引，加快查找. UNIQUE( [ 外網IP地址 ], [ 外網端口 ] ) -> 表示這兩個字段聯合起來不能重復.

映射表: 實現一對多，的

[NAPT 分配端口] [ wid 主鍵標識 ]

UNIQUE( [NAPT 分配端口], [ wid 主鍵標識 ] ) -> 表示這兩個字段聯合起來不能重復. UNIQUE( [ wid 主鍵標識 ] ) -> 標識此字段不能重復.

看完了上面的數據結構是更明白了還是更暈了？ 呵呵! 多想一會兒就會明白了。通過NAT,內網計算機計算機向外連結是很容易的，NAPT會自動處理，我們的應用程序根本不必關心它是如何處理的。那么外部的計算機想訪問內網中的計算機如何實現呢？我們來看一下下面的流程：

c 是一臺在NAPT后面的內網計算機，s是一臺有外網IP地址的計算機。c 主動向 s 發起連接請求，NAPT依據上面描述的規則在自己的數據結構中記錄下來，建立一個Session. 然后 c 和 s 之間就可以實現雙向的透明的數據傳輸了。如下面所示:

  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]

由此可見，一臺外網IP地址的計算機想和NAPT后面的內網計算機通訊的條件就是要求NAPT后面的內網計算機主動向外網IP地址的計算機發起一個UDP數據包。外網IP地址的計算機利用收到的UDP數據包獲取到NAPT的外網IP地址和映射的端口，以后就可以和內網IP的計算機透明的進行通訊了。

現在我們再來分析一下我們最關心的兩個NAPT后面的內網計算機如何實現直接通訊呢? 兩者都無法主動發出連接請求，誰也不知道對方的NAPT的公網IP地址和NAPT上面映射的端口號。所以我們要靠一個公網IP地址的服務器幫助兩者來建立連接。當兩個NAPT后面的內網計算機分別連接了公網IP地址的服務器后，服務器可以從收到的UDP數據包中獲取到這兩個NAPT設備的公網IP地址和這兩個連接建立的Session的映射端口。兩個內網計算機可以從服務器上獲取到對方的NAPT設備公網IP地址和映射的端口了。

我們假設兩個內網計算機分別為A和B，對應的NAPT分別為AN和 BN， 如果A在獲取到B對應的BN的IP地址和映射的端口后，迫不急待的向這個IP 地址和映射的端口發送了個UDP數據包，會有什么情況發生呢？依據上面的原理和數據結構我們會知道，AN會在自己的數據結構中生成一條記錄，標識一個新Session的存在。BN在收到數據包后，從自己的數據結構中查詢，沒有找到相關記錄，因此將包丟棄。B是個慢性子，此時才慢吞吞的向著AN的IP地址和映射的端口發送了一個UDP數據包，結果如何呢？當然是我們期望的結構了，AN在收到數據包后，從自己的數據結構中查找到了記錄，所以將數據包進行處理發送給了A。A 再次向B發送數據包時，一切都時暢通無阻了。OK, 大工告成！且慢，這時對于Cone NAPT而言，對于Symmetric NAPT呢？呵呵，自己分析一下吧...

NAPT(The IP Network Address/Port Translator) 進行UDP穿透的具體情況分析!

首先明確的將NAPT設備按照上面的說明分為: Symmetric NAPT 和 Cone NAPT, Cone NAPT 是我們需要的。Win9x/2K/XP/2003 自帶的NAPT也為Cone NAPT。

第一種情況, 雙方都是Symmetric NAPT:

此情況應給不存在什么問題，肯定是不支持UDP穿透。

第二種情況, 雙方都是Cone NAPT:

此情況是我們需要的，可以進行UDP穿透。

第三種情況, 一個是Symmetric NAPT, 一個是Cone NAPT:

此情況比較復雜，但我們按照上面的描述和數據機構進行一下分析也很容易就會明白了, 分析如下,

假設: A -> Symmetric NAT, B -> Cone NAT

1. A 想連接 B, A 從服務器那兒獲取到 B 的NAT地址和映射端口, A 通知服務器，服務器告知 B A的NAT地址和映射端口, B 向 A 發起連接，A 肯定無法接收到。此時 A 向 B 發起連接， A 對應的NAT建立了一個新的Session，分配了一個新的映射端口， B 的 NAT 接收到UDP包后，在自己的映射表中查詢，無法找到映射項，因此將包丟棄了。

2. B 想連接 A, B 從服務器那兒獲取到 A 的NAT地址和映射端口, B 通知服務器, 服務器告知 A B的NAT地址和映射端口,A 向 B 發起連接, A 對應的NAT建立了一個新的Session，分配了一個新的映射端口B肯定無法接收到。此時 B 向 A 發起連接, 由于 B 無法獲取 A 建立的新的Session的映射端口，仍是使用服務器上獲取的映射端口進行連接， 因此 A 的NAT在接收到UDP包后，在自己的映射表中查詢，無法找到映射項, 因此將包丟棄了。

根據以上分析，只有當連接的兩端的NAT都為Cone NAT的情況下，才能進行UDP的內網穿透互聯。

NAPT(The IP Network Address/Port Translator) 進行UDP穿透如何進行現實的驗證和分析!

需要的網絡結構如下:

三個NAT后面的內網機器，兩個外網服務器。其中兩臺Cone NAPT，一臺 Symmetric NAPT。

驗證方法:

可以使用本程序提供的源碼，編譯，然后分別運行服務器程序和客戶端。修改過后的源碼增加了客戶端之間直接通過IP地址和端口發送消息的命令，利用此命令，你可以手動的驗證NAPT的穿透情況。為了方便操作，推薦你使用一個遠程登陸軟件，可以直接在一臺機器上操作所有的相關的計算機，這樣很方便，一個人就可以完成所有的工作了。呵呵，本人就是這么完成的。歡迎有興趣和經驗的朋友來信批評指正，共同進步。