Peer-to-Peer (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

译文版权申明：请引用此文的作者或网站注明出处：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.

 

 

4. Application design guidelines

 

 

 

 

 

 

 

 

4.程序设计指南

 

 

 

 

 

 

 

 

4.1. What works with P2P middleboxes

 

 

 

 

 

 

 

 

4.1. P2P代理的现状

 

 

 

 

 

 

 

 

       对于两端都处于NAT之后的P2P直连，当前最佳解决方案仍然是UDP打洞技术，而在各种NAT系统中这种技术也得到了相当广泛的应用。当程序需要进行有效的p2p直连的通讯时候，推荐使用UDP打洞技术，当然，当无法建立直连时，也要做好消息转发的处理。

 

 

 

 

 

 

 

 

Since UDP hole punching is the most efficient existing method of establishing direct peer-to-peer communication between two nodes that are both behind NATs, and it works with a wide variety of  existing NATs, it is recommended that applications use this technique if efficient peer-to-peer communication is required, but be prepared to fall back on simple relaying when direct communication cannot be established.

 

 

 

 

 

 

 

 

 

4.2. Peers behind the same NAT

 

 

 

 

 

 

 

 

4.2. 位于同一个NAT后的端与端通信指南

 

 

 

 

 

 

 

 

       在实际的情况中，还有相当大一部分用户不止两个IP地址（多网卡情况），而是三个或者更多，这种情况下，如果很难决定到底使用哪个地址来注册到服务器，就要应用程序将所有的地址都注册到服务器上去。

 

 

 

 

 

 

 

 

In practice there may be a fairly large number of users who have not two IP addresses, but three or more. In these cases, it is hard or impossible to tell which addresses to send to the registration server. The applications should send all its addresses, in such a case.

 

 

 

 

 

 

 

 

 

 4.3. Peer discovery

 

 

 

 

 

 

 

 

4.3. 主机发现

 

 

 

 

 

 

 

 

        应用程序发送很多包到网络的几个地址上，用于发现哪个地址对于指定的主机来说是最好的。这样是导致网络“空间浪费”的源头之一，就象是在网络上倒垃圾一样；端将会选择不正确的路由地址；就像在内部网中一样（例如：11.0.1.1，分配给DOD [DOD还不能确定是什么，查到相关文献是与美国国防部相关的协议] 的）;因此应用程序在发送hello包时，应该小心地练习。(这段话翻译得不是很好，请求指正)

 

 

 

 

 

 

 

 

      Applications sending packets to several addresses to discover which one is best to use for a given peer may become a significant source of 'space junk' littering the net, as the peer may have chosen to use routable addresses improperly as an internal LAN (e.g. 11.0.1.1, which is assigned to the DOD). Thus applications should exercise caution when sending the speculative hello packets.

 

 

 

 

 

 

 

 

 

4.4. TCP P2P applications

 

 

 

 

 

 

 

 

4.4. 基于TCP 的P2P应用程序

 

 

 

 

 

 

 

 

       套接字API被应用程序开发者广泛地使用，但它其实最初是专门设计用于 C/S模式的应用程序的。由于这个自身原因，就出现了一些限制：一个套接字只能绑定一个TCP或者UDP端口；应用程序不允许多个套接字绑定同一个端口（TCP或UDP）用于同时与多个外部节点建立会话；也不允许使用一个套接字来监听这个端口的同时，其他套接字通过这个端口发出向外的初始化会话连接。

 

 

 

 

 

 

 

 

     The sockets API, used widely by application developers, is designed with client-server applications in mind. In its native form, only a single socket can bind to a TCP or UDP port. An application is not allowed to have multiple sockets binding to the same port (TCP or UDP) to initiate simultaneous sessions with multiple external nodes (or) use one socket to listen on the port and the other sockets to initiate outgoing sessions.

 

 

 

 

 

 

 

 

 

        上面所说的“单一套接字对应单一端口”绑定约束对于UDP来说并不算一个障碍，因为UDP是一个基于数据报的协议。UDP P2P应用程序设计者可以用recvfrom()和sendto()函数来让一个SOCKET不仅发送而且可以从多个主机上接受数据报文。

 

 

 

 

 

 

 

 

    The above single-socket-to-port bind restriction is not a problem however with UDP, because UDP is a datagram based protocol. UDP P2P application designers could use a single socket to send as well as receive datagrams from multiple peers using recvfrom() and sendto() calls.

 

 

 

 

 

 

 

 

 

       但是TCP就不一样了。TCP中，每个进入和外出的连接都和一个单独的套接字保持关联。Linux 套接字API中使用 SO_REUSEADDR 选项标记了这个问题。在FreeBSD和NetBSD上，这个选项一般来说是无法正常工作的，但是，可以将其改为使用BSD-specific SetReuseAddress call(Linux中并没有这个命令，纯Unix标准中亦不存在），就可以使用了。Win32 API提供了一个等效的SetReuseAddress 命令。使用以上所提到的选项，应用程序就能使用多个套接字用来重用TCP端口。那就是说，打开两个TCP套接字流绑定使用同一个端口，只要使用listen()在一边并在另外一边使用connect()在另外一端。

 

 

 

 

 

 

 

 

         This is not the case with TCP. With TCP, each incoming and outgoing connection is to be associated with a separate socket. Linux sockets API addresses this problem with the aid of SO_REUSEADDR option. On FreeBSD and NetBSD, this option does not seem to work; but, changing it to use the BSD-specific SetReuseAddress call (which Linux doesn't have and isn't in the Single Unix Standard) seems to work.  Win32 API offers an equivalent SetReuseAddress call. Using any of the above mentioned options, an application could use multiple sockets to reuse a TCP port. Say, open two TCP stream sockets bound to the same port, do a listen() on one and a connect() from the other.

 

 

 

 

 

 

 

 

 

4.5. Use of midcom protocol

 

 

 

 

 

 

 

 

4.5. 使用 MidCom 协议

 

 

 

 

 

 

 

 

如果应用程序知道它们需要穿越的代理并且这些代理实现Midcom协议，应用程序能使用Midcom协议更容易的穿越代理。

 

 

 

 

 

 

 

 

If the applications know the middleboxes they would be traversing and these middleboxes implement the midcom protocol, applications could use the midcom protocol to ease their way through the middleboxes.

 

 

 

 

 

 

 

 

 

       例如：P2P应用程序需要NAT代理保持终端端口的绑定状态。假如代理可以支持Midcom，P2P应用程序可以控制修改绑定端口(或者绑定地址)的参数，例如生存时间，最大空闲时间，因此应用程序不仅可以直接的连接外部主机而且也可以从外部主机接受连接；这样就不需要定期保持端口绑定的状态。当应用程序不再需要绑定，也可以使用Midcom协议简单的取消绑定。

 

 

 

 

 

 

 

 

For example, P2P applications require that NAT middleboxes preserve end-point port bindings. If midcom is supported on the middleboxes, P2P applications can exercise control over port binding (or address binding) parameters such as lifetime, maxidletime, and directionality so the applications can both  connect to external peers as well as receive connections from external peers; and do not need to send periodic keep-alives to keep the port binding alive. When the application no longer needs the binding, the application could simply dismantle the binding, also using the midcom protocol.  

 

 

 

 

 

 

 

 

 参考：MidCom方案

 

 

 

 

 

 

 

 

     MidCom（Middlebox Communications）方案是通过在第三方实体和FW/NAT之间建立中间盒来通信，使FW/NAT设备变为可控的一种新的概念。如图所示，MidCom包括MidCom Agent和Middlebox，Agent通过MidCom协议通知Middlebox建立相应的NAT映射表项。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  

 

一般情况下，Middlebox集成在NAT或FW设备中，Agent可在软交换、代理服务器或终端上实现。

 

 

 

 

 

 

 

 

由于应用业务识别的智能从Middlebox移到外部的MidCom Agent上，因此，根据MidCom的架构，在不需要更改Middlebox基本特性的基础上，通过对MidCom Agent的升级就可以支持更多的新业务。这是相对于NAT/ALG方式的一个很大的优势。

 

 

 

 

 

 

 

 

从安全性考虑，MidCom方式支持控制报文和媒体流的加密，因此安全性比较高。