Peer-to-Peer (P2P) communication across middleboxes（翻译4）

最新推荐文章于 2018-11-21 15:58:00 发布

eydwyz

最新推荐文章于 2018-11-21 15:58:00 发布

阅读量345

点赞数

分类专栏： p2p

p2p 专栏收录该内容

17 篇文章 6 订阅

订阅专栏

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

译文版权申明：请引用此文的作者或网站注明出处：http://blog.csdn.net/hxhbluestar，以尊重译者的劳动成果！

3.3.3. Peers separated by multiple NATs 客户端分别处于多层NAT之后

In some topologies involving multiple NAT devices, it is not possible for two clients to establish an "optimal" P2P route between them without specific knowledge of the topology. Consider for example the following situation.

在有些网络拓扑中就存在多层NAT设备，如果不熟悉网络拓扑的知识，要想建立一条“理想的”端对端连接基本上是不可能的。让我们来看看下图这种情况：

Suppose NAT X is a large industrial NAT deployed by an internet service provider (ISP) to multiplex many customers onto a few public IP addresses, and NATs A and B are small consumer NAT gateways deployed independently by two of the ISP's customers to multiplex their private home networks onto their respective ISP-provided IP addresses. Only server S and NAT X have globally routable IP addresses; the "public" IP addresses used by NAT A and NAT B are actually private to the ISP's addressing realm, while client A's and B's addresses in turn are private to the addressing realms of NAT A and B, respectively.

Each client initiates an outgoing connection to server S as before, causing NATs A and B each to create a single public/private translation, and causing NAT X to establish a public/private translation for each session.

假如 NAT X 是由 Internet服务供应商（ISP）配置的一个大型工业 NAT，它使用少量的公网IP地址来为一些客户群提供服务；NAT A 和 NAT B 则是为ISP的两个客户群所配置的小一点的独立NAT网关，它们为各自客户群的私人家庭网络提供IP地址。只有Server S 和NAT X 拥有公网固定IP地址，而NAT A 和 NAT B所拥有的“公网”IP地址对于ISP的寻址域来说则实际上“私有”的，这时Client A的地址对于NAT A的寻址领域来说是“私有”的，Client B的地址对于NAT B的寻址域来说同样是“私有”的。

还是跟以前一样，每个客户端都建立了一个“外出”的连接到服务器S，导致NATA 和 NAT B 分别进行一次公有/私有转换，并导致 NAT X 为每个会话都建立了一个公有/私有的转换。（也就是把私有地址转换成为公网地址的过程，NAT的本质工作）

Now suppose clients A and B attempt to establish a direct peer-to- peer UDP connection. The optimal method would be for client A to send messages to client B's public address at NAT B, 192.168.1.2:31000 in the ISP's addressing realm, and for client B to send messages to A's public address at NAT B, namely 192.168.1.1:30000. Unfortunately, A and B have no way to learn these addresses, because server S only sees the "global" public addresses of the clients, 155.99.25.11:62000 and 155.99.25.11:62001.Even if A and B had some way to learn these addresses, there is still no guarantee that they would be usable because the address assignments in the ISP's private addressing realm might conflict with unrelated address assignments in the clients' private realms. The clients therefore have no choice but to use their global public addresses as seen by S for their P2P communication, and rely on NAT X to provide loopback translation.

现在让我们假设 Client A 和 Client B 想要建立一条端对端的UDP 直连。理想的方法应该是 Client A 发送一条信息到 Client B在NAT B的公网地址192.168.1.2:31000上,这个地址在ISP的寻址域内；同时 Client B也发送一条消息到Client A 在 NAT B的公网地址上，也就是192.168.1.1:30000；如果能这样发的话，问题就解决了。可惜Client A和 Client B根本就不可能知道对方的这个地址，因为Server S只记录了他们真正的公网地址155.99.25.11:62000和155.99.25.11:62001。即使 Client A 和 Client B 通过某种途径得知了这些地址，还是不能够保证这样就能进行通话了，因为这些地址是由ISP的私有寻址域分配的，可能会与私有域所分配的其他无关客户端地址相冲突因此，如果客户端之间想要进行端对端的通信的话，别无选择，只能通过他们真正的公网地址来进行；并且 NAT X必须还得支持 “loopback translation”才行。

3.3.4. Consistent port bindings 保持端口绑定

The hole punching technique has one main caveat: it works only if both NATs are cone NATs (or non-NAT firewalls), which maintain a consistent port binding between a given (private IP, private UDP) pair and a (public IP, public UDP) pair for as long as that UDP port is in use. Assigning a new public port for each new session, as a symmetric NAT does, makes it impossible for a UDP application to reuse an already-established translation for communication with different external destinations. Since cone NATs are the most widespread, the UDP hole punching technique is fairly broadly applicable; nevertheless a substantial fraction of deployed NATs are symmetric and do not support the technique.

在使用“UDP打洞技术”时有一点必须要注意：它只能在双方的NAT都是cone NAT（或者干脆没有NAT）时才能正常工作；这些NAT在自己的公网UDP端口被使用时保持着端口的绑定——[私有IP，私有UDP端口]对和[公网IP，公网UDP端口]对的一一对应。如果像 symmetricNAT那样给每个新的会话都分配一个新的公网端口，那么UDP应用程序想要与其他外部客户端进行通话，就无法重复使用已经建立好的通信转换。