通過middlebox實施P2P通訊_第1頁
通過middlebox實施P2P通訊_第2頁
通過middlebox實施P2P通訊_第3頁
通過middlebox實施P2P通訊_第4頁
通過middlebox實施P2P通訊_第5頁
已閱讀5頁,還剩8頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、.通過middlebox實施P2P通訊1. 介紹今天的Internet的middleboxes已經(jīng)普遍存在, 比如象網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT),主要是因為IPv4的地址空間消耗危機中產(chǎn)生的一個解決方案。然而,由這些middleboxes建立的不對稱尋址和連接,已經(jīng)成為點對點 (P2P)應(yīng)用和協(xié)議中獨特的問題, 這些應(yīng)用和協(xié)議包括例如網(wǎng)絡(luò)電話和多人在線游戲。這些話題甚至可能在使用 IPv6 協(xié)議后繼續(xù)存在, 比如說在 NAT 常被當(dāng)作兼容 IPv4 機制NAT-PT的地方,還有當(dāng)NAT 不再需要之后,防火墻將會依然存在(這些問題)。當(dāng)前發(fā)展的middleboxes最初計劃用在C/S結(jié)構(gòu)中,即在那些相

2、關(guān)的匿名客戶端主動去連接有著固定IP地址和DNS域名的可連接主機。大多數(shù)的middleboxes實現(xiàn)一個不對稱的溝通模型,即那些私有的內(nèi)部網(wǎng)絡(luò)上的主機可以和公網(wǎng)上的主機連接通訊,但是公網(wǎng)上的外部主機不能夠和內(nèi)網(wǎng)上的主機通訊除了被 middleboxs 的管理者明確地配置之外。 在 NAPT 的通常情形中,在內(nèi)部網(wǎng)絡(luò)上的一位客戶機在公網(wǎng)上并沒有一個唯一獨特的IP地址,但是可以在同一私網(wǎng)上的其他客戶機一樣,分享一個公網(wǎng)IP地址,并有NAPT管理。 這些在一臺middlebox后的不知道名稱和不易訪問的內(nèi)部主機對客戶端軟件比如網(wǎng)頁瀏覽器并不是一個問題,它們之需要向外連接。而且這種不易訪問的特性有時候

3、被視為對保護隱私有利。 但是,在點對點的應(yīng)用中,英特網(wǎng)上的主機通常會考慮要和客戶建立直接和彼此訪問的通話連接。呼叫者和被叫者可能會在不同的middleboxes 后面,兩者都可能沒有任何的固定IP地址或者其他的公網(wǎng)存在表現(xiàn)。舉例來說,一個通常的在線游戲架構(gòu),是讓參加游戲的主人連接到一個大家都知道的服務(wù)器上設(shè)定一些初識值,以及連接后的使用目的。然后,為了在游戲期間有更加快速和有效的游戲速度,需要建立彼此直接的連接。同樣地,一個可共享的文件可能可以讓一個大家都知道的資源搜索引擎發(fā)現(xiàn)或者查找到,但如果需要文件數(shù)據(jù)傳輸,就需要和那臺共享文件的主機建立直接的連接了。在點對點連接時,middlebox就生

4、成了一個問題。因為在middlebox后面的那些需要用TCP或者UDP和其他機器連接的主機通常沒有固定可用的公網(wǎng)端口可以進行連接。 RFC 3235 NAT-APPL簡短地說明了這個問題,但是沒有提供任何的通常解決方案。 在這一份文檔中,我們就 P2P/ middlebox 問題有2點說明。 首先,我們總結(jié)那些在middleboxes存在時P2P應(yīng)用程序可以工作的已知方法。其次,我們提供基于這些實踐的一套應(yīng)用程序設(shè)計指導(dǎo)方針使P2P在middleboxes下應(yīng)用的更健康。更進一步,我們提供的設(shè)計指導(dǎo)方針可以讓將來的 middleboxes 更有效率的支持支援 P2P 應(yīng)用。 我們的重點是要能夠

