• <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>
            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 我風 閱讀(273) 評論(0)  編輯 收藏 引用
            <2007年3月>
            25262728123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(12)

            隨筆分類

            隨筆檔案

            文章檔案

            相冊

            收藏夾

            C++

            MyFavorite

            搜索

            •  

            積分與排名

            • 積分 - 327110
            • 排名 - 75

            最新評論

            閱讀排行榜

            評論排行榜

            久久久久亚洲AV成人网人人软件| 久久国产综合精品五月天| 久久久久99这里有精品10| 久久精品极品盛宴观看| 国产精品久久国产精品99盘| 国产精品欧美久久久久天天影视 | 精品视频久久久久| 久久免费视频1| 久久亚洲国产精品一区二区| 日日狠狠久久偷偷色综合96蜜桃| 精品熟女少妇AV免费久久| 亚洲一区中文字幕久久| 一级做a爰片久久毛片看看| 久久精品国产第一区二区三区| 久久久网中文字幕| 久久精品国产亚洲av麻豆色欲 | 国产成人久久AV免费| 一本一道久久精品综合| 一本久久久久久久| 久久精品一区二区三区AV| 久久精品免费大片国产大片| 无码AV波多野结衣久久| 久久这里的只有是精品23| 久久人人超碰精品CAOPOREN| 久久99国产精品久久99| 色欲综合久久躁天天躁蜜桃| 婷婷久久五月天| 国产69精品久久久久APP下载| 国产综合免费精品久久久| 99久久免费国产特黄| 久久综合狠狠综合久久| 囯产极品美女高潮无套久久久| 亚洲国产成人久久综合一区77| 中文字幕亚洲综合久久| 99久久精品国产一区二区| 久久亚洲国产中v天仙www | 久久久久久久久久久免费精品| 国产V综合V亚洲欧美久久| 亚洲色欲久久久综合网东京热| 色播久久人人爽人人爽人人片aV| 久久婷婷人人澡人人|