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

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

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

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

3、基于代理服务上的P2P通信技术

       本章节详细地回顾了当前比较流行的一些基于当前代理设备的点对点通信技术，来源于应用或协议设计者的前瞻。

 

3.1. Relaying

3.1 转发

      

       最可靠，但又是最低效的点对点通信方法，莫过于将p2p网络通信看作一个C/S结构，通过（服务器来）转发信息。举例来说，如下图，两个客户端A和B，均与服务器S初始化了一个TCP或UDP连接，服务器S具有公网固定IP地址,两个客户端分布在不同的私网中，这样，他们各自的NAT代理服务器将不允许他们进行直连。

 

   The most reliable, but least efficient, method of implementing peer-to-peer communication in the presence of a middlebox is to make the peer-to-peer communication look to the network like client/server communication through relaying.  For example, suppose two client hosts, A and B, have each initiated TCP or UDP connections with a well-known server S having a permanent IP address. The clients reside on separate private networks, however, and their respective middleboxes prevent either client from directly initiating a connection to the other.

                           

       取而代之的方式是，两个客户端可以把服务器S当作信使来转发消息。比如，为了将消息发送到B，A先发送一条信息给服务器S，服务器S再利用初始化时已经建立的连接，将信息转发给B。

 

   Instead of attempting a direct connection, the two clients can simply use the server S to relay messages between them.  For example, to send a message to client B, client A simply sends the message to server S along its already-established client/server connection, and server S then sends the message on to client B using its existing client/server connection with B.

 

 

这个方法的优势是：当两个客户端都与服务端保持连接的时候，它将始终如一的正常工作。

但是它的劣势也很明显:它将全面依赖并消耗服务器的资源和性能和网络带宽。两个客户端的通信反应时间将明显增加，即使他们与服务器始终保持着连接。名为 TURN 的协议[TURN]定义了一个利用转发技术进行可靠通信的模型。

  

       This method has the advantage that it will always work as long as both clients have connectivity to the server.  Its obvious disadvantages are that it consumes the server's processing power and network bandwidth unnecessarily, and communication latency between   the two clients is likely to be increased even if the server is well- connected.  The TURN protocol [TURN] defines a method of implementing relaying in a relatively secure fashion.

 

3.2. Connection reversal

3.2 反向连接

 

这里介绍第二种技术，但是它只能在通信的两端只有一端处于NAT之后的情况下。举例来说，假设客户端A处于NAT之后，而客户端B有一个公网IP地址，如下图所示

 

   The second technique works if only one of the clients is behind a middlebox.  For example, suppose client A is behind a NAT but client B has a globally routable IP address, as in the following diagram:                             

 

       客户端A的私有IP地址是 10.0.0 .1，并使用TCP端口1234，客户端A初始化了一个与服务器S（IP=18.181.0.31:1235）的连接。NAT A（IP=155.99.25.11）分配了一个62000的TCP端口给这个连接。因此，服务器S认为客户端A的IP地址是 155.99.25.11:62000。而因为客户端B拥有固定IP地址138.76.29.7，所以在这个端对端的连接中，客户端B使用TCP端口1234。

 

        Client A has private IP address 10.0.0 .1, and the application is using TCP port 1234. This client has established a connection with server S at public IP address 18.181.0.31 and port 1235.  NAT A has assigned TCP port 62000, at its own public IP address 155.99.25.11, to serve as the temporary public endpoint address for A's session with S: therefore, server S believes that client A is at IP address 155.99.25.11 using port 62000.  Client B, however, has its own permanent IP address, 138.76.29.7, and the peer-to-peer application on B is accepting TCP connections at port 1234.

 

       现在我们假设客户端B将会与客户端A初始化一个端对端连接会话。B将首先试图

连接A的任何一个地址——客户端A认为是它自己所有的地址，即 10.0.0 .1:1234。或者是从服务器S观察到的地址,即155.99.25.11:62000。然而不论是连接上叙地址中的哪一个，都不可能成功。第一种情况：试图直接连到10.0.0.1肯定会失败，因为10.0.0.1根本就不是一个可以在公网上路由的IP地址；第二种情况，从B传来的TCP SYN请求将能够到达端口NAT A的端口62000，但NAT A却会拒绝这个连接请求，因为只有外出的连接才允许（进入）。

 

   Now suppose client B would like to initiate a peer-to-peer communication session with client A.  B might first attempt to contact client A either at the address client A believes itself to have, namely 10.0.0 .1:1234, or at the address of A as observed by server S, namely 55.99.25.11:62000.  In either case, however, the connection will fail.  In the first case, traffic directed to IP address 10.0.0 .1 will simply be dropped by the network because 10.0.0 .1 is not a publicly routable IP address.  In the second case, the TCP SYN request from B will arrive at NAT A directed to port 62000, but NAT A will reject the connection request because only outgoing connections are allowed.

 

       在所有的尝试都失败之后，客户端B就只能借用服务器S来传递一个到客户端A的请求，请求一个“翻转”的连接到客户端B，而客户端A，在接受了这个通过服务器S转发的请求之后，将打开一个与客户端B通讯的TCP连接（在B的公网IP地址和端口号上）。NAT A允许这个连接通过，因为这个连接起源于NAT A的内部，并且同时客户端B能够受这个连接因为B并不位于NAT之后。

   After attempting and failing to establish a direct connection to A, client B can use server S to relay a request to client A to initiate a "reversed" connection to client B.  Client A, upon eceiving this relayed request through S, opens a TCP connection to client B at B's public IP address and port number.  NAT A allows the connection to proceed because it is originating inside the firewall, and client B can receive the connection because it is not behind a middlebox.

 

       当前很多p2p系统都使用了这种技术。它的主要限制在于：只能有一端位于NAT之后这个技术才能生效。然而当今真实的情况是，越来越多的客户端两端都处于NAT之后，那么这个方法就是不可行的。因为逆向连接不是一个通用的解决方案，所以在这里就不推荐使用了。应用程序可以选择尝试做逆向连接，但是有可能消息会被自动退回——如果另外一端的消息传递机制既不是“正向”也不是“逆向”连接的话。

A variety of current peer-to-peer systems implement this technique. Its main limitation, of course, is that it only works as long as only one of the communicating peers is behind a NAT: in the increasingly common case where both peers are behind NATs, the method fails.  Because connection reversal is not a general solution to the problem, it is NOT recommended as a primary strategy. Applications may choose to attempt connection reversal, but should be able to fall back automatically on another mechanism such as relaying if neither a "forward" nor a "reverse" connection can be established.