5、穿透 middleboxes,以提供更廣闊和更直接的P2P 應(yīng)用。 2. 術(shù)語在本章中我們首先簡要描述一下一些middlebox術(shù)語,我們這里的重點是兩種常導(dǎo)致P2P應(yīng)用出現(xiàn)問題的middlebox.防火墻一個防火墻限制私人內(nèi)網(wǎng)和公眾英特網(wǎng)之間的通訊,典型地防火墻就是丟棄那些它認為未經(jīng)許可的數(shù)據(jù)包。在數(shù)據(jù)包穿越一個防火墻時,它檢查但是不修改包里的 IP地址和TCP/ UDP 端口信息。 網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)當(dāng)數(shù)據(jù)包穿過NAT時,NAT不僅檢查同時也修改數(shù)據(jù)的包頭信息,并且允許更多的在NAT后的主機分享少數(shù)公網(wǎng)IP地址(通常只有1個)。NAT通常有2種主要類型:Basic Nat一個Basic

6、 NAT映射一個內(nèi)在的私有IP地址到一個公網(wǎng)IP地址,但當(dāng)數(shù)據(jù)包穿過NAT時,不更換它的TCP/UDP端口號。Basic Nat通常是只用在一些具備公共IP地址池的NAT上,通過它可以地址綁定,即代表一臺內(nèi)部主機。Network Address/Port Translator (NAPT)但是最通常的,當(dāng)數(shù)據(jù)包穿過NAT時,一個NAPT檢查并修改它的TCP/UDP端口,那么就可以允許多臺內(nèi)網(wǎng)主機同時共享一個單獨的公網(wǎng)IP地址了。關(guān)于 NAT 的分類和術(shù)語,NAT-TRAD 和 NAT-TERM中有更多的信息。那些將來分類的NAPT的附加術(shù)語在較近的工作STUN中被定義。當(dāng)一個內(nèi)網(wǎng)的主機經(jīng)過一個

7、NAT和外部進行TCP或者UDP連接的期間,NAPT分配一個公網(wǎng)IP 住址和端口,以便來自外部終端響應(yīng)的數(shù)據(jù)包能被NAPT接收,解釋,并轉(zhuǎn)發(fā)給內(nèi)網(wǎng)的主機。這個結(jié)果是由 NAPT 建立一個(私有IP地址,私有端口)和(公網(wǎng)IP地址,公網(wǎng)端口)之間的端口綁定實現(xiàn)的。在這個期間NAPT將為綁定的端口執(zhí)行地址翻譯。一個關(guān)于P2P應(yīng)用的問題是,當(dāng)一個內(nèi)部主機從一個私有IP,私有端口同時與外網(wǎng)上的多臺不同的主機建立多個連接時,NAT是如何運作的。Cone NAT建立一個端口,把一個(私有IP,私有端口)和(公用IP,公用端口)綁定后,對于以后來自同一私有IP和端口號的應(yīng)用連接,cone NAT將重復(fù)使用這

8、個綁定的端口,只要有一個連接會話,這個綁定端口就會保持激活狀態(tài)。例如,下面圖表中,推想一下客戶端A通過一個cone NAT同時建立2個外部會話,從同樣的內(nèi)部網(wǎng)絡(luò)終端(10.0.0.1:1234)到2個不同的外部服務(wù)器,S1和S2。cone NAT只會分配一個公用的終端,155.99.25.11:62000,都會到兩個會話,并在地址轉(zhuǎn)換期間確??蛻舳硕丝诘囊恢?。Basic NAT和防火墻不修改通過middlebox的數(shù)據(jù)包中的端口號,這些類型的middlebox可以被認為是一種特殊的Cone Nat。Server S1 Server S2 18.181.0.31:1235 138.76.29.7

9、: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 | Clie

10、nt A 10.0.0.1:1234Symmetric NAT對稱的NAT(Symmetric NAT),與Cone NAT有明顯差別,在所有會話期間中不會保持綁定(私有IP,私有端口)和(公共IP,公共端口)的端口不變。相反,它會為每個新對話重新分配一個新的公共端口。舉例來說,設(shè)想客戶A從同樣端口上要發(fā)起兩個外部對話,一個和S1連接,另一個和S2連接。Symmetric NAT可能會為第一個會話分配一個公共的端點 155.99.25.11:62000,而為第二個會話分配一個不同的公共端點155.99.25.11:62001。為了地址轉(zhuǎn)換,NAT可以區(qū)分這兩個會話傳輸?shù)哪康?,因為和這些會話有關(guān)

11、的外部端點(就是S1、S2)是不同的,甚至在通過地址轉(zhuǎn)換時丟失了客戶端的目的標(biāo)示。(即丟了S1、S2的IP地址NAT也知道如何區(qū)分,我是這么理解的,可能有誤。) 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:62001 v | Symmetric NAT 155.9

