• <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>

            大龍的博客

            常用鏈接

            統(tǒng)計(jì)

            最新評(píng)論

            P2P之UDP穿透NAT的原理與實(shí)現(xiàn)(附源代碼)---------來(lái)自網(wǎng)絡(luò)

            原創(chuàng):shootingstars
            參考:http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

            論壇上經(jīng)常有對(duì)P2P原理的討論,但是討論歸討論,很少有實(shí)質(zhì)的東西產(chǎn)生(源代碼)。呵呵,在這里我就用自己實(shí)現(xiàn)的一個(gè)源代碼來(lái)說(shuō)明UDP穿越NAT的原理。

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

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

            呵呵,現(xiàn)在該輪到我們的正題P2P了。有了上面的理論,實(shí)現(xiàn)兩個(gè)內(nèi)網(wǎng)的主機(jī)通訊就差最后一步了:那就是雞生蛋還是蛋生雞的問題了,兩邊都無(wú)法主動(dòng)發(fā)出連接請(qǐng)求,誰(shuí)也不知道誰(shuí)的公網(wǎng)地址,那我們?nèi)绾蝸?lái)打這個(gè)洞呢?我們需要一個(gè)中間人來(lái)聯(lián)系這兩個(gè)內(nèi)網(wǎng)主機(jī)。
            ??? 現(xiàn)在我們來(lái)看看一個(gè)P2P軟件的流程,以下圖為例:

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

            ??? 首先,Client A登錄服務(wù)器,NAT A為這次的Session分配了一個(gè)端口60000,那么Server S收到的Client A的地址是202.187.45.3:60000,這就是Client A的外網(wǎng)地址了。同樣,Client B登錄Server S,NAT B給此次Session分配的端口是40000,那么Server S收到的B的地址是187.34.1.56:40000。
            ??? 此時(shí),Client A與Client B都可以與Server S通信了。如果Client A此時(shí)想直接發(fā)送信息給Client B,那么他可以從Server S那兒獲得B的公網(wǎng)地址187.34.1.56:40000,是不是Client A向這個(gè)地址發(fā)送信息Client B就能收到了呢?答案是不行,因?yàn)槿绻@樣發(fā)送信息,NAT B會(huì)將這個(gè)信息丟棄(因?yàn)檫@樣的信息是不請(qǐng)自來(lái)的,為了安全,大多數(shù)NAT都會(huì)執(zhí)行丟棄動(dòng)作)。現(xiàn)在我們需要的是在NAT B上打一個(gè)方向?yàn)?02.187.45.3(即Client A的外網(wǎng)地址)的洞,那么Client A發(fā)送到187.34.1.56:40000的信息,Client B就能收到了。這個(gè)打洞命令由誰(shuí)來(lái)發(fā)呢,呵呵,當(dāng)然是Server S。
            ??? 總結(jié)一下這個(gè)過程:如果Client A想向Client B發(fā)送信息,那么Client A發(fā)送命令給Server S,請(qǐng)求Server S命令Client B向Client A方向打洞。呵呵,是不是很繞口,不過沒關(guān)系,想一想就很清楚了,何況還有源代碼呢(侯老師說(shuō)過:在源代碼面前沒有秘密 8)),然后Client A就可以通過Client B的外網(wǎng)地址與Client B通信了。
            ???
            ??? 注意:以上過程只適合于Cone NAT的情況,如果是Symmetric NAT,那么當(dāng)Client B向Client A打洞的端口已經(jīng)重新分配了,Client B將無(wú)法知道這個(gè)端口(如果Symmetric NAT的端口是順序分配的,那么我們或許可以猜測(cè)這個(gè)端口號(hào),可是由于可能導(dǎo)致失敗的因素太多,我們不推薦這種猜測(cè)端口的方法)。

            posted on 2006-12-28 14:21 大龍 閱讀(202) 評(píng)論(1)  編輯 收藏 引用

            評(píng)論

            # re: P2P之UDP穿透NAT的原理與實(shí)現(xiàn)(附源代碼)---------來(lái)自網(wǎng)絡(luò) 2008-01-21 11:33 sss

            sss  回復(fù)  更多評(píng)論   


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            精品国产乱码久久久久久呢| 91久久精品国产免费直播| 亚洲狠狠综合久久| 久久精品99久久香蕉国产色戒| 一本大道久久东京热无码AV| 久久九色综合九色99伊人| 色综合久久中文综合网| 99精品伊人久久久大香线蕉| 久久综合九色综合欧美狠狠| 97精品国产97久久久久久免费| 久久综合丁香激情久久| 国产福利电影一区二区三区久久久久成人精品综合 | 久久婷婷国产剧情内射白浆 | 品成人欧美大片久久国产欧美...| 青青青国产精品国产精品久久久久| 国产精品无码久久久久久| 国产精品久久久久久一区二区三区| 精品久久一区二区| 国产成人综合久久久久久| 久久精品国产福利国产琪琪| 亚洲中文字幕伊人久久无码| 亚洲伊人久久大香线蕉综合图片| 亚洲精品蜜桃久久久久久| 91精品国产9l久久久久| 久久亚洲av无码精品浪潮| 久久精品国产免费观看| 国产精品岛国久久久久| 91性高湖久久久久| 久久人人爽人人爽人人片AV高清| 久久水蜜桃亚洲av无码精品麻豆 | 一本久久精品一区二区| 国产亚洲精品美女久久久| 国内精品久久久久久久coent| 亚洲精品乱码久久久久久蜜桃| 久久亚洲日韩精品一区二区三区| 国产精品天天影视久久综合网| 久久夜色撩人精品国产| 精品久久久久久成人AV| 亚洲AV伊人久久青青草原| 精品久久久久香蕉网| 久久久久久精品免费看SSS |