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

            P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路)

               為了項(xiàng)目的后期IM應(yīng)用,最近在研究libjingle,中間看了也收集了很多資料,感慨網(wǎng)上很多資料要么太過(guò)于糾結(jié)協(xié)議(如STUN、ICE等)實(shí)現(xiàn)細(xì)節(jié),要么中間有很多紕漏。最后去偽存真,歸納總結(jié)了一下,希望對(duì)以后的同行有些許幫助。
               如果有什么需要討論或者指正的,歡迎留言或者郵件peakflys@gmail.com                            
            P2P實(shí)現(xiàn)的原理
            首先先介紹一些基本概念:
               NAT(Network Address Translators),網(wǎng)絡(luò)地址轉(zhuǎn)換:網(wǎng)絡(luò)地址轉(zhuǎn)換是在IP地址日益缺乏的情況下產(chǎn)生的,它的主要目的就是為了能夠地址重用。NAT從歷史發(fā)展上分為兩大類,基本的NAT和NAPT(Network Address/Port Translator)。
               最先提出的是基本的NAT(peakflys注:剛開始其實(shí)只是路由器上的一個(gè)功能模塊),它的產(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è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)過(guò)這個(gè)NAT設(shè)備的IP數(shù)據(jù)報(bào)的IP地址,還會(huì)改變IP數(shù)據(jù)報(bào)的TCP/UDP端口。基本NAT的設(shè)備可能我們見的不多(基本已經(jīng)淘汰了),NAPT才是我們真正需要關(guān)注的??聪聢D:

            有一個(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èn)外網(wǎng)主機(jī)18.181.0.31的1235端口,那么當(dāng)數(shù)據(jù)包通過(guò)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)鍵的部分了。
            看看下面的情況:

            接上面的例子,如果Client A的原來(lái)那個(gè)Socket(綁定了1234端口的那個(gè)UDP Socket)又接著向另外一個(gè)Server S2發(fā)送了一個(gè)UDP包,那么這個(gè)UDP包在通過(guò)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剛好是第一種,那么很可能會(huì)有很多P2P軟件失靈。(可以慶幸的是,現(xiàn)在絕大多數(shù)的NAT屬于后者,即Cone NAT)
            peakflys注:Cone NAT具體又分為3種:
            (1)全圓錐( Full Cone) : NAT把所有來(lái)自相同內(nèi)部IP地址和端口的請(qǐng)求映射到相同的外部IP地址和端口。任何一個(gè)外部主機(jī)均可通過(guò)該映射發(fā)送IP包到該內(nèi)部主機(jī)。
            (2)限制性圓錐(Restricted Cone) : NAT把所有來(lái)自相同內(nèi)部IP地址和端口的請(qǐng)求映射到相同的外部IP地址和端口。但是,只有當(dāng)內(nèi)部主機(jī)先給IP地址為X的外部主機(jī)發(fā)送IP包,該外部主機(jī)才能向該內(nèi)部主機(jī)發(fā)送IP包。
            (3)端口限制性圓錐( Port Restricted Cone) :端口限制性圓錐與限制性圓錐類似,只是多了端口號(hào)的限制,即只有內(nèi)部主機(jī)先向IP地址為X,端口號(hào)為P的外部主機(jī)發(fā)送1個(gè)IP包,該外部主機(jī)才能夠把源端口號(hào)為P的IP包發(fā)送給該內(nèi)部主機(jī)。
            好了,我們看到,通過(guò)NAT,子網(wǎng)內(nèi)的計(jì)算機(jī)向外連結(jié)是很容易的(NAT相當(dāng)于透明的,子網(wǎng)內(nèi)的和外網(wǎng)的計(jì)算機(jī)不用知道NAT的情況)。
            但是如果外部的計(jì)算機(jī)想訪問(wèn)子網(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就可以通過(guò)這個(gè)洞與內(nèi)網(wǎng)的192.168.0.10聯(lián)系了。(但是其他的IP不能利用這個(gè)洞)。
            P2P的常用實(shí)現(xiàn)
            一、普通的直連式P2P實(shí)現(xiàn)
            通過(guò)上面的理論,實(shí)現(xiàn)兩個(gè)內(nèi)網(wǎng)的主機(jī)通訊就差最后一步了:那就是雞生蛋還是蛋生雞的問(wèn)題了,兩邊都無(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軟件的流程,以下圖為例:
            首先,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)作)?,F(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ā)呢?自然是Server S。
            總結(jié)一下這個(gè)過(guò)程:如果Client A想向Client B發(fā)送信息,那么Client A發(fā)送命令給Server S,請(qǐng)求Server S命令Client B向Client A方向打洞。然后Client A就可以通過(guò)Client B的外網(wǎng)
            地址與Client B通信了。
            注意:以上過(guò)程只適合于Cone NAT的情況,如果是Symmetric NAT,那么當(dāng)Client B向Client A打洞的端口已經(jīng)重新分配了,Client B將無(wú)法知道這個(gè)端口(如果Symmetric NAT的端口是順序分配的,那么我們或許可以猜測(cè)這個(gè)端口號(hào),可是由于可能導(dǎo)致失敗的因素太多,這種情況下一般放棄P2P  ---peakflys)。
            二、STUN方式的P2P實(shí)現(xiàn)
            STUN是RFC3489規(guī)定的一種NAT穿透方式,它采用輔助的方法探測(cè)NAT的IP和端口。毫無(wú)疑問(wèn)的,它對(duì)穿越早期的NAT起了巨大的作用,并且還將繼續(xù)在NAT穿透中占有一席之地。
            STUN的探測(cè)過(guò)程需要有一個(gè)公網(wǎng)IP的STUN server,在NAT后面的UAC必須和此server配合,互相之間發(fā)送若干個(gè)UDP數(shù)據(jù)包。UDP包中包含有UAC需要了解的信息,比如NAT外網(wǎng)IP,PORT等等。UAC通過(guò)是否得到這個(gè)UDP包和包中的數(shù)據(jù)判斷自己的NAT類型。
            假設(shè)有如下UAC(B),NAT(A),SERVER(C),UAC的IP為IPB,NAT的IP為 IPA ,SERVER的 IP為IPC1 、IPC2。請(qǐng)注意,服務(wù)器C有兩個(gè)IP,后面你會(huì)理解為什么需要兩個(gè)IP。
            (1)NAT的探測(cè)過(guò)程
            STEP1:B向C的IPC1的port1端口發(fā)送一個(gè)UDP包。C收到這個(gè)包后,會(huì)把它收到包的源IP和port寫到UDP包中,然后把此包通過(guò)IP1C和port1發(fā)還給B。這個(gè)IP和port也就是NAT的外網(wǎng)IP和port,也就是說(shuō)你在STEP1中就得到了NAT的外網(wǎng)IP。
            熟悉NAT工作原理的應(yīng)該都知道,C返回給B的這個(gè)UDP包B一定收到。如果在你的應(yīng)用中,向一個(gè)STUN服務(wù)器發(fā)送數(shù)據(jù)包后,你沒有收到STUN的任何回應(yīng)包,那只有兩種可能:1、STUN服務(wù)器不存在,或者你弄錯(cuò)了port。2、你的NAT設(shè)備拒絕一切UDP包從外部向內(nèi)部通過(guò),如果排除防火墻限制規(guī)則,那么這樣的NAT設(shè)備如果存在,那肯定是壞了„„
            當(dāng)B收到此UDP后,把此UDP中的IP和自己的IP做比較,如果是一樣的,就說(shuō)明自己是在公網(wǎng),下步NAT將去探測(cè)防火墻類型,就不多說(shuō)了(下面有圖)。如果不一樣,說(shuō)明有NAT的存在,系統(tǒng)進(jìn)行STEP2的操作。
            STEP2:B向C的IPC1發(fā)送一個(gè)UDP包,請(qǐng)求C通過(guò)另外一個(gè)IPC2和PORT(不同與SETP1的IP1)向B返回一個(gè)UDP數(shù)據(jù)包(現(xiàn)在知道為什么C要有兩個(gè)IP了吧,為了檢測(cè)cone NAT的類型)。
            我們來(lái)分析一下,如果B收到了這個(gè)數(shù)據(jù)包,那說(shuō)明什么?說(shuō)明NAT來(lái)著不拒,不對(duì)數(shù)據(jù)包進(jìn)行任何過(guò)濾,這也就是STUN標(biāo)準(zhǔn)中的full cone NAT。遺憾的是,full cone nat太少了,這也意味著你能收到這個(gè)數(shù)據(jù)包的可能性不大。如果沒收到,那么系統(tǒng)進(jìn)行STEP3的操作。
            STEP3:B向C的IPC2的port2發(fā)送一個(gè)數(shù)據(jù)包,C收到數(shù)據(jù)包后,把它收到包的源IP和port寫到UDP包中,然后通過(guò)自己的IPC2和port2把此包發(fā)還給B。
            和step1一樣,B肯定能收到這個(gè)回應(yīng)UDP包。此包中的port是我們最關(guān)心的數(shù)據(jù),下面我們來(lái)分析:
            如果這個(gè)port和step1中的port一樣,那么可以肯定這個(gè)NAT是個(gè)CONE NAT,否則是對(duì)稱NAT。道理很簡(jiǎn)單:根據(jù)對(duì)稱NAT的規(guī)則,當(dāng)目的地址的IP和port有任何一個(gè)改變,那么NAT都會(huì)重新分配一個(gè)port使用,而在step3中,和step1對(duì)應(yīng),我們改變了IP和port。因此,如果是對(duì)稱NAT,那這兩個(gè)port肯定是不同的。
            如果在你的應(yīng)用中,到此步的時(shí)候PORT是不同的,那就只能放棄P2P了,原因同上面實(shí)現(xiàn)中的一樣。如果不同,那么只剩下了restrict cone 和port restrict cone。系統(tǒng)用step4探測(cè)是是那一種。
            STEP4:B向C的IP2的一個(gè)端口PD發(fā)送一個(gè)數(shù)據(jù)請(qǐng)求包,要求C用IP2和不同于PD的port返回一個(gè)數(shù)據(jù)包給B。
            我們來(lái)分析結(jié)果:如果B收到了,那也就意味著只要IP相同,即使port不同,NAT也允許UDP包通過(guò)。顯然這是restrict cone NAT。如果沒收到,沒別的好說(shuō),port restrict NAT.
            協(xié)議實(shí)現(xiàn)的算法運(yùn)行圖如下:
            一旦路經(jīng)到達(dá)紅色節(jié)點(diǎn)時(shí),UDP的溝通是沒有可能性的(peakflys注:準(zhǔn)備來(lái)說(shuō)除了包被防火墻blocked之外,其他情況也是有可能建立P2P的,只是代價(jià)太大,一般放棄)。一旦通過(guò)黃色或是綠色的節(jié)點(diǎn),就有連接的可能。
            最終通過(guò)STUN服務(wù)器得到自己的NAT類型和公網(wǎng)IP、Port,以后建立P2P時(shí)就非常容易了
            peakflys注:Libjingle正是通過(guò)ICE&STUN方式,建立的P2P連接。關(guān)于libjingle的介紹,待續(xù)……

            參考資料:
            1、維基百科之STUN
            2、http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt(shootingstars)

            posted on 2013-01-25 15:43 peakflys 閱讀(37586) 評(píng)論(12)  編輯 收藏 引用 所屬分類: P2P

            評(píng)論

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2013-05-15 21:04 lail3344

            寫的淺顯易懂,謝謝博主  回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2013-12-08 22:24 istep

            學(xué)習(xí)了。  回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2014-02-06 19:31 wencan

            Cone不是克隆,是圓錐  回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2014-03-25 13:48 peakflys

            已修正,謝謝@wencan
              回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2014-05-29 19:30 nobody

            樓主梳理的很用心,通俗易懂,謝謝分享~  回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2014-06-25 16:07 FreeLancer

            看了以后就明白了,再讀stun源碼就easy了,非常感謝LZ!  回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路)[未登錄] 2014-07-01 17:21 Rick

            簡(jiǎn)明扼要,寫的很好,非常感謝。  回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2014-10-31 15:55 溫輝敏

            寫的很好,全而精,將NAT的相關(guān)知識(shí)全部都理清了,謝謝!  回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2015-01-15 19:31 阿凡

            請(qǐng)求Server S命令Client B向Client A方向打dong 怎么打 ??
            B發(fā)請(qǐng)求給A???
            Server S給B命令>>???
              回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2015-01-16 11:23 peakflys

            @阿凡
            Server S把Client A的NAT信息發(fā)給Client B,然后B直接給A的NAT發(fā)一條信息即可,具體原因可以再看一下文中對(duì)Cone NAT的介紹。  回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2015-03-25 22:16 麻員維

            感謝LZ的精彩分享!  回復(fù)  更多評(píng)論   

            # re: P2P的原理和常見的實(shí)現(xiàn)方式(為libjingle開路) 2016-06-02 19:24 wainiwann

            學(xué)習(xí)了,感謝lz的分享  回復(fù)  更多評(píng)論   

            <2016年6月>
            2930311234
            567891011
            12131415161718
            19202122232425
            262728293012
            3456789

            導(dǎo)航

            統(tǒng)計(jì)

            公告

            人不淡定的時(shí)候,就愛表現(xiàn)出來(lái),敲代碼如此,偶爾的靈感亦如此……

            常用鏈接

            留言簿(4)

            隨筆分類

            隨筆檔案

            文章檔案

            搜索

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            久久精品国产一区二区| 国产精品九九久久精品女同亚洲欧美日韩综合区 | 久久av高潮av无码av喷吹| 久久强奷乱码老熟女网站| 亚洲精品国产字幕久久不卡| 国内精品九九久久久精品| 国产精品99久久久久久宅男| 久久久久久久久66精品片| 99久久久精品| 久久久久久综合网天天| 91精品国产高清久久久久久91| 亚洲综合伊人久久大杳蕉| 国产伊人久久| 国产精品美女久久久久网| 亚洲精品午夜国产VA久久成人| 久久精品亚洲福利| 久久无码av三级| 久久久久无码精品国产| 久久久久99这里有精品10| 国产精品丝袜久久久久久不卡| 久久精品国产亚洲77777| 久久国语露脸国产精品电影| 日本精品一区二区久久久| 国产激情久久久久影院小草| jizzjizz国产精品久久| 综合久久国产九一剧情麻豆| 久久久久亚洲AV综合波多野结衣| 狠狠色丁香久久综合五月| 国内精品久久人妻互换| 狠狠精品久久久无码中文字幕| 亚洲欧洲精品成人久久曰影片| 国内精品久久久久久久影视麻豆 | 久久久久久久免费视频| 久久久精品视频免费观看| 99久久亚洲综合精品网站| 色综合久久天天综合| 老司机国内精品久久久久| 久久精品一区二区三区不卡| 国产日产久久高清欧美一区| 精品久久一区二区三区| 伊人久久免费视频|