12、9.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:1234Cone NAT和Symmetric NAT之間的比較與TCP/UDP之間的比較有些類似。(TCP需要綁定,UDP不需要,Cone NAT需要綁定,Symmetric NAT不需要)按照NAT從已知的公共IP,公共端口接收的數(shù)據(jù)限制,Cone NAT可以更進一步的進行分類。這種分類通常都是UDP

13、連接的,因為NAT和防火墻會拒絕任何無條件的TCP連接,除非明確地以別的方式配置。 Full Cone NAT在給一個新的外部會話建立了一個公共/私有的端口綁定后,一個full cone NAT就可以通過這個公共端口從公網(wǎng)上的任何外部端點接收數(shù)據(jù)通訊了。Full cone NAT也常常叫做混合NAT。Restricted Cone NAT當(dāng)網(wǎng)絡(luò)主機發(fā)一個或者幾個數(shù)據(jù)包給外部主機后,一個受限的cone NAT(Restricted Cone NAT)才會接受來自這個外部(源)IP地址的數(shù)據(jù)包。受限的cone NAT有效的運用了防火墻的原理,拒絕沒有要求的數(shù)據(jù),只接收已知道的外部IP地址傳來的數(shù)據(jù)

14、。(偏開原文,大意就是網(wǎng)絡(luò)主機需要發(fā)一個請求給外部IP地址要求要數(shù)據(jù),NAT才會接收這個外部IP地址傳來的數(shù)據(jù),不然不接收。)Port-Restricted Cone NAT一個端口受限的cone NAT(Port-Restricted Cone NAT),也是這樣,只接收那些網(wǎng)絡(luò)主機曾經(jīng)發(fā)給一個外部IP地址和端口相匹配的數(shù)據(jù)。一個Port-Restricted cone NAT可以和對稱 NAT一樣(symmetric NAT),保護內(nèi)部節(jié)點不接收未被請求的數(shù)據(jù)包,但是保持一個私有端口在連接過程中不變。(偏開原文,即不僅請求的IP和外部發(fā)來數(shù)據(jù)的IP是一樣的,PORT也要是一樣,這樣才接收數(shù)

15、據(jù)。對稱NAT也有這個效果,但這種cone NAT保持端口不變,而對稱NAT要變端口號的)。最后,在這篇文檔中我們定義一些新的術(shù)語來給middleboxes中有關(guān)P2P的行為進行分類:P2P-Application在這篇文檔中P2P-Application被當(dāng)做一個應(yīng)用程序,在那些參與P2P連接的并在一個公共的登錄服務(wù)器注冊的終端運行,可以是一個私有端點,也可以是一個公共端點,或者兩者都是,并建立一個初步的會話。P2P-MiddleboxP2P- Middlebox就是允許P2P應(yīng)用程序交換數(shù)據(jù)的的middlebox。P2P-firewall一個P2P-防火墻就是提供防火墻功能的P2P- Mi

16、ddlebox,但不具備地址映射功能。P2P-NATP2P-NAT就是提供NAT功能,也提供防火墻功能的P2P- Middlebox。一臺P2P- Middlebox必須為UDP傳輸至少提供Cone NAT功能,允許應(yīng)用程序使用UDP建立完整的P2P連接。 loopback translation(自環(huán)映射)當(dāng)一臺位于私有域的主機,它的NAT試圖用此主機在公網(wǎng)的映射地址連接其他位于同樣NAT后的其他主機,相當(dāng)于NAT裝置在數(shù)據(jù)包上做了兩次NAT轉(zhuǎn)換。在數(shù)據(jù)報到達目標(biāo)主機之前,源主機的私有端點被轉(zhuǎn)換成NAT分配的公共端點,然后把目標(biāo)主機的公共端點轉(zhuǎn)換成目標(biāo)主機的私有端點。我們在上面提到的地址轉(zhuǎn)換

17、用一臺NAT裝置完成就稱為Loopback translation。3. 用middleboxes進行P2P通訊的技術(shù)這段文章詳細的回顧一下使用現(xiàn)有的middlebox實現(xiàn)P2P通訊的技術(shù),主要從應(yīng)用程序或協(xié)議設(shè)計上來述說。3.1 Relaying(傳輸)最可靠的,但是效率最低的,實現(xiàn)P2P通訊的方法就是在傳輸過程中,把P2P通訊看成向C/S通訊的網(wǎng)絡(luò)一樣。例如,推想2個客戶主機,A和B,各自發(fā)起一個TCP或UDP的連接,連接到一個大家都知道的擁有固定IP地址的服務(wù)器S上??蛻糁鳈C都在各自的私有網(wǎng)絡(luò)中,但是它們各自的middlebox不允許自己的客戶端可以直接和其它主機連接。 Server S

