青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

posts - 126,  comments - 73,  trackbacks - 0

論壇上經常有對P2P原理的討論,但是討論歸討論,很少有實質的東西產生(源代碼)。呵呵,在這里我就用自己實現的一個源代碼來說明UDP穿越NAT的原理。

首先先介紹一些基本概念:
??? NAT(Network Address Translators),網絡地址轉換:網絡地址轉換是在IP地址日益缺乏的情況下產生的,它的主要目的就是為了能夠地址重用。NAT分為兩大類,基本的NAT和NAPT(Network Address/Port Translator)。
??? 最開始NAT是運行在路由器上的一個功能模塊。
???
??? 最先提出的是基本的NAT,它的產生基于如下事實:一個私有網絡(域)中的節點中只有很少的節點需要與外網連接(呵呵,這是在上世紀90年代中期提出的)。那么這個子網中其實只有少數的節點需要全球唯一的IP地址,其他的節點的IP地址應該是可以重用的。
??? 因此,基本的NAT實現的功能很簡單,在子網內使用一個保留的IP子網段,這些IP對外是不可見的。子網內只有少數一些IP地址可以對應到真正全球唯一的IP地址。如果這些節點需要訪問外部網絡,那么基本NAT就負責將這個節點的子網內IP轉化為一個全球唯一的IP然后發送出去。(基本的NAT會改變IP包中的原IP地址,但是不會改變IP包中的端口)
??? 關于基本的NAT可以參看RFC 1631
???
??? 另外一種NAT叫做NAPT,從名稱上我們也可以看得出,NAPT不但會改變經過這個NAT設備的IP數據報的IP地址,還會改變IP數據報的TCP/UDP端口。基本NAT的設備可能我們見的不多(呵呵,我沒有見到過),NAPT才是我們真正討論的主角。看下圖:
????????????????????????????????????????????Server S1?????????????????????????
?????????????????????????????????????????? 18.181.0.31:1235??????????????????????????
?????????????????????????????????????????????????????? ?|
????????? ^???? Session 1 (A-S1)??? ^??????? |?
????????? |?????18.181.0.31:1235????? |??????? |??
????????? v????155.99.25.11:62000? v?????? |????
??????????????????????????????????????????????????????? |
??????????????????????????????????????????????????? NAT
??????????????????????????????????????????????? 155.99.25.11
????????????????????????????????????????????????????????|
????????? ^?????Session 1 (A-S1)?? ^?????????|?
????????? |?????18.181.0.31:1235???? |??????????|?
????????? v??? 10.0.0.1:1234????????? v?????????|??
????????????????????????????????????????????????????????|
???????????????????????????????????????????????? Client A
?????????????????????????????????????????????? 10.0.0.1:1234
??? 有一個私有網絡10.*.*.*,Client A是其中的一臺計算機,這個網絡的網關(一個NAT設備)的外網IP是155.99.25.11(應該還有一個內網的IP地址,比如10.0.0.10)。如果Client A中的某個進程(這個進程創建了一個UDP Socket,這個Socket綁定1234端口)想訪問外網主機18.181.0.31的1235端口,那么當數據包通過NAT時會發生什么事情呢?
??? 首先NAT會改變這個數據包的原IP地址,改為155.99.25.11。接著NAT會為這個傳輸創建一個Session(Session是一個抽象的概念,如果是TCP,也許Session是由一個SYN包開始,以一個FIN包結束。而UDP呢,以這個IP的這個端口的第一個UDP開始,結束呢,呵呵,也許是幾分鐘,也許是幾小時,這要看具體的實現了)并且給這個Session分配一個端口,比如62000,然后改變這個數據包的源端口為62000。所以本來是(10.0.0.1:1234->18.181.0.31:1235)的數據包到了互聯網上變為了(155.99.25.11:62000->18.181.0.31:1235)。
??? 一旦NAT創建了一個Session后,NAT會記住62000端口對應的是10.0.0.1的1234端口,以后從18.181.0.31發送到62000端口的數據會被NAT自動的轉發到10.0.0.1上。(注意:這里是說18.181.0.31發送到62000端口的數據會被轉發,其他的IP發送到這個端口的數據將被NAT拋棄)這樣Client A就與Server S1建立以了一個連接。

