P2P之UDP穿透NAT的原理與實現 - 增強篇
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
關鍵詞: P2P UDP NAT 原理 穿透 Traveral Symmetric Cone 文章說明: 關于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地址在全球不懼有唯一性,也因此無法被其它外網主機直接訪問。 NAT 最初的目的是為使用內網IP地址的計算機提供通過少數幾臺具有公網的IP地址的計算機訪問外部網絡的功能。NAT 負責將某些內網IP地址的計算機向外部網絡發出的IP數據包的源IP地址轉換為NAT自己的公網的IP地址,目的IP地址不變, 并將IP數據包轉發給路由器,最終到達外部的計算機。同時負責將外部的計算機返回的IP數據包的目的IP地址轉換為內網的IP地址,源IP地址不變,并最終送達到內網中的計算機。 NAPT 負責將某些內網IP地址的計算機向外部網絡發出的TCP/UDP數據包的源IP地址轉換為NAPT自己的公網的IP地址,源端口轉為NAPT自己的一個端口。目的IP地址和端口不變, 并將IP數據包發給路由器,最終到達外部的計算機。同時負責將外部的計算機返回的IP數據包的目的IP地址轉換內網的IP地址,目的端口轉為內網計算機的端口,源IP地址和源端口不變,并最終送達到內網中的計算機。
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的原理是什么: ---------------------- ---------------------- 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的實現還會根據設備的忙碌狀態進行智能計算超時時間的長短。 [192.168.0.6:1827] A. 源地址(內網IP地址)不同,忽略其它因素, 在NAPT上肯定對應不同的Session D的情況正式我們關心和要討論的問題。依據目的地址(公網IP地址)對于Session的建立的決定方式我們將NAPT設備劃分為兩大類: Symmetric NAPT: [202.223.98.78:9696] [202.223.98.78:9696] [202.223.98.78:9696] [202.223.98.78:9696] [202.223.98.78:9696] [202.223.98.78:9696] ^ ^ ^ 現在絕大多數的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 分配端口]建立主鍵,必須唯一且建立索引,加快查找. 映射表: [NAPT 分配端口] [ 外網端口 ] UNIQUE( [NAPT 分配端口], [ 外網端口 ] ) -> 表示這兩個字段聯合起來不能重復. Cone NAPT 工作時的端口映射數據結構如下: 內網信息表: [NAPT 分配端口] [ 內網IP地址 ] [ 內網端口 ] [ SessionTime 開始時間 ] PRIMARY KEY( [NAPT 分配端口] ) -> 表示依據[NAPT 分配端口]建立主鍵,必須唯一且建立索引,加快查找. 外網信息表: [ wid 主鍵標識 ] [ 外網IP地址 ] [ 外網端口 ] PRIMARY KEY( [ wid 主鍵標識 ] ) -> 表示依據[ wid 主鍵標識 ]建立主鍵,必須唯一且建立索引,加快查找. 映射表: 實現一對多,的 [NAPT 分配端口] [ wid 主鍵標識 ] UNIQUE( [NAPT 分配端口], [ 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的計算機透明的進行通訊了。 我們假設兩個內網計算機分別為A和B,對應的NAPT分別為AN和BN, 如果A在獲取到B對應的BN的IP地址和映射的端口后,迫不急待的向這個IP 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的內網穿透互聯。
需要的網絡結構如下: 三個NAT后面的內網機器,兩個外網服務器。其中兩臺Cone NAPT,一臺 Symmetric NAPT。 驗證方法: 可以使用本程序提供的源碼,編譯,然后分別運行服務器程序和客戶端。修改過后的源碼增加了客戶端之間直接通過IP地址和端口發送消息的命令,利用此命令,你可以手動的驗證NAPT的穿透情況。為了方便操作,推薦你使用一個遠程登陸軟件,可以直接在一臺機器上操作所有的相關的計算機,這樣很方便,一個人就可以完成所有的工作了。呵呵,本人就是這么完成的。歡迎有興趣和經驗的朋友來信批評指正,共同進步。 該文章在 2014/2/7 12:18:40 編輯過 |
關鍵字查詢
相關文章
正在查詢... |