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

            yehao's Blog

            P2P網絡技術概覽與實現原理

            http://www.cnblogs.com/NeuqUstcIim/archive/2008/08/07/1263278.html
            穿越NAT的意義:

              NAT是為了節省IP地址而設計的,但它隱藏了內網機器的地址,“意外”起到了安全的作用。對外不可見,不透明的內部網絡也與互聯網的“公平” 應用,“相互共享”的思想所不容,尤其是P2P網絡中“相互服務”的宗旨,所以穿越NAT,讓眾多內部網絡的機器也參與到P2P網絡中的大集體中來,一直 是P2P開發者的所希望的。穿越NAT需要借助外部的支持,說白了就是“內外勾結”,騙過NAT。很多P2P網絡成功地實現了這一目標,但還是有一些“遺 憾”---并非所有的情況下都可以。由于客戶端是主動登錄P2P網絡才可穿越,所以P2P的方式也沒有違背企業的內部管理原則,畢竟“自由世界”的加入都 是自覺自愿的。

              NAT原理:

              NAT(Network Address Translation)網絡地址轉換/網絡地址翻譯。

              工作原理:NAT主要的通過對數據包頭的地址替換來完成內網計算機訪問外網服務的。當內部機器要訪問外部網絡時,NAT設備把內部的IP1與端 口號1(網絡層地址與傳輸層地址),轉換成NAT的外部IP2與新的端口號2,再送給外部網絡,數據返回時,再把目的為IP2:端口2的數據包替換為 IP1:端口1,送給內網機器。若通訊協議的內容中有IP地址的傳遞,如FTP協議,NAT在翻譯時還要注意數據包內涉及協議地址交互的地方也要替換,否 則協議就會出現地址混亂。在NAT設備中維護了這個要替換地址的映射表,并根據內部計算機的通訊需求維護該表。外部網絡來數據包能否進入NAT,主要是看 是否已經有可映射的表項,若沒有就會丟棄。

              1

              NAT的外部公網地址可以是一個IP,也可以是一個網段,形成地址池。NAT還可以把某個外網地址直接影射給內網的某個服務器,讓外網的用戶可以直接訪問到這臺服務器。NAT的工作的隱藏內網的機器,但允許內網主動打開到外網的通訊“通道”,也就是建立映射表項。

              NAT給P2P帶來的問題是:NAT只允許單方面發起連接,通訊的雙方不是平等的,P2P網絡的基礎有了問題,具體的表現為:

              內網主機IP是私有的,外部主機看不到,也無法主動發起連接

              即使知道了內網IP,但NAT會丟棄沒有在影射表的數據包

              內網主機可以作為客戶端訪問外網,但不能作為服務器提供服務

              當兩個主機都位于各自的NAT之后,要實現P2P的連接,就不僅是誰主動的問題,而是如何解決在兩個NAT上同時有對方映射表項的問題。

            STUN協議(IETF RFC 3489):

              STUN協議是一種通道協議,可以作為正式通訊前的通路建立,它采用的是用戶終端干預的一種方法,可以解決應用協議內部傳遞IP地址給NAT帶 來的麻煩。用戶通過其他方法得到其地址對應在NAT出口上的對外地址,然后在報文負載中所描述的地址信息就直接填寫NAT上對外地址,而不是內網的私有 IP,這樣報文的內容在經過NAT時就按普通的NAT流程轉換報文頭部的IP地址即可,負載內的IP地址信息無需再修改。利用STUN的思路可以穿越 NAT。STUN協議是客戶端/服務器協議,分兩種請求方式:一是UDP發送的綁定請求(Binding Requests),二是TCP發送的秘密請求(Shared Secret Requests)。綁定請求用于確定NAT分配的綁定地址。

              STUN標準中,根據內部終端的地址(P:p)到NAT出口的公網地址(A:b)的影射方式,把NAT分為四種類型:

              2

              1. Full Cone:來自相同的內部地址的請求消息映射為相同的外部地址,與外部地址(目的地址)無關。映射關系為P:p↔A:b,任何外部主機可通過(A:b)發送到數據到(P:p)上。

              2. Restricted Cone:來自相同的內部地址的請求消息映射為相同的外部地址,返回的數據只接受該內部節點曾發數據的那個目的計算機地址X。映射關系為P:p↔A:b↔X,只有來自X的數據包才可通過(A:b)發送到數據到(P:p)上。

              3. Port Restricted Cone:來自相同的內部地址的請求消息映射為相同的外部地址,返回的數據只接受該內部節點曾發數據的那個目的地址X:x。映射關系為 P:p↔A:b↔X:x,只有來自X:x的數據包才可通過(A:b)發送到數據到(P:p)上。

              4. Symmetric(對稱) NAT:只有來自相同的內部地址(P:p),并且發送到同一個地址(X:x) 的請求消息,才被映射為相同的外部地址(A:b),返回的數據只接受該內部節點曾發數據的那個目的地址X:x。映射關系為P:p↔A:b↔X:x,當 (P:p)訪問(Y:y)時,映射為P:p↔B:c↔Y:y。

              P2P利用STUN穿越NAT:

              位于NAT后面終端A與B要穿越NAT直接通訊,可以借助在公網上的第三者Server來幫助。

              穿越NAT的情況分為為兩種方式:

                1、一方在NAT之后,一方在公網上。這種情況相對簡單,只要讓NAT之后的終端先發起通訊,NAT就沒有作用了,它可以從Server上取得另一個Peer的地址,主動連接,回來的數據包就可以方便地穿越NAT

                2、雙方都在NAT之后,連接的成功與否與兩個NAT的類型有關。主要的思路的先通過終端與Server的連接,獲得兩個終端在NAT外部的地址(IP與 端口號),再由終端向對方的外部地址發邀請包,獲取自己與對方通訊的外部地址,俗稱為“打洞”。關鍵是獲取了NAT外部映射的地址,就可以發包直接溝通, 建立連接。但當一方是對稱型,另一方是Port Restricted或對稱型時,無法有效獲取外部地址,邀請包無法到達對方,也就無法穿越NAT。具體的分析可以根據兩個NAT的類型分成若干情況分 析,這里給一般的穿越例子。

            3

            實例:UDP穿越NAT:

              A登錄Server,NAT A分配端口11000,Server得到A的地址為100.10.10.10:11000

              B登錄Server,NAT B分配端口22000,Server得到B的地址為200.20.20.20:22000

              此時B會把直接來自A的包丟棄,所以要在NAT B上打一個方向為A的洞,那么A就可以向200.20.20.20:22000發送數據了

              打洞的指令來自Server。B向A的地址100.10.10.10:11000發一個UDP報文,被NAT A丟棄,但在NAT B上建立映射記錄,NAT B不在丟棄來自A的報文。

              Server通知A可以通訊,A發起數據UDP包給B,NAT B放行,B收到A的包,雙方開始通訊

              注:若是對稱NAT,當B向A打洞的端口要重新分配(NAT A不會再分配11000端口),B無法獲取這個端口,所以不適用本方法。

              實例:TCP穿越NAT:

              A登錄Server,NAT A分配端口11000,Server得到A的地址為100.10.10.10:11000

              B登錄Server,NAT B分配端口22000,Server得到B的地址為200.20.20.20:22000

              A向B發送TCP數據包SYN:192.168.10.11:1234=>200.20.20.20:22000,在NAT A上打洞

              B向A發送TCP數據包SYN:192.168.20.22:1234=>100.10.10.10:11000,在NAT B上打洞

              通道建立,A與B三次握手建立TCP連接

            posted on 2011-08-18 16:13 厚積薄發 閱讀(348) 評論(0)  編輯 收藏 引用 所屬分類: 網絡編程

            導航

            <2025年8月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            統計

            常用鏈接

            留言簿

            隨筆分類

            文章分類

            文章檔案

            搜索

            最新評論

            久久精品成人国产午夜| 亚洲精品无码专区久久同性男| 无码精品久久久久久人妻中字| 色婷婷久久综合中文久久蜜桃av| 久久久一本精品99久久精品66| 国产精品欧美久久久久无广告| 久久国产精品无| 99久久www免费人成精品| 99精品国产99久久久久久97| 久久99热狠狠色精品一区| 7777精品伊人久久久大香线蕉| 99久久精品免费国产大片| 亚洲伊人久久精品影院| 狠狠人妻久久久久久综合蜜桃| 人妻久久久一区二区三区| 伊人精品久久久久7777| 热99re久久国超精品首页| 精品人妻伦九区久久AAA片69| 国产精品美女久久久久网| 久久天天躁夜夜躁狠狠| 色综合久久中文字幕综合网| 中文字幕亚洲综合久久2| 久久亚洲精品无码AV红樱桃| 久久国产AVJUST麻豆| 一本一道久久a久久精品综合 | 国产99久久久国产精品小说| 日本福利片国产午夜久久| 久久99国产综合精品| 久久久久久久久无码精品亚洲日韩 | 国内精品久久久久久久涩爱| av午夜福利一片免费看久久 | 一本久久精品一区二区| 精品久久久久久久久久久久久久久| 国产亚洲精品自在久久| 99精品久久精品一区二区| 久久超碰97人人做人人爱| 九九久久自然熟的香蕉图片| 久久A级毛片免费观看| 国产V综合V亚洲欧美久久| 狠狠色婷婷综合天天久久丁香| 亚洲欧美精品伊人久久|