P2P技術穿透防火墻及代碼的簡單實現

P2P技術穿透防火墻及代碼的簡單實現首先先介紹一些基本概念：NAT（NetworkAddressTranslators），網絡地址轉換：網絡地址轉換是在IP地址日益缺乏的情況下產生的，它的主要目的就是為了能夠地址重用。NAT分為兩大類，基本的NAT和NAPT（NetworkAddress/PortTranslator）。最開始NAT是運行在路由器上的一個功能模塊。最先提出的是基本的NAT，它的產生基于如下事實：一個私有網絡（域）中的節(jié)點中只有很少的節(jié)點需要與外網連接（呵呵，這是在上世紀90年代中期提出的）。那么這個子網中其實只有少數的節(jié)點需要全球唯一的IP地址，其他的節(jié)點的IP地址應該是可以重用的。因此，基本的NAT實現的功能很簡單，在子網內使用一個保留的IP子網段，這些IP對外是不可見的。子網內只有少數一些IP地址可以對應到真正全球唯一的IP地址。如果這些節(jié)點需要訪問外部網絡，那么基本NAT就負責將這個節(jié)點的子網內IP轉化為一個全球唯一的IP然后發(fā)送出去。（基本的NAT會改變IP包中的原IP地址，但是不會改變IP包中的端口）關于基本的NAT可以參看RFC1631另外一種NAT叫做NAPT，從名稱上我們也可以看得出，NAPT不但會改變經過這個NAT設備的IP數據報的IP地址，還會改變IP數據報的TCP/UDP端口?；綨AT的設備可能我們見的不多（呵呵，我沒有見到過），NAPT才是我們真正討論的主角?？聪聢D：ServerS1:1235I"Session1（A-S1）”||1:1235||v1:62000v||NAT1|"Session1（A-S1）”||1:1235||v:1234v||ClientA:1234有一個私有網絡10.*.*.*，ClientA是其中的一臺計算機，這個網絡的網關（一個NAT設備）的外網IP是1（應該還有一個內網的IP地址，比如0）。如果Client