18、 | | +-+-+ | | NAT A NAT B | | | | Client A Client B 不能直接連接,兩個客戶端就使用S服務(wù)器進行消息的傳遞。例如,要發(fā)送一條信息到客戶端B,客戶端A以C/S連接方式簡單的發(fā)送一條信息到S服務(wù)器,然后S服務(wù)器使用已經(jīng)和客戶端B建立的C/S連接發(fā)送這條信息到客戶端B。這種方法的優(yōu)勢在于只要兩個客戶端都連在服務(wù)器上,它就是有效的。它的明顯缺點是它需要了服務(wù)器的處理并占用了帶寬,而且即使服務(wù)器的網(wǎng)絡(luò)狀況良好,也有一定的通訊滯后問題。TRUN協(xié)議TURN定義了這種P2P應(yīng)用的相關(guān)方法。3.2 逆向連接 (Connection reversal)第二種技

19、術(shù)是在只有一個客戶位于middlebox后的條件下運用的。舉例來說, 推想客戶A在 NAT 后面但是客戶 B 有一個全球有效的 IP 地址, 參照下面圖表: Server S 18.181.0.31:1235 | | +-+-+ | | NAT A | 155.99.25.11:62000 | | | | | Client A Client B 10.0.0.1:1234 138.76.29.7:1234客戶A有一個私有IP地址10.0.0.1,并且一個應(yīng)用程序使用TCP端口1234。這個客戶端和服務(wù)器S的公網(wǎng)IP地址18.181.0.31和端口1235建立了一個連接。NAT A為了客戶端A和

20、服務(wù)器S的會話,臨時分配了一個終端地址,其TCP端口62000,它自己的IP地址是155.99.25.11:因此,服務(wù)器S認為客戶端A用的是IP地址155.99.25.11,端口是62000。然而,客戶端B有著自己的固定IP地址,138.76.29.7,并且在它上面的P2P應(yīng)用程序可以在端口1234接收TCP連接?,F(xiàn)在推想客戶端B想要與客戶端A建立一個P2P連接會話。B可能用客戶端A本身的地址,即10.0.0.1:1234,也可能用在服務(wù)器S上得到到的地址,155,99.25.11:62000,去嘗試連接。然而無論在哪一種情況下,連接都會失敗。第一種情況下,指向IP地址10.0.0.1的通訊包

21、會被丟棄,因為10.0.0.1不是一個公網(wǎng)固定IP地址。第二種情況下,來自客戶端B的TCP SYN請求包將會到達NAT A的62000端口,但NAT A將會拒絕這個請求,因為NAT A只允許向外發(fā)送數(shù)據(jù)。在嘗試和客戶端A建立直接連接失敗后,客戶端B會利用服務(wù)器S傳遞一個請求,讓客戶端A去主動連接客戶。客戶端A在通過服務(wù)器S接收到傳遞的請求后,會使用客戶端B的公共IP地址和端口建立一個TCP連接。 因為這個連接是在防火墻內(nèi)部發(fā)起的,所以NAT A允許這個連接建立,而客戶端B也能接收這個連接,因為它并不處于middlebox后面。當(dāng)前實現(xiàn)P2P系統(tǒng)的一種技術(shù),它有一個主要的局限性,就是它只能允許P

22、2P中一方在NAT后面:而兩方都在NAT后面的情況是很常見的,這種方法就會失敗。因為這種逆向連接并不是解決問題的普遍方法,通常不推薦這個方法。應(yīng)用程序可以選擇試一試逆向連接,但當(dāng)向前或逆向都不能建立連接時,應(yīng)用程序應(yīng)該能夠自動的可以選擇另外的連接機制,比如relaying(即3.1說的)。3.3 UDP hole punching第三種技術(shù),也是這篇文章的一個重要點之一,就是被稱為UDP Hole Punching的技術(shù)。當(dāng)兩個需要通訊的主機可能都在middlebox后面的時候,UDP hole punching依賴于cone NAT和普通防火墻的一些特性,允許合適的P2P應(yīng)用程序以punch