??? 呵呵,上面的基礎知識可能很多人都知道了,那么下面是關鍵的部分了。
??? 看看下面的情況:
???????????? 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: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
????????????????????????????????????????????? |
??????????????????????????????????????? Client A
?????????????????????????????????????10.0.0.1:1234
??? 接上面的例子,如果Client A的原來那個Socket(綁定了1234端口的那個UDP Socket)又接著向另外一個Server S2發送了一個UDP包,那么這個UDP包在通過NAT時會怎么樣呢?
??? 這時可能會有兩種情況發生,一種是NAT再次創建一個Session,并且再次為這個Session分配一個端口號(比如:62001)。另外一種是NAT再次創建一個Session,但是不會新分配一個端口號,而是用原來分配的端口號62000。前一種NAT叫做Symmetric NAT,后一種叫做Cone NAT。我們期望我們的NAT是第二種,呵呵,如果你的NAT剛好是第一種,那么很可能會有很多P2P軟件失靈。(可以慶幸的是,現在絕大多數的NAT屬于后者,即Cone NAT)
??
??? 好了,我們看到,通過NAT,子網內的計算機向外連結是很容易的(NAT相當于透明的,子網內的和外網的計算機不用知道NAT的情況)。
??? 但是如果外部的計算機想訪問子網內的計算機就比較困難了(而這正是P2P所需要的)。
??? 那么我們如果想從外部發送一個數據報給內網的計算機有什么辦法呢?首先,我們必須在內網的NAT上打上一個“洞”(也就是前面我們說的在NAT上建立一個Session),這個洞不能由外部來打,只能由內網內的主機來打。而且這個洞是有方向的,比如從內部某臺主機(比如:192.168.0.10)向外部的某個IP(比如:219.237.60.1)發送一個UDP包,那么就在這個內網的NAT設備上打了一個方向為219.237.60.1的“洞”,(這就是稱為UDP Hole Punching的技術)以后219.237.60.1就可以通過這個洞與內網的192.168.0.10聯系了。(但是其他的IP不能利用這個洞)。

呵呵,現在該輪到我們的正題P2P了。有了上面的理論,實現兩個內網的主機通訊就差最后一步了:那就是雞生蛋還是蛋生雞的問題了,兩邊都無法主動發出連接請求,誰也不知道誰的公網地址,那我們如何來打這個洞呢?我們需要一個中間人來聯系這兩個內網主機。
??? 現在我們來看看一個P2P軟件的流程,以下圖為例:

?????????????????????? Server S (219.237.60.1)
???????????????????????????????????????? |
???????????????????????????????????????? |
??????????? +----------------------+----------------------+
???????????? |????????????????????????????????????????????????????????|
?NAT A (外網IP:202.187.45.3)????????????NAT B (外網IP:187.34.1.56)
???????????? |?? (內網IP:192.168.0.1)??????????????????????| (內網IP:192.168.0.1)
??????????? ?|???????????????????????????????????????????????????????? |
Client A? (192.168.0.20:4000)???????????? Client B (192.168.0.10:40000)