A中的某個進程（這個進程創(chuàng)建了一個UDPSocket,這個Socket綁定1234端口）想訪問外網主機1的1235端口，那么當數據包通過NAT時會發(fā)生什么事情呢？首先NAT會改變這個數據包的原IP地址，改為1。接著NAT會為這個傳輸創(chuàng)建一個SessionCSession是一個抽象的概念，如果是TCP，也許Session是由一個SYN包開始，以一個FIN包結束。而UDP呢，以這個IP的這個端口的第一個UDP開始，結束呢，呵呵，也許是幾分鐘，也許是幾小時，這要看具體的實現了）并且給這個Session分配一個端口，比如62000，然后改變這個數據包的源端口為62000。所以本來是（:1234->1:1235）的數據包到了互聯網上變?yōu)榱耍?:62000->1:1235）。一旦NAT創(chuàng)建了一個Session后，NAT會記住62000端口對應的是的1234端口，以后從1發(fā)送到62000端口的數據會被NAT自動的轉發(fā)到上。（注意：這里是說1發(fā)送到62000端口的數據會被轉發(fā)，其他的IP發(fā)送到這個端口的數據將被NAT拋棄）這樣ClientA就與ServerS1建立以了一個連接。呵呵，上面的基礎知識可能很多人都知道了，那么下面是關鍵的部分了?？纯聪旅娴那闆r：ServerS1ServerS21:1235:1235||||+ + +|"Session2(A-S2)”||:1235|v|v1:62000v|"Session|"Session2(A-S2)”||:1235|v|v1:62000v|"Session2(A-S2)”||:1235|v:1234vConeNAT1|"Session1(A-S1)”|1:1235|v:1234v||ClientA:1234接上面的例子，如果ClientA的原來那個Socket（綁定了1234端口的那個UDPSocket）又接著向另外一個ServerS2發(fā)送了一個UDP包，那么這個UDP包在通過NAT時會怎么樣呢？這時可能會有兩種情況發(fā)生，一種是NAT再次創(chuàng)建一個Session，并且再次為這個Session分配一個端口號（比如：62001）。另外一種是NAT再次創(chuàng)建一個Session，但是不會新分配一個端口號，而是用原來分配的端口號62000。前一種NAT叫做SymmetricNAT,后一種叫做ConeNAT。我們期望我們的NAT是第二種，呵呵，如果你的NAT剛好是第一種，那么很可能會有很多P2P軟件失靈。（可以慶幸的是，現在絕大多數的NAT屬于后者，即ConeNAT）好了，我們看到，通過NAT,子網內的計算機向外連結是很容易的（NAT相當于透明的，子網內的和外網的計算機不用知道NAT的情況）。但是如果外部的計算機想訪問子網內的計算機就比較困難了（而這正是P2P所需要的）。那么我們如果想從外部發(fā)送一個數據報給內網的計算機有什么辦法呢？首先，我們必須在內網的NAT上打上一個“洞”（也就是前面我們說的在NAT上建立一個Session），這個洞不能由外部來打，只能由內網內的主機來打。而且這個洞是有方向的，比如從內部某臺主機（比如：0）向外部的某個IP（比如：）發(fā)送一個UDP包，那么就在這個內網的NAT設備上打了一個方向為的“洞”，（這就是稱為UDPHolePunching的技術）以后就可以通過這個洞與內網的0聯系了。（但是其他的IP不能利用這個洞）。呵呵，現在該輪到我們的正題P2P了。有了上面的理論，實現兩個內網的主機通訊就差最后一步了：那就是雞生蛋還是蛋生雞的問題了，兩邊都無法主動發(fā)出連接請求，誰也不知道誰的公網地址，那我們如何來打這個洞呢？我們需要一個中間人來聯系這兩個內網主機?，F在我們來看看一個P2P軟件的流程，以下圖為例：ServerS（）||+ + +||NATA（外網IP:）NATB（外網IP:6）|（內網IP:）|（內網IP:）||ClientA（0:4000）ClientB（0:40000）首先，ClientA登錄服務器，NATA為這次的Session分配了一個端口60000，那么ServerS收到的ClientA的地址是:60000，這就是ClientA的外網地址了。同樣，ClientB登錄ServerS，NATB給此次Session分配的端口是40000，那么ServerS收到的B的地址是6:40000。此時，ClientA與ClientB都可以與ServerS通信了。如果ClientA此時想直接發(fā)送信息給ClientB,那么他可以從ServerS那兒獲得B的公網地址6:40000,是不是ClientA向這個地址發(fā)送信息ClientB就能收到了呢？答案是不行，因為如果這樣發(fā)送信息，NATB會將這個信息丟棄（因為這樣的信息是不請自來的，為了安全，大多數NAT都會執(zhí)行丟棄動作）?，F在我們需要的是在NATB上打一個方向為（即ClientA的外網地址）的洞，那么ClientA發(fā)送到6:40000的信息,ClientB就能收到了。這個打洞命令由誰來發(fā)呢，呵呵，當然是ServerS?？偨Y一下這個過程：如果ClientA想向ClientB發(fā)送信息，那么ClientA發(fā)送命令給ServerS，請求ServerS命令ClientB向ClientA方向打洞。呵呵，是不是很繞口，不過沒關系，想一想就很清楚了，何況還有源代碼呢（侯老師說過：在源代碼面前沒有秘密8）），然后ClientA就可以通過ClientB的外網地址與ClientB通信了。注意：以上過程只適合于ConeNAT的情況，如果是SymmetricNAT，那么當ClientB向ClientA打洞的端口已經重新分配了，ClientB將無法知道這個端口（如果SymmetricNAT的端口是順序分配的，那么我們或許可以猜測這個端口號，可是由于可能導致失敗的因素太多，我們不推薦這種猜測端口的方法）。另一篇文章接上：下面解釋一下上面的文章中沒有提及或者說我覺得比較欠缺的地方.私有地址/端口和公有地址/端口：我們知道,現在大部分網絡采用的都是NAPT（NetworkAddress/PortTranslator）了，這個東東的作用是一個對外的對話在經過NAT之后IP地址和端口號都會被改寫，在這里把一次會話中客戶自己認為在使用的IP地址和端口號成為私有地址/端口,而把經過NAPT之后被改寫的IP地址和端口號稱為公有地址/端口.或者可以這么理解，私有地址/端口是你家里人對你的昵稱而公有地址/端口則是你真正對外公開的名字.如何獲得用戶的私用地址/端口號，這個很簡單了，而要得到公有地址/端口號就要在連接上另一臺機器之后由那臺機器看到的IP地址和端口號來表示.如果明白了上面的東西,下面進入我們的代碼，在這里解釋一下關鍵部分的實現：客戶端首先得到自己的私有地址/終端,然后向server端發(fā)送登陸請求,server端在得到這個請求之后就可以知道這個client端的公有地址/終端,server會為每一個登陸的client保存它們的私有地址/端口和公有地址/端口.OK,下面開始關鍵的打洞流程.假設clientA要向clientB對話,但是A不知道B的地址，即使知道根據NAT的原理這個對話在第一次會被拒絕，因為clientB的NAT認為這是一個從沒有過的外部發(fā)來的請求.這個時候,A如果發(fā)現自己沒有保存B的地址，或者說發(fā)送給B的會話請求失敗了，它會要求server端讓B向A打一個洞，這個B->A的會話意義在于它使NATB認為A的地址/端口是可以通過的地址/端口，這樣A再向B發(fā)送對話的時候就不會再被NATB拒絕了.打一個比方來說明打洞的過程,A想來B家做客，但是遭到了B的管家NATB的拒絕,理由是:我從來沒有聽我家B提過你的名字，這時A找到了A,B都認識的朋友server,要求server給B報一個信，讓B去跟管家說A是我的朋友，于是,B跟管家NATB說,A是我認識的朋友，這樣A的訪問請求就不會再被管家NATB所拒絕了.簡而言之,UDP打洞就是一個通過server保存下來的地址使得彼此之間能夠直接通信的過程,server只管幫助建立連接，在建立間接之后就不再介入了.下面是一個模擬P2P聊天的過程的源代碼，過程很簡單，P2PServer運行在一個擁有公網IP的計算機上，P2PClient運行在兩個不同的NAT后（注意，如果兩個客戶端運行在一個NAT后，本程序很可能不能運行正常，這取決于你的NAT是否支持loopbacktranslation，詳見/draft-ford-midcom-p2p-01.txt，當然，此問題可以通過雙方先嘗試連接對方的內網IP來解決，但是這個代碼只是為了驗證原理，并沒有處理這些問題），后登錄的計算機可以獲得先登錄計算機的用戶名，后登錄的計算機通過sendusernamemessage的格式來發(fā)送消息。如果發(fā)送成功，說明你已取得了直接與對方連接的成功。程序現在支持三個命令：send,getu,exitsend格式：sendusernamemessage功能：發(fā)送信息給usernamegetu格式：getu功能：獲得當前服務器用戶列表exit格式：exit功能：注銷與服務器的連接（服務器不會自動監(jiān)測客戶是否吊線）代碼很短，相信很容易懂，如果有什么問題，可以給我發(fā)郵件zhouhuis22@或者在CSDN上發(fā)送短消息。同時，歡迎轉發(fā)此文，但希望保留作者版權8-）。_05/04052509317298.rar〃/upload/200405/04052509317298.rar另一篇介紹打洞技術的（補充）UDP打洞技術依賴于由公共防火墻和coneNAT,允許適當的有計劃的端對端應用程序通過NAT〃打洞"，即使當雙方的主機都處于NAT之后。這種技術在RFC3027的5.1節(jié)［NATPROT］中進行了重點介紹，并且在Internet［KEGEL］中進行了非正式的描敘，還應用到了最新的一些協議，例如［TEREDO,ICE］協議中。不過，我們要注意的是，〃術〃如其名，UDP打洞技術的可靠性全都要依賴于UDP。這里將考慮兩種典型場景，來介紹連接的雙方應用程序如何按照計劃的進行通信的，第一種場景，我們假設兩個客戶端都處于不同的NAT之后；第二種場景，我們假設兩個客戶端都處于同一個NAT之后，但是它們彼此都不知道（他們在同一個NAT中）。處于不同NAT之后的客戶端通信我們假設ClientA和ClientB都擁有自己的私有IP地址，并且都處在不同的NAT之后，端對端的程序運行于CLIENTA,CLIENTB,S之間，并且它們都開放了UDP端口1234。CLIENTA和CLIENTB首先分別與S建立通信會話，這時NATA把它自己的UDP端口62000分配給C