23、 holes方式通過middlebox并且建立彼此之間直接的連接。這種技術(shù)在RFC 3027NAT- PORT的5.1節(jié)中簡要的提及,并且在英特網(wǎng)KEGEL非證實的提到,也在最近的一些協(xié)議TEREDO, ICE中用到。正如名字中的所提到的,這種技術(shù)只能用于UDP連接。我們將會考慮兩個特別情況,并且考慮應(yīng)用程序如何完善的處理兩者之間的握手連接。第一種情況下,也是較為普通的情況,兩個在不通的NAT后面的客戶端要求直接的進行P2P連接。第二種情況,兩臺客戶端位于同一個NAT后面,但不能肯定(兩臺客戶端位于同一個NAT后面)。3.3.1 位于不同NAT后面(Peers behind different

24、 NATs)假設(shè)客戶端A和B都有自己的私有IP地址,也都位于不同的NAT后面。P2P應(yīng)用程序在A、B和服務(wù)器S上運行,用的都是UDP端口1234。A和B各自和服務(wù)器S建立UDP通訊連接,使NAT A為A的連接分配一個自己的公共端口62000,而NAT B為B的連接分配的是31000端口。 Server S 18.181.0.31:1234 | | +-+-+ | | NAT A NAT B 155.99.25.11:62000 138.76.29.7:31000 | | | | Client A Client B 10.0.0.1:1234 10.1.1.3:1234現(xiàn)在推想一下,客戶端A想要

25、直接和B建立一個UDP通訊會話。假設(shè)A簡單的發(fā)一個UDP信息包到B的公共地址138.76.29.7:31000,然而NAT B將會丟棄這些進入的數(shù)據(jù)信息(除非它是一個FULL cone NAT),原因是NAT B和S已經(jīng)建立的外部會話,而A發(fā)送的信息中的源地址和端口號是和S不匹配的(可以參照一下上面的內(nèi)容,匹配才能接受)。同樣,假如B發(fā)送一個條UDP數(shù)據(jù)包給A的公網(wǎng)地址,NAT A也會丟棄。但是,假設(shè)A發(fā)出一個UDP數(shù)據(jù)信息給B的公網(wǎng)IP地址,同時也通過服務(wù)器S傳遞一個請求給B,要求B也發(fā)一個UDP信息給A的公網(wǎng)IP地址。A直接向B的公共IP地址(138.76.29.7:31000)發(fā)送的數(shù)據(jù)

26、包會讓NAT A在A的私有地址和B的公網(wǎng)地址之間建立了一個新的連接會話。同時,B到A的公網(wǎng)地址(155.99.25.11:62000)的信息會導(dǎo)致NAT B在B的私有地址和A的公共地址之間建立一個新的連接會話。一旦這種新的UDP連接在兩者之間建立起來,客戶端A和B就不需要服務(wù)器S的介紹就能彼此直接通訊了。UDP hole punching技術(shù)有幾個很有用的特點。一旦在兩個位于middlebox后面的客戶端建立了一個直接的P2P連接,在連接中的任何一方都可以扮演一個介紹人的角色,依次繼續(xù)和另一個客戶端建立連接,減少了最初的服務(wù)器S的負擔(dān)。如果說有STUN的話,假如兩個中的任意一個或兩個都碰巧不在

27、middlebox后面,上述應(yīng)用程序?qū)⑼瑯涌梢越2P通訊通道,應(yīng)用程序不需要嘗試明確middlebox的類型。Hole punching技術(shù)甚至可以自動的運用在多級NAT下面,多重NAT就是那些客戶端需要經(jīng)歷多級地址轉(zhuǎn)換才能進入公網(wǎng)。3.3.2 位于同一NAT后(Peers behind the same NAT)現(xiàn)在考慮兩臺客戶端(但并不確定)都在同一個NAT后面的情況,因此會有私有IP地址空間。客戶端A與服務(wù)器S建立一個UDP會話,NAT會分配一個公共端口62000??蛻舳薆與服務(wù)器S也建立一個簡單的連接,NAT為此分配一個公共端口62001。 Server S 18.181.0.31

