• <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 communication across middleboxes(翻譯2)

            原文版權:Copyright (C) The Internet Society (2003).? All Rights Reserved.

            原文地址:http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt





            3.3. UDP hole punching  UDP打洞技術


                The third technique, and the one of primary interest in this document, is widely known as "UDP Hole Punching." UDP hole punching relies on the properties of common firewalls and cone NATs to allow appropriately designed peer-to-peer applications to "punch holes" through the middlebox and establish direct connectivity with each other, even when both communicating hosts may lie behind middleboxes. This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and has been informally described elsewhere on the Internet [KEGEL] and used in some recent protocols [TEREDO, ICE]. As the name implies, unfortunately, this technique works reliably only with UDP.




                第三種技術,也是這篇文章主要要研究的,就是非常有名的“UDP打洞技術”,UDP打洞技術依賴于由公共防火墻和cone NAT,允許適當的有計劃的端對端應用程序通過NAT“打洞”,即使當雙方的主機都處于NAT之后。這種技術在 RFC3027的5.1節[NAT PROT] 中進行了重點介紹,并且在Internet[KEGEL]中進行了非正式的描敘,還應用到了最新的一些協議,例如[TEREDO,ICE]協議中。不過,我們要注意的是,“術”如其名,UDP打洞技術的可靠性全都要依賴于UDP。




                 We will consider two specific scenarios, and how applications can be designed to handle both of them gracefully. In the first situation, representing the common case, two clients desiring direct peer-to- peer communication reside behind two different NATs. In the second, the two clients actually reside behind the same NAT, but do not necessarily know that they do.




                 這里將考慮兩種典型場景,來介紹連接的雙方應用程序如何按照計劃的進行通信的,第一種場景,我們假設兩個客戶端都處于不同的NAT之后;第二種場景,我們假設兩個客戶端都處于同一個NAT之后,但是它們彼此都不知道(他們在同一個NAT中)。




            3.3.1. Peers behind different NATs  處于不同NAT之后的客戶端通信



                 Suppose clients A and B both have private IP addresses and lie behind different network address translators. The peer-to-peer application running on clients A and B and on server S each use UDP port 1234.? A and B have each initiated UDP communication sessions with server S, causing NAT A to assign its own public UDP port 62000 for A's session with S, and causing NAT B to assign its port 31000 to B's session with S, respectively.



                我們假設 Client A 和 Client B 都擁有自己的私有IP地址,并且都處在不同的NAT之后,端對端的程序運行于 CLIENT A,CLIENT B,S之間,并且它們都開放了UDP端口1234。 CLIENT A和CLIENT B首先分別與S建立通信會話,這時NAT A把它自己的UDP端口62000分配給CLIENT A與S的會話,NAT B也把自己的UDP端口31000分配給CLIENT B與S的會話。如下圖所示:


            假如這個時候 CLIENT A 想與 CLIENT B建立一條UDP通信直連,如果 CLIENT A只是簡單的發送一個UDP信息到CLIENT B的公網地址138.76.29.7:31000的話,NAT B會不加考慮的將這個信息丟棄(除非NAT B是一個 full cone NAT),因為 這個UDP信息中所包含的地址信息,與CLIENT B和服務器S建立連接時存儲在NAT B中的服務器S的地址信息不符。同樣的,CLIENT B如果做同樣的事情,發送的UDP信息也會被 NAT A 丟棄。




                 Suppose A starts sending UDP messages to B's public address, however, and simultaneously relays a request through server S to B, asking B to start sending UDP messages to A's public address.? A's outgoing messages directed to B's public address (138.76.29.7:31000) cause NAT A to open up a new communication session between A's private address and B's public address. At the same time, B's messages to A's public address (155.99.25.11:62000) cause NAT B to open up a new communication session between B's private address and A's public address. Once the new UDP sessions have been opened up in each direction, client A and B can communicate with each other directly without further burden on the "introduction" server S.




                假如 CLIENT A 開始發送一個 UDP 信息到 CLIENT B 的公網地址上,與此同時,他又通過S中轉發送了一個邀請信息給CLIENT B,請求CLIENT B也給CLIENT A發送一個UDP信息到 CLIENT A的公網地址上。這時CLIENT A向CLIENT B的公網IP(138.76.29.7:31000)發送的信息導致 NAT A 打開一個處于 CLIENT A的私有地址和CLIENT B的公網地址之間的新的通信會話,與此同時,NAT B 也打開了一個處于CLIENT B的私有地址和CLIENT A的公網地址(155.99.25.11:62000)之間的新的通信會話。一旦這個新的UDP會話各自向對方打開了,CLIENT A和CLIENT B之間就可以直接通信,而無需S來牽線搭橋了。(這就是所謂的打洞技術)!




                 The UDP hole punching technique has several useful properties. Once a direct peer-to-peer UDP connection has been established between two clients behind middleboxes, either party on that connection can in turn take over the role of "introducer" and help the other party establish peer-to-peer connections with additional peers, minimizing the load on the initial introduction server S. The application does not need to attempt to detect explicitly what kind of middlebox it is behind, if any [STUN], since the procedure above will establish peer- to-peer communication channels equally well if either or both clients do not happen to be behind a middlebox.? The hole punching technique even works automatically with multiple NATs, where one or both clients are removed from the public Internet via two or more levels of address translation.




                 UDP打洞技術有很多實用的地方:第一,一旦這種處于NAT之后的端對端的直連建立之后,連接的雙方可以輪流擔任 對方的“媒人”,把對方介紹給其他的客戶端,這樣就極大的降低了服務器S的工作量;第二,應用程序不用關心這個NAT是屬于cone還是symmetric,即便要,如果連接的雙方有一方或者雙方都恰好不處于NAT之后,基于上敘的步驟,他們之間還是可以建立很好的通信通道;第三,打洞技術能夠自動運作在多重NAT之后,不論連接的雙方經過多少層NAT才到達Internet,都可以進行通信。





            譯后小記:本來已經翻譯好了,是在網文快捕中翻譯的,結果,一個全選把所有翻譯的內容全部刪除了(網文快捕的Bug?:),不得不痛苦的再翻一遍。不過,有失必有得,第二次翻譯流暢多了,希望大家讀來還順口。

            Posted on 2006-01-12 14:21 艾凡赫 閱讀(398) 評論(0)  編輯 收藏 引用 所屬分類: P2P
            99久久国产热无码精品免费久久久久| 国内精品久久久久| 香蕉久久久久久狠狠色| 久久综合给合久久狠狠狠97色69 | 人妻少妇精品久久| 漂亮人妻被黑人久久精品| 精品综合久久久久久88小说| 亚洲中文字幕无码久久综合网| 亚洲乱亚洲乱淫久久| 久久丫精品国产亚洲av不卡| 久久久国产精华液| 欧美亚洲另类久久综合| 精品熟女少妇AV免费久久| 久久99亚洲综合精品首页| 久久亚洲AV成人无码电影| 漂亮人妻被中出中文字幕久久| 久久国产精品-国产精品| 一级a性色生活片久久无少妇一级婬片免费放| 久久超碰97人人做人人爱| 伊人久久大香线蕉综合热线| 精品久久久久久无码中文字幕| 91久久婷婷国产综合精品青草| 狠狠精品久久久无码中文字幕| 久久精品国产精品亚洲艾草网美妙| 国产91色综合久久免费| 久久久久亚洲AV无码永不| 中文国产成人精品久久不卡| 久久精品国产99国产精品亚洲| 亚洲?V乱码久久精品蜜桃| 久久人人爽人人精品视频| 少妇被又大又粗又爽毛片久久黑人| 久久99精品国产麻豆婷婷| 久久精品国产99久久香蕉| 久久久久久国产精品免费免费| 精品多毛少妇人妻AV免费久久| 久久精品成人| 无码精品久久一区二区三区| 亚洲国产香蕉人人爽成AV片久久 | 久久亚洲AV无码精品色午夜 | 无码国内精品久久人妻| 久久久久久久亚洲Av无码|