??? 首先,Client A登錄服務器,NAT A為這次的Session分配了一個端口60000,那么Server S收到的Client A的地址是202.187.45.3:60000,這就是Client A的外網地址了。同樣,Client B登錄Server S,NAT B給此次Session分配的端口是40000,那么Server S收到的B的地址是187.34.1.56:40000。
??? 此時,Client A與Client B都可以與Server S通信了。如果Client A此時想直接發送信息給Client B,那么他可以從Server S那兒獲得B的公網地址187.34.1.56:40000,是不是Client A向這個地址發送信息Client B就能收到了呢?答案是不行,因為如果這樣發送信息,NAT B會將這個信息丟棄(因為這樣的信息是不請自來的,為了安全,大多數NAT都會執行丟棄動作)。現在我們需要的是在NAT B上打一個方向為202.187.45.3(即Client A的外網地址)的洞,那么Client A發送到187.34.1.56:40000的信息,Client B就能收到了。這個打洞命令由誰來發呢,呵呵,當然是Server S。
??? 總結一下這個過程:如果Client A想向Client B發送信息,那么Client A發送命令給Server S,請求Server S命令Client B向Client A方向打洞。呵呵,是不是很繞口,不過沒關系,想一想就很清楚了,何況還有源代碼呢(侯老師說過:在源代碼面前沒有秘密 8)),然后Client A就可以通過Client B的外網地址與Client B通信了。
???
??? 注意:以上過程只適合于Cone NAT的情況,如果是Symmetric NAT,那么當Client B向Client A打洞的端口已經重新分配了,Client B將無法知道這個端口(如果Symmetric NAT的端口是順序分配的,那么我們或許可以猜測這個端口號,可是由于可能導致失敗的因素太多,我們不推薦這種猜測端口的方法)。
???
??? 下面是一個模擬P2P聊天的過程的源代碼,過程很簡單,P2PServer運行在一個擁有公網IP的計算機上,P2PClient運行在兩個不同的NAT后(注意,如果兩個客戶端運行在一個NAT后,本程序很可能不能運行正常,這取決于你的NAT是否支持loopback translation,詳見http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt,當然,此問題可以通過雙方先嘗試連接對方的內網IP來解決,但是這個代碼只是為了驗證原理,并沒有處理這些問題),后登錄的計算機可以獲得先登錄計算機的用戶名,后登錄的計算機通過send username message的格式來發送消息。如果發送成功,說明你已取得了直接與對方連接的成功。
??? 程序現在支持三個命令:send , getu , exit
???
??? send格式:send username message
??? 功能:發送信息給username
???
??? getu格式:getu
??? 功能:獲得當前服務器用戶列表
???
??? exit格式:exit
??? 功能:注銷與服務器的連接(服務器不會自動監測客戶是否吊線)


???源碼地址:
?? http://m.shnenglu.com/Files/kyelin/P2P_by_shootingstars.rar



from:http://www.ppcn.net/n1306c2.aspx? (shootingstars )

posted on 2007-11-13 11:32 我風 閱讀(279) 評論(0)  編輯 收藏 引用

只有注冊用戶登錄后才能發表評論。
網站導航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


<2009年12月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

常用鏈接

留言簿(12)

隨筆分類

隨筆檔案

文章檔案

相冊

收藏夾

C++

MyFavorite

搜索

  •  