28、:1234 | | NAT A-S 155.99.25.11:62000 B-S 155.99.25.11:62001 | +-+-+ | | Client A Client B 10.0.0.1:1234 10.1.1.3:1234假想A和B使用UDP hole punching技術(shù)與服務(wù)器S的建立一個外部的通訊路線做為中間介紹。然后A和B將可以通過服務(wù)器S得到各自公共IP地址和端口號,然后使用這些地址各自向?qū)Ψ桨l(fā)送數(shù)據(jù)。兩個客戶能夠以這種方式彼此通訊,只要NAT不僅僅允許外網(wǎng)上的主機可以和內(nèi)網(wǎng)上的主機進行UDP傳輸會話,也可以允許內(nèi)網(wǎng)上的主機可以和其他內(nèi)網(wǎng)的主機進行UDP會話。我們在loo

29、pback translation中設(shè)計到這種情況,因為來自私有網(wǎng)絡(luò)的數(shù)據(jù)包到達NAT后,會looped back到私有網(wǎng)絡(luò)上就象從公網(wǎng)來的一樣。例如,當(dāng)A向B的公共IP地址發(fā)送一個UDP包,這個包的包頭有一個源IP地址和端口,是10.0.0.1:1234,而目的地址是155.99.25.11.62001。NAT接受到這個包,會把源地址轉(zhuǎn)換(映射)為155.99.25.11:62000(就是A的公網(wǎng)地址),把目的地址轉(zhuǎn)換為10.1.1.3:1234,然后發(fā)給B。即使NAT支持回環(huán)映射,NAT的轉(zhuǎn)換和發(fā)送步驟看上去是多余的,在A和B通訊時似乎為NAT添加了潛在的負擔(dān)。這個問題的解決方法是直接的。

30、當(dāng)A和B一開始在服務(wù)器S上交換地址信息時,它們就可以包含他們自己的IP地址和端口號,并且是可見的,對服務(wù)器S也是可見的??蛻舳烁鶕?jù)它們得到的地址同時開始向?qū)Ψ桨l(fā)數(shù)據(jù)包,并建立成功的通訊。假如這兩個客戶端都在同一NAT后面,數(shù)據(jù)包象通訊一開始就能直接到達,而不需要通過NAT就能建立直接連接。假如這兩個客戶端位于不同的NAT后,到達彼此私有地址的數(shù)據(jù)包會被丟棄,但是客戶端可以通過各自的公共地址來建立連接。重要的是這些數(shù)據(jù)包需要通過一些方法去鑒別,然而,在這種情況下,A發(fā)到B的私有地址的數(shù)據(jù)包完全有可能到達A私網(wǎng)內(nèi)其他無關(guān)的終端,B發(fā)到A的包也是這樣。3.3.3 Peers separated by

31、 multiple NATs(多級NAT)在有多重NAT設(shè)備的拓撲結(jié)構(gòu)中,如果沒有一些拓撲的知識,在兩個客戶端之間建立理想的P2P鏈路是不可能的。看看下面的舉的例子。 Server S 18.181.0.31:1234 | | NAT X A-S 155.99.25.11:62000 B-S 155.99.25.11:62001 | | +-+-+ | | NAT A NAT B 192.168.1.1:30000 192.168.1.2:31000 | | | | Client A Client B 10.0.0.1:1234 10.1.1.3:1234假設(shè)NAT X是由一個英特網(wǎng)服務(wù)提供者

32、(ISP)設(shè)置的一個大型NAT,在一些公網(wǎng)IP地址上擁有許多用戶,NAT A和B是小用戶群的NAT網(wǎng)關(guān),由ISP的用戶自己獨自配置,有各自的私有網(wǎng)絡(luò)和用戶群,使用的是ISP提供的IP地址。只有SERVER S和NAT X有自己全球固定的IP地址,而NAT A和B用的公共IP地址實際上是ISP地址域中私有地址,而客戶端A和B的地址對NAT A和B來說也是私有的地址。每當(dāng)客戶端需要和服務(wù)器S建立一個外部的連接,都會導(dǎo)致NAT A和B和客戶端建立一個單獨的公共/私有連接,然后讓NAT X為每個連接會話建立一個公共/私有連接?,F(xiàn)在推想客戶A和B嘗試建立一個直接的P2P UDP連接。對客戶端A來說,最佳

