P2P communication across middleboxes（翻譯3）
原文版權(quán)：Copyright (C) The Internet Society (2003).All Rights Reserved.
原文地址：
http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt3.3.2. Peers behind the same NAT 客戶端都處于相同的NAT之后
Now consider the scenario in which the two clients (probably unknowingly) happen to reside behind the same NAT, and are therefore located in the same private IP address space. Client A has established a UDP session with server S, to which the common NAT has assigned public port number 62000. Client B has similarly established a session with S, to which the NAT has assigned public port number 62001.
現(xiàn)在讓我們來考慮一下兩個(gè)客戶端(很有可能不知不覺的就會(huì))同時(shí)位于相同的NAT之后，而且是在同一個(gè)子網(wǎng)內(nèi)部的情況， Client A與S之間的會(huì)話使用了NAT的62000端口，Client B與S之間的會(huì)話使用了62001端口，如下圖所示：
Suppose that A and B use the UDP hole punching technique as outlined above to establish a communication channel using server S as an introducer. Then A and B will learn each other's public IP addresses and port numbers as observed by server S, and start sending each other messages at those public addresses.The two clients will be able to communicate with each other this way as long as the NAT allows hosts on the internal network to open translated UDP sessions with other internal hosts and not just with external hosts. We refer to this situation as "loopback translation," because packets arriving at the NAT from the private network are translated and then "looped back" to the private network rather than being passed through to the public network. For example, when A sends a UDP packet to B's public address, the packet initially has a source IP address and port number of 10.0.0.1:124 and a destination of 155.99.25.11:62001. The NAT receives this packet, translates it to have a source of 155.99.25.11:62000 (A's public address) and a destination of 10.1.1.3:1234, and then forwards it on to B. Even if loopback translation is supported by the NAT, this translation and forwarding step is obviously unnecessary in this situation, and is likely to add latency to the dialog between A and B as well as burdening the NAT.
我們假設(shè)，Client A 和 Client B 要使用上一節(jié)我們所描述的 “UDP打洞技術(shù)”，并通過服務(wù)器S這個(gè)“媒人”來認(rèn)識，這樣Client A 和Client B首先從服務(wù)端S得到了彼此的公網(wǎng)IP地址和端口，然后就往對方的公網(wǎng)IP地址和端口上發(fā)送消息。在這種情況下，如果NAT 僅僅允許在 內(nèi)部網(wǎng)主機(jī)與其他內(nèi)部網(wǎng)主機(jī)（處于同一個(gè)NAT之后的網(wǎng)絡(luò)主機(jī)）之間打開UDP會(huì)話通信通道，而內(nèi)部網(wǎng)主機(jī)與其他外部網(wǎng)主機(jī)就不允許的話，那么Client A 和Client B就可以通話了。我們把這種情形叫做“l(fā)oopback translation”(“回環(huán)轉(zhuǎn)換”)，因?yàn)閿?shù)據(jù)包首先從局域網(wǎng)的私有IP發(fā)送到NAT轉(zhuǎn)換，然后“繞一圈”，再回到局域網(wǎng)中來，但是這樣總比這些數(shù)據(jù)通過公網(wǎng)傳送好。舉例來說，當(dāng) Client A發(fā)送了一個(gè)UDP數(shù)據(jù)包到 Client B的公網(wǎng)IP地址，這個(gè)數(shù)據(jù)包的報(bào)頭中就會(huì)有一個(gè)源地址10.0.0.1:124和一個(gè)目標(biāo)地址155.99.25.11:62001。NAT接收到這個(gè)包以后，就會(huì)(進(jìn)行地址轉(zhuǎn)換)解析出這個(gè)包中有一個(gè)公網(wǎng)地址源地址155.99.25.11:62000和一個(gè)目標(biāo)地址10.1.1.3:1234，然后再發(fā)送給B，雖說NAT支持“l(fā)oopback translation”，我們也發(fā)現(xiàn)，在這種情形下,這個(gè)解析和發(fā)送的過程有些多余，并且這個(gè)Client A 和Client B 之間的對話可能潛在性地給NAT增加了負(fù)擔(dān)。
The solution to this problem is straightforward, however. When A and B initially exchange address information through server S, they should include their own IP addresses and port numbers as "observed" by themselves, as well as their addresses as observed by S.The clients then simultaneously start sending packets to each other at each of the alternative addresses they know about, and use the first address that leads to successful communication. If the two clients are behind the same NAT, then the packets directed to their private addresses are likely to arrive first, resulting in a direct communication channel not involving the NAT. If the two clients are behind different NATs, then the packets directed to their private addresses will fail to reach each other at all, but the clients will hopefully establish connectivity using their respective public addresses. It is important that these packets be authenticated in some way, however, since in the case of different NATs it is entirely possible for A's messages directed at B's private address to reach some other, unrelated node on A's private network, or vice versa.
其實(shí)，解決這個(gè)問題的方案是顯而易見的。當(dāng) Client A和ClientB 最初通過服務(wù)器S交換彼此的地址信息時(shí)，他們也就應(yīng)該“發(fā)現(xiàn)”了自己的IP地址和端口——也就是服務(wù)器S所發(fā)現(xiàn)的。兩個(gè)客戶端同時(shí)的發(fā)送 數(shù)據(jù)包 到對方的公網(wǎng)地址和私有地址上，然后選擇首先使得通信成功的那個(gè)地址就可以了。如果兩個(gè)客戶端都位于同一個(gè)NAT之后，那么發(fā)往私有地址的數(shù)據(jù)包應(yīng)該先于發(fā)往公網(wǎng)地址的數(shù)據(jù)包到達(dá)，這樣就建立了一個(gè)不包括NAT的直連通信通道。如果兩個(gè)客戶端位于不同NAT之后，雖然發(fā)送到對方私有地址的數(shù)據(jù)包會(huì)毫無疑問的發(fā)送失敗，但還是很有可能使用他們各自的公網(wǎng)IP地址來建立一條通信通道的。所以檢測這些數(shù)據(jù)包的方法和工作就變得非常重要，不論如何，只要雙方都處于不同NAT之后，就完全有可能 Client A 想發(fā)送到 Client B 的信息會(huì)被發(fā)到別的無關(guān)的地方去，反之亦然（Client B 想發(fā)送到 Client A的消息也會(huì)被發(fā)到別的無關(guān)的地方去）。
(最后一句“unrelated node on A's private network”沒有完全理解是什么意思，總之，放到整個(gè)語境中，應(yīng)該就是說，Client A 瞄準(zhǔn) Client B的私有地址端口的信息會(huì)被NAT轉(zhuǎn)發(fā)到別的地方去，因?yàn)閮烧咛幱诓煌腘AT之后，NAT A 如果在 內(nèi)部網(wǎng)絡(luò) 找到了一個(gè)擁有與Client B相同的私有地址的電腦，就會(huì)把信息發(fā)送過去，這樣，就根本不會(huì)發(fā)送到 Client B 上去)