積分與排名

  • 積分 - 329000
  • 排名 - 75

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            欧美日韩一区二区三区免费| 在线看日韩av| 亚洲四色影视在线观看| 午夜宅男欧美| 亚洲尤物视频网| 欧美激情小视频| 久久成人免费日本黄色| 欧美色偷偷大香| 亚洲精品麻豆| 国内精品一区二区| 欧美中文在线观看国产| 欧美在线观看网址综合| 国产精品国产三级国产普通话蜜臀 | 国产乱人伦精品一区二区| 亚洲高清视频一区| 亚洲第一在线| 美女亚洲精品| 亚洲国产高潮在线观看| 亚洲经典三级| 国产精品国产三级国产aⅴ浪潮| 另类成人小视频在线| 亚洲成人在线视频网站| 奶水喷射视频一区| 亚洲精选中文字幕| 欧美一级黄色录像| 在线欧美不卡| 欧美激情片在线观看| 日韩视频在线一区二区| 亚洲欧美在线免费| 在线欧美日韩国产| 欧美极品一区二区三区| 久久午夜羞羞影院免费观看| 国产精品日韩欧美一区二区| 亚洲无线视频| 一区二区三区av| 国产精品啊啊啊| 亚洲欧美日韩一区在线| 久久久久久久综合| 亚洲人成网站色ww在线| 欧美精品精品一区| 亚洲精品免费在线| 亚洲免费一在线| 国产精品视频一二三| 欧美专区在线观看| 亚洲国产mv| 亚洲欧美日韩国产| 永久免费视频成人| 亚洲欧美精品在线观看| 久色婷婷小香蕉久久| 狂野欧美激情性xxxx欧美| 国产一区二区精品久久| 久热国产精品| 久久伊人一区二区| 亚洲精品视频中文字幕| 中文国产成人精品久久一| 国产麻豆一精品一av一免费| 另类激情亚洲| 国产精品大片wwwwww| 久久久精品免费视频| 欧美不卡一区| 久久精品亚洲| 欧美日韩亚洲精品内裤| 久久久亚洲国产美女国产盗摄| 欧美激情亚洲自拍| 久久精品国产清自在天天线| 欧美巨乳在线观看| 久久中文字幕导航| 国产精品久久久久久亚洲毛片| 欧美成人四级电影| 国产精品网站在线播放| 亚洲欧洲视频| 国模私拍视频一区| 中日韩高清电影网| 一区二区三区毛片| 浪潮色综合久久天堂| 欧美在线视频导航| 国产精品国产自产拍高清av王其| 欧美韩日一区| 一区久久精品| 久久riav二区三区| 欧美影院午夜播放| 国产精品久久二区| 亚洲美女在线国产| 亚洲久色影视| 美女黄毛**国产精品啪啪 | 欧美专区18| 亚洲综合成人在线| 欧美日韩精品二区第二页| 欧美黄色一区二区| 亚洲国产裸拍裸体视频在线观看乱了中文 | 欧美一区=区| 香蕉久久夜色| 国产精品久久久久久久app| 91久久精品国产91性色| 亚洲全部视频| 久久综合亚州| 亚洲电影免费在线| 亚洲精选视频免费看| 久久国产精品99国产| 国产伦精品一区二区| 欧美亚洲网站| 美女福利精品视频| 狠狠色综合一区二区| 久久久久久久综合日本| 老司机免费视频一区二区| 欧美一区观看| 久久久综合激的五月天| 国产亚洲综合在线| 欧美在线亚洲一区| 模特精品裸拍一区| 亚洲精品免费电影| 欧美日韩一区综合| 亚洲综合色自拍一区| 久久久久国产精品厨房| 一区二区在线不卡| 欧美成人精品一区| 99国产精品国产精品久久| 亚洲欧美日本日韩| 国产综合网站| 欧美久久99| 亚洲欧美激情诱惑| 欧美刺激性大交免费视频| av成人毛片| 国产欧美日韩一区二区三区| 久久久视频精品| 亚洲精品在线视频观看| 欧美一级精品大片| 91久久中文| 国产精品美女黄网| 久久综合给合久久狠狠色| 日韩性生活视频| 久久久久久亚洲精品中文字幕| 在线精品一区| 国产精品久久综合| 老司机精品久久| 在线中文字幕一区| 久热爱精品视频线路一| 亚洲一二三四区| 亚洲第一二三四五区| 国产精品xxxxx| 蜜桃av久久久亚洲精品| 亚洲制服少妇| 亚洲精品影院| 免费观看久久久4p| 亚洲欧美电影在线观看| 91久久精品美女| 国产综合久久久久影院| 欧美日韩在线视频首页| 美日韩免费视频| 久久久91精品国产| 亚洲免费在线| 日韩亚洲精品电影| 欧美成人精品高清在线播放| 亚洲欧美乱综合| 日韩亚洲精品在线| 亚洲电影免费观看高清完整版| 国产精品一级在线| 欧美日韩亚洲视频| 男人的天堂亚洲| 久久久免费av| 久久国产精品久久久久久久久久 | 亚洲在线中文字幕| 亚洲美女一区| 亚洲国产电影| 欧美国产欧美综合| 久久精品男女| 欧美一区二区黄色| 国产精品99久久久久久有的能看| 亚洲国产欧美在线人成| 一区二区三区在线不卡| 国产综合一区二区| 国产综合色精品一区二区三区| 国产九九精品视频| 国产精品素人视频| 国产乱码精品一区二区三区不卡 | 国产精品v亚洲精品v日韩精品| 欧美精品一区二区三区一线天视频| 另类欧美日韩国产在线| 久久久夜夜夜| 久久夜色精品国产亚洲aⅴ | 国产精品嫩草99av在线| 国产精品扒开腿爽爽爽视频| 欧美日韩中文字幕综合视频 | 亚洲美女视频在线观看| 亚洲欧洲一区二区三区| 亚洲精品网址在线观看| 日韩午夜激情| 亚洲一区二区三区高清不卡| 午夜精品国产精品大乳美女| 欧美中文字幕不卡| 久久综合国产精品台湾中文娱乐网| 久久久久成人精品免费播放动漫| 久久国产精品久久w女人spa| 久久久久久久久久久久久久一区 | 欧美激情 亚洲a∨综合| 欧美日韩大陆在线| 国产精品美女www爽爽爽| 国产丝袜一区二区| 亚洲第一毛片| 一区二区三区成人精品|