33、的方法是發(fā)送一個數(shù)據(jù)信息到客戶端B在NAT B上,屬于ISP的地址域的公共IP地址192.168.1.2:31000,對客戶端B來說就是發(fā)信息到A在NAT A的公共IP地址192.168.1.1:30000(原文是NAT B,是不是筆誤,還是我理解有問題?)。不幸的是,A和B并沒有知道這些地址的方法,因為服務(wù)器S只能看到客戶端全局的公共IP地址,就是155.99.25.11:62000和155.99.25.11:62001。甚至當(dāng)A和B有某些方法可以得到這些地址,但他們依然不能保證這些地址是有用的,因為這些由ISP的私有地址域分配的地址可能與客戶自己分配的私有地址由沖突??蛻舳艘虼藳]有選擇只能

34、使用由服務(wù)器S知道的公共IP地址來通訊,并且依賴NAT X來提供loopback translation。3.3.4 Consistent prot binddings(保持端口綁定)hole punching 技術(shù)有一個需要注意的地方:它只能工作在兩臺NAT都是cone NAT(或沒有NAT 防火墻)的情況下,只要UDP端口還在使用,它就需要保持一個固定的端口把一個給定(私有IP,私有UDP端口)和一個(公共IP,公共UDP端口)綁定。象對稱NAT一樣,為每個新的連接會話分配一個新的公共端口,對一個UDP應(yīng)用程序來說,為了和不同的外部通訊重用一個已經(jīng)存在的地址轉(zhuǎn)換是不可以的。(這邊稍微有點糊

35、涂,再多看看。) 既然cone NAT運用是相當(dāng)普遍的,UDP hole punching技術(shù)應(yīng)用的也相當(dāng)廣泛,但是還有一小部分是對等NAT配置,因此不能支持這種技術(shù)。3.4 UDP port number prediction有關(guān)UDP hole punching技術(shù)在上面已經(jīng)被討論過,它可以允許在一些對等NAT存在的地方也能建立P2P UDP連接會話。這種方法有時被稱為N+1技術(shù) BIDIR 并且由TakedaSYM-STUN詳細介紹。這種方法分析NAT的工作方式并且試圖預(yù)測它為將來的連接會話分配的公共端口。再次考慮那兩個客戶的狀態(tài),A和B,在各自分開的NAT后面,已經(jīng)與一臺擁有永久地址的

36、服務(wù)器S建立了UDP連接。 Server S 18.181.0.31:1234 | | +-+-+ | | Symmetric NAT A Symmetric NAT B A-S 155.99.25.11:62000 B-S 138.76.29.7:31000 | | | | Client A Client B 10.0.0.1:1234 10.1.1.3:1234NAT A分配一個屬于自己的UDP端口62000以在A和S之間建立通訊連接,而NAT B分配一個31000端口用于在B和S之間建立連接。通過與服務(wù)器的通訊,A和B可以從服務(wù)器S上得到對方的公共IP地址和端口號。客戶端A現(xiàn)在發(fā)送一個U

37、DP數(shù)據(jù)包到地址138.76.29.7,端口31001(注意端口數(shù)目的增加),而客戶端B同時發(fā)送一個數(shù)據(jù)包到地址的155,99.25.11,端口62001上。如果NAT A和B依次為新的連接分配端口,如果從A-S和B-S連接建立后沒過多少時間,那在A和B之間的一個雙向通訊通道就可以工作起來。A到B的數(shù)據(jù)包讓NAT A建立一個新的連接,NAT A(所期望的)分配一個公共端口62001,因為之前A和S的連接會話用的62000端口,接下來就是62001。同樣的,B到A的數(shù)據(jù)包將讓NAT B打開一個新連接,并將(也是所期望的)分配一個端口31001。如果客戶端可以正確的預(yù)測到NAT為新的連接分配的端口

38、,一條雙向的UDP通訊通道就會象如下圖所示一樣建立起來。 Server S 18.181.0.31:1234 | | +-+-+ | | NAT A NAT B A-S 155.99.25.11:62000 B-S 138.76.29.7:31000 A-B 155.99.25.11:62001 B-A 138.76.29.7:31001 | | | | Client A Client B 10.0.0.1:1234 10.1.1.3:1234顯而易見有很多情況都能導(dǎo)致這種方法失敗。假如任意一個預(yù)測的端口碰巧已經(jīng)被其他無關(guān)的連接占用,NAT將會錯過正確的端口,連接嘗試也將失敗。假如任意一個NA

39、T有時或者總是選擇非連續(xù)的端口號,這個方法也將失敗。假如在A(B)建立了它和S的連接之后,但在發(fā)送第一個數(shù)據(jù)包到B(A)之前,一個不同的客戶端在NAT(也或者B)打開一個新的外部連接到任何外部主機,無關(guān)的客戶端會不注意的偷了(A TO B或者B TO A)所要求的端口。因此在任一NAT都包含不止一臺客戶端時,這種方法很少使用。實際上,如果那些NAT是cone NAT,或者一個是cone NAT,另一個是對稱NAT,這種情況下的P2P應(yīng)用程序依然需要工作,應(yīng)用程序需要實現(xiàn)查明在任何一個上與end STUN有關(guān)的NAT是哪一鐘,并按此來修改它的工作方式,這樣增加了算法的復(fù)雜程序并讓網(wǎng)絡(luò)變的脆弱。最

40、終,假如任何一方客戶端在2級以上的NAT下并且離客戶端最近的NAT是對稱的,預(yù)測端口的方式是無法工作的。對所有這些原因來說,應(yīng)用程序是無法實現(xiàn)這種方法的,在這里被提及是為了歷史和信息目的(就是告訴大家有這么回事,我想)3.5. Simultaneous TCP open(TCP同時打開)在一對節(jié)點都在已存在middlebox后,有一種建立直接P2P TCP連接的方法有時候會被使用。大多數(shù)TCP連接都是從一個終端發(fā)從一個SYN包到另一個終端,另一個中斷同步響應(yīng)一個SYN-ACK包。無論怎樣,對于兩個終端來說,同時通過發(fā)送同步包到對方然后用一個ACK包應(yīng)答來建立一個TCP連接是可行的。這種過程就被

41、稱為simultaneous open(同時打開)如果一個middlebox從嘗試建立一個TCP連接的私有網(wǎng)絡(luò)的外面接受一個TCP SYN包,middlebox通常以丟棄這個SYN包或者發(fā)送一個TCP RST(連接復(fù)位)包的方式來拒絕這個連接嘗試。但是,如果同步包與源和目的地址端口一起到達,那么會讓middlebox相信一個TCP連接已經(jīng)建立起來,然后middlebox將會允許數(shù)據(jù)包通過。特別是如果middlebox剛剛得到并轉(zhuǎn)換了一個從同樣地址和端口來的SYN包,它將認為連接是成立的并允許進來的SYN通過。如果客戶端A和B能彼此預(yù)測公共端口,它們各自的middlebox將分配下一個TCP連接

42、端口,如果其中一個客戶端和另一個客戶端建立一個外部的TCP連接,可以在對方SYN到達本地middlebox之前就發(fā)送SYN包通過它本地自己的middlebox,那么P2P TCP連接就可以工作了。令人遺憾的是,這個方法也可能比上面說的UDP端口號預(yù)測方法更脆弱并對時效更加敏感。首先,除非在進行TCP連接時,兩個middleboxes是簡單的防火墻或者cone NAT,在各自嘗試猜測公共端口號來讓NAT分配新的連接時,和上面(UDP端口預(yù)測)說到的完全一樣的事情會導(dǎo)致連接失敗。另外,如果有一方的客戶發(fā)送的同步包太迅速的到達對面的middlebox,遠端middlebox可能會用一個RST包拒絕S

43、YN包,接下來就會導(dǎo)致本地的middlebox關(guān)閉對話并且在將來SYN重發(fā)時使用了相同但無用的端口號。最終,對simultaneous open的支持作為一個TCP的特殊應(yīng)用,沒有在廣泛的系統(tǒng)中被使用。因此,這個方法也只為歷史因素在這里被同樣提及;它不建議被應(yīng)用程序使用。在現(xiàn)有NAT上想要實現(xiàn)P2P直接通訊的應(yīng)用程序應(yīng)該使用UDP。4. Application design guidelines(應(yīng)用程序設(shè)計思路)4.1 What works with P2P middleboxes(如何和P2P middlebox一起工作)既然UDP hole punching是在兩個都位于NAT后的主機之間建立P2P直接通訊方法中最有效率的一個,并且它可以在多種現(xiàn)有NAT上使用,如果要求建立有效的P2P通訊,通常建議這種方法,但當(dāng)直接通訊不能建立時,就得依靠簡單的傳播。(還不怎么明白) 4.2 Peers behind the same NAT(主機在同一個NAT后面)實際上有相當(dāng)數(shù)量的用戶不止2個IP地址,會有3個或者更多的IP地址。

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論