中文字幕日本人妻久久久免费,久久影视综合亚洲,精品久久久久久亚洲

Thu, 12 Jan 2006 06:22:00 GMT

P2P communication across middleboxes�Q�翻�?�Q?BR>
原文版权�Q�Copyright (C) The Internet Society (2003).All Rights Reserved.

原文地址�Q?A target=_blank>http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

3.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.

现在让我们来考虑一下两个客��L��(很有可能不知不觉的就�?同时位于相同的NAT之后�Q�而且是在同一个子�|�内部的情况�Q?Client A与S之间的会话��用了NAT�?2000端口�Q�Client B与S之间的会话��用了62001端口�Q�如下图所�C�：

screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window';}" border=0>
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.

我们假设�Q�Client A �?Client B 要��用上一节我们所描述�?“UDP打洞技术”，�q��过服务器S�q�个“媒人”来认识�Q�这样Client A 和Client B首先从服务端S得到了彼此的公网IP地址和端口，然后��往�Ҏ��的公�|�IP地址和端口上发送消息。在�q�种情况下，如果NAT 仅仅允许�?内部�|�主��Z��其他内部�|�主机（处于同一个NAT之后的网�l�主机）之间打开UDP会话通信通道�Q�而内部网��L��与其他外部网��L��׃��允许的话�Q�那么Client A 和Client B��可以通话了。我们把�q�种情�Ş叫做“loopback translation�?“回环�{换�?�Q�因为数据包首先从局域网的私有IP发送到NAT转换�Q�然后“绕一圈”，再回到局域网中来�Q�但是这��h��L��q�些数据通过公网传送好。�D例来��_��?Client A发送了一个UDP数据包到 Client B的公�|�IP地址�Q�这个数据包的报头中��׃��有一个源地址10.0.0.1:124和一个目标地址155.99.25.11:62001。NAT接收到这个包以后�Q�就�?�q�行地址转换)解析��个包中有一个公�|�地址源地址155.99.25.11:62000和一个目标地址10.1.1.3:1234�Q�然后再发送给B�Q�虽说NAT支持“loopback translation”，我们也发玎ͼ�在这�U�情形下,�q�个解析和发送的�q�程有些多余�Q��ƈ且这个Client A 和Client B 之间的对话可能潜在性地�l�NAT增加了负担�?BR>

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.

其实�Q�解册��个问题的�Ҏ��是显而易见的。当 Client A和ClientB 最初通过服务器S交换彼此的地址信息�Ӟ��他们也就应该“发现”了自己的IP地址和端口——也��是服务器S所发现的。两个客��L��同时的发�?数据�?到对方的公网地址和私有地址上，然后选择首先使得通信成功的那个地址��可以了。如果两个客��L��都位于同一个NAT之后�Q�那么发往�U�有地址的数据包应该先于发往公网地址的数据包到达�Q�这样就建立了一个不包括NAT的直�q�通信通道。如果两个客��L��位于不同NAT之后�Q�虽然发送到�Ҏ��U�有地址的数据包会毫无疑问的发送失败，但还是很有可能��用他们各自的公网IP地址来徏立一条通信通道的。所以检��这些数据包的方法和工作��变得非帔R��要，不论如何�Q�只要双斚w��处于不同NAT之后�Q�就完全有可�?Client A 惛_��送到 Client B 的信息会被发到别的无关的地方去，反之亦然�Q�Client B 惛_��送到 Client A的消息也会被发到别的无关的地方去�Q��?BR>

(最后一句“unrelated node on A's private network”没有完全理解是什么意思，��M��Q�放到整个语境中�Q�应该就是说�Q�Client A 瞄准 Client B的私有地址端口的信息会被NAT转发到别的地方去�Q�因��Z��者处于不同的NAT之后�Q�NAT A 如果�?内部�|�络扑ֈ�了一个拥有与Client B相同的私有地址的电脑，��׃��把信息发送过去，�q�样�Q�就�Ҏ��不会发送到 Client B 上去)

爱饭�?/a> 2006-01-12 14:22 发表评论

Thu, 12 Jan 2006 06:21:00 GMT

P2P communication across middleboxes�Q�翻�?�Q?BR>
原文版权�Q�Copyright (C) The Internet Society (2003).? All Rights Reserved.

原文地址�Q?A target=_blank>http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

3.3. UDP hole punching  UDP打洞技�?BR>

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.

�W�三�U�技术，也是�q�篇文章主要要研�I�的�Q�就是非常有名的“UDP打洞技术”，UDP打洞技术依赖于由公共防火墙和cone NAT�Q�允讔R��当的有计划的端对端应用�E�序通过NAT“打�z�”，即��当双方的��L��都处于NAT之后。这�U�技术在 RFC3027�?.1节[NAT PROT] 中进行了重点介绍�Q��ƈ且在Internet[KEGEL]中进行了非正式的描叙�Q�还应用��C��最新的一些协议，例如[TEREDO,ICE]协议中。不�q�，我们要注意的是，“术”如其名�Q�UDP打洞技术的可靠性全都要依赖于UDP�?BR>

   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.

   �q�里��考虑两种典型场景�Q�来介绍�q�接的双方应用程序如何按照计划的�q�行通信的，�W�一�U�场景，我们假设两个客户端都处于不同的NAT之后�Q�第二种场景�Q�我们假设两个客��L��都处于同一个NAT之后�Q�但是它们彼此都不知�?他们在同一个NAT�?�?BR>

3.3.1. Peers behind different NATs  处于不同NAT之后的客��L��通信

   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 都拥有自��q��U�有IP地址�Q��ƈ且都处在不同的NAT之后�Q�端对端的程序运行于 CLIENT A,CLIENT B,S之间�Q��ƈ且它们都开放了UDP端口1234�?CLIENT A和CLIENT B首先分别与S建立通信会话�Q�这时NAT A把它自己的UDP端口62000分配�l�CLIENT A与S的会话，NAT B也把自己的UDP端口31000分配�l�CLIENT B与S的会话。如下图所�C�：

screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window';}" border=0>
假如�q�个时�?CLIENT A 想与 CLIENT B建立一条UDP通信直连�Q�如�?CLIENT A只是��单的发送一个UDP信息到CLIENT B的公�|�地址138.76.29.7:31000的话�Q�NAT B会不加考虑的将�q�个信息丢弃�Q�除非NAT B是一�?full cone NAT�Q�，因�ؓ �q�个UDP信息中所包含的地址信息�Q�与CLIENT B和服务器S建立�q�接时存储在NAT B中的服务器S的地址信息不符。同��L��Q�CLIENT B如果做同��L��事情�Q�发送的UDP信息也会�?NAT A 丢弃�?BR>

   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 的公�|�地址上，与此同时�Q�他又通过S中�{发送了一个邀请信息给CLIENT B�Q�请求CLIENT B也给CLIENT A发送一个UDP信息�?CLIENT A的公�|�地址上。这时CLIENT A向CLIENT B的公�|�IP(138.76.29.7:31000)发送的信息��D�� NAT A 打开一个处�?CLIENT A的私有地址和CLIENT B的公�|�地址之间的新的通信会话�Q�与此同�Ӟ��NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公�|�地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对�Ҏ��开了，CLIENT A和CLIENT B之间��可以直接通信�Q�而无需S来牵�U�搭桥了�?�q�就是所谓的打洞技�?�Q?BR>

   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打洞技术有很多实用的地方：�W�一�Q�一旦这�U�处于NAT之后的端对端的直�q�徏立之后，�q�接的双方可以轮��担�?�Ҏ��的“媒人”，把对方介�l�给其他的客��L��Q�这样就极大的降低了服务器S的工作量�Q�第二，应用�E�序不用兛_��q�个NAT是属于cone�q�是symmetric�Q�即便要�Q�如果连接的双方有一�Ҏ��者双斚w��恰好不处于NAT之后�Q�基于上叙的步骤�Q�他们之间还是可以徏立很好的通信通道�Q�第三，打洞技术能够自动运作在多重NAT之后�Q�不��接的双方�l�过多少层NAT才到达Internet�Q�都可以�q�行通信�?BR>

译后��记�Q�本来已�l�翻译好了，是在�|�文快捕中翻译的�Q�结果，一个全选把所有翻译的内容全部删除�?�|�文快捕的Bug?�Q?�Q�不得不痛苦的再��M��遍。不�q�，有失必有得，�W�二�ơ翻译流畅多了，希望大家��L��q�顺口�?BR>

爱饭�?/a> 2006-01-12 14:21 发表评论

Thu, 12 Jan 2006 06:19:00 GMT

P2P communication across middleboxes�Q�翻�?�Q?BR>
从今天开始将陆箋��译Peer-to-Peer (P2P) communication across middleboxes�q�篇文章,�q�没有按照章节次序来�Q�请读者见谅�?BR>
原文版权�Q�Copyright (C) The Internet Society (2003).  All Rights Reserved.

原文地址�Q?A target=_blank>http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

3.4. UDP port number prediction UPD端口号预�a�

A variant of the UDP hole punching technique discussed above exists that allows P2P UDP sessions to be created in the presence of some symmetric NATs.  This method is sometimes called the "N+1" technique [BIDIR] and is explored in detail by Takeda [SYM-STUN]. The method works by analyzing the behavior of the NAT and attempting to predict the public port numbers it will assign to future sessions.

Consider again the situation in which two clients, A and B, each behind a separate NAT, have each established UDP connections with a permanently addressable server S:

让我们来考虑�q�样一�U�情况，有两个客��L�� A �?B�Q�他们都藏在不同的NAT后面�Q�他们都开放了一个UDP�q�接�l�具有固定IP的Server S�Q�如下图

screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window';}" border=0>
  NAT A has assigned its own UDP port 62000 to the communication session between A and S, and NAT B has assigned its port 31000 to the session between B and S.  By communicating through server S, A and B learn each other's public IP addresses and port numbers as observed by S.  Client A now starts sending UDP messages to port 31001 at address 138.76.29.7 (note the port number increment), and client B simultaneously starts sending messages to port 62001 at address 155.99.25.11.  If NATs A and B assign port numbers to new sessions  sequentially, and if not much time has passed since the A-S and B-S sessions were initiated, then a working bi-directional communication channel between A and B should result.

A's messages to B cause NAT A  to open up a new session, to which NAT A will (hopefully) assign public port number 62001, because 62001 is next in sequence after the  port number 62000 it previously assigned to the session between A and S.  Similarly, B's messages to A will cause NAT B to open a new session, to which it will (hopefully) assign port number 31001.  If
both clients have correctly guessed the port numbers each NAT assigns to the new sessions, then a bi-directional UDP communication channel will have been established as shown below.

NAT A 分配了它自己的UDP端口62000�Q�用来保�?客户端A �?服务器S 的通信会话�Q?NAT B 也分配了31000端口�Q�用来保�?客户端B �?服务器S 的通信会话。通过�?服务器S的对话，客户端A �?客户端B 都相互知道了�Ҏ��所映射的真实IP和端口�?BR>
客户端A发送一条UDP消息�?138.76.29.7:31001(��h��意到端口��L��增加)�Q�同�?客户端B发送一条UDP消息�?155.99.25.11:62001。如果NAT A 和NAT B�l�箋分配端口�l�新的会话，�q�且从A-S和B-S的会话时间消耗得�q�不多的话，那么一条处于客��L��A和客��L��B之间的双向会话通道��徏立了�?BR>
客户端A发出的消息送达B��D��了NAT A打开了一个新的会话，�q�且我们希望 NAT A��会指派62001端口�l�这个新的会话，因�ؓ62001是��62000后，NAT会自动指�z�� 从服务器S到客��L��A之间的新会话的端口号�Q�类似的�Q�客��L��B发出的消息送达A��D��?NAT B打开了一个新的会话，�q�且我们希望 NAT B ��会指派31001�q�个端口�l�新的会话；如果两个客户端都正确的猜��到了对�Ҏ��会话被指�z��端口��P��那么�q�个客户端A�Q�客��L��B的双向连接就被打通了。其�l�果如下图所�C�：

screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window';}" border=0>
Obviously there are many things that can cause this trick to fail. If the predicted port number at either NAT already happens to be in use by an unrelated session, then the NAT will skip over that port number and the connection attempt will fail.  If either NAT sometimes or always chooses port numbers non-sequentially, then the trick will fail.

If a different client behind NAT A (or B respectively) opens up a new outgoing UDP connection to any external destination after A (B) establishes its connection with S but before sending its first message to B (A), then the unrelated client will inadvertently "steal" the desired port number.  This trick is therefore much less likely to work when either NAT involved is under load.



明显的，有许多因素会��D��q�个�Ҏ��p�|�Q�如果这个预�a�的新端口�Q?2001�?1001�Q?恰好已经被一个不相关的会话所使用�Q�那么NAT��׃��跌��q�个端口��P��q�个�q�接��׃��宣告��p�|�Q�如果两个NAT有时或者��L��不按照顺序来生成新的端口��P��那么�q�个�Ҏ��也是行不通的�?BR>

如果隐藏在NAT A后的一个不同的客户端X�Q�或者在NAT B后）打开了一个新的“外出”UDP �q�接�Q��ƈ且无��个连接的目的如何�Q�只要这个动作发生在客户端A 建立了与服务器S 的连接之后，客户端A �?客户端B 建立�q�接之前�Q�那么这个无关的客户端X ��׃��h不备地“偷�?到这个我们��望分配的端口。所以，�q�个�Ҏ��变得如此脆弱而且不堪一击，只要��M��一个NAT方包含以上碰到的问题�Q�这个方法都不会奏效�?BR>

Since in practice a P2P application implementing this trick would still need to work if the NATs are cone NATs, or if one is a cone NAT and the other is a symmetric NAT, the application would need to detect beforehand what kind of NAT is involved on either end [STUN] and modify its behavior accordingly, increasing the complexity of the algorithm and the general brittleness of the network.

Finally, port number prediction has no chance of working if either client is behind two or more levels of NAT and the NAT(s) closest to the client are symmetric.  For all of these reasons, it is NOT recommended that new applications implement this trick; it is mentioned here for historical and informational purposes.

自从使用�q�种�Ҏ��来实践P2P的应用程序以�?在处�?cone NAT �p�d��的网�l�环境中�q�个�Ҏ��q�是实用的；如果有一方�ؓ cone NAT 而另外一方�ؓ symmetric NAT�Q�那么应用程序就应该预先发现另外一方的 NAT 是什么类型，再做出正��的行�ؓ来处理通信�Q�这样就增大了算法的复杂度，�q�且降低了在真实�|�络环境中的普适性�?BR>
最后，如果P2P的一方处在两�U�或者两�U�以上的NAT下面�Q��ƈ且这些NATs 接近�q�个客户端是 symmetric的话�Q�端口号预言是无效的�Q?BR>
因此�Q��ƈ不推荐��用这个方法来写新的P2P应用�E�序�Q�这也是历史的经验和教训�Q?BR>

爱饭�?/a> 2006-01-12 14:19 发表评论

Thu, 12 Jan 2006 06:18:00 GMT

P2P communication across middleboxes�Q�术语篇�Q?BR>
2. Terminology

2. 术语

In this section we first summarize some middlebox terms. We focus hereon the two kinds of middleboxes that commonly cause problems for P2P applications.

在这一章节中，首先概要的介�l�一下“代理”技术的一些术语。然后集中讨��Z��U�造成P2P应用问题的代理机制�?BR>

Firewall

A firewall restricts communication between a private internal network and the public Internet, typically by dropping packets that are deemed unauthorized.  A firewall examines but does not modify the IP address and TCP/UDP port information in packets crossing the boundary.

防火�?BR>
防火墙限制了�U�网与公�|�的通信�Q�它主要是将�Q�防火墙�Q�认为未�l�授权的的包丢弃�Q�防火墙只是��验包的数据，�q�不修改数据包中的IP地址和TCP/UDP端口信息�?BR>

Network Address Translator (NAT)

A network address translator not only examines but also modifies the header information in packets flowing across the boundary, allowing many hosts behind the NAT to share the use of a smaller number of public IP addresses (often one). Network address translators in turn have two main varieties:

�|�络地址转换�Q�NAT�Q?BR>
当有数据包通过�Ӟ��|�络地址转换器不仅检查包的信息，�q�要��包头中的IP地址和端口信息进行修攏V��以使得处于NAT之后的机器共享几个仅有的公网IP地址�Q�通常是一个）。网�l�地址转换器主要有两种�c�d��Q?BR>

Basic NAT

A Basic NAT maps an internal host's private IP address to a public IP address without changing the TCP/UDP port numbers in packets crossing the boundary.  Basic NAT is generally only useful when the NAT has a pool of public IP addresses from which to make address bindings on behalf of internal hosts.

基础NAT

基础NAT ��私�|�主机的�U�有IP地址转换成公�|�IP地址�Q�但�q�不��TCP/UDP端口信息�q�行转换。基��NAT一般用在当NAT拥有很多公网IP地址的时候，它将公网IP地址与内部主��行绑定，使得外部可以用公�|�IP地址讉K��内部��L��。（译者注�Q�实际上是只��IP转换�Q?92.168.0.23 <-> 210.42.106.35,�q�与直接讄��IP地址为公�|�IP�q�是有一定区别的�Q�特别是对于企业来说�Q�外部的信息都要�l�过�l�一防火墙才能到辑ֆ�部，但是内部��L��又可以��用公�|�IP�Q?BR>

Network Address/Port Translator (NAPT)

By far the most common, a Network Address/Port Translator examines and modifies both the IP address and the TCP/UDP port number fields of packets crossing the boundary, allowing multiple internal hosts to share a single public IP address simultaneously.

Refer to [NAT-TRAD] and [NAT-TERM] for more general information on NAT taxonomy and terminology. Additional terms that further classify NAPT are defined in more recent work [STUN]. When an internal host opens an outgoing TCP or UDP session through a network address/port translator, the NAPT assigns the session a public IP address and port number so that subsequent response packets from the external endpoint can be received by the NAPT, translated, and forwarded to the internal host. The effect is that the NAPT establishes a port binding between (private IP address, private port number) and (public IP address, public port number).

The port binding defines the address translation the NAPT will perform for the duration of the session.  An issue of relevance to P2P applications is how the NAT behaves when an internal host initiates multiple simultaneous sessions from a single (private IP, private port) pair to multiple distinct endpoints on the external network.

�|�络地址和端口�{�?�Q�NAPT�Q?BR>
�q�是最普遍的情况，�|�络地址/端口转换器检查、修改包的IP地址和TCP/UDP端口信息�Q�这��P��更多的内部主机就可以同时使用一个公�|�IP地址�?BR>
请参考[NAT-TRAD]和[NAT-TERM]两个文档了解更多的NAT分类和术语信息。另外，关于NAPT的分�c�d��术语�Q�[STUN]在最�q�做了更多的定义。当一个内部网��L��通过NAT打开一个“外出”的TCP或UDP会话�Ӟ��NAPT分配�l�这个会话一个公�|�IP和端口，用来接收外网的响应的数据包，�q�经�q��{换通知内部�|�的��L��。这样做的效果是�Q�NAPT�?[�U�有IP:�U�有端口] 和[公网IP:公网端口]之间建立了一个端口绑定�?BR>
端口�l�定指定了NAPT��在�q�个会话的生存期内进行地址转换��d��。这中间存在一个这��L��问题�Q�如果P2P应用�E�序从内部网�l�的一个[�U�有IP地址:端口]对同时发出多条会话给不同的外�|�主机，那么NAT会怎样处理呢？��L��以下几种�Ҏ��?BR>

Cone NAT

After establishing a port binding between a (private IP, private port) tuple and a (public IP, public port) tuple, a cone NAT will re-use this port binding for subsequent sessions the    application may initiate from the same private IP address and port number, for as long as at least one session using the port binding remains active.

锥�ŞNAT

�Q�译者注�Q��ؓ什么叫做锥形呢�Q�请看以下图�?�l�端和外部服务器�Q�都通过NAT分派的这个绑定地址�Ҏ��传送信息，��p��一个漏斗一��P��{�选�ƈ传递信息）

screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window';}" border=0>

当徏立了一�?[�U�有IP:端口]-[公网IP:端口] 端口�l�定之后�Q�对于来自同一个[�U�有IP:端口]会话�Q�锥形NAT服务器允许发起会话的应用�E�序重复使用�q�个端口�l�定�Q�一直到�q�个会话�l�束才解除（端口�l�定�Q��?BR>

For example, suppose Client A in the diagram below initiates two simultaneous outgoing sessions through a cone NAT, from the same internal endpoint (10.0.0.1:1234) to two different external servers, S1 and S2.  The cone NAT assigns just one public endpoint tuple�Q�元�l�）, 155.99.25.11:62000, to both of these sessions, ensuring that the "identity" of the client's port is maintained across address translation. Since Basic NATs and firewalls do not modify port numbers as packets flow across the middlebox, these types of middleboxes can be viewed as a degenerate form of Cone NAT.
screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window';}" border=0>

例如�Q�假�?Client A�Q�IP地址信息如上图所�C�）通过一�?锥�ŞNAT 同时发�v两个外出的连接，它��用同一个内部端口（10.0.0.1:1234�Q�给公网的两��C��同的服务器，S1和S2。锥形NAT 只分配一个公�|�IP和端口（155.99.25.11:62000�Q�给�q�个两个会话�Q�通过地址转换可以 ��保 Client使用端口的“同一性”（译者注�Q�即�q�个Client只��用这个端口）。而基��NATs和防火墙却不能修改经�q�的数据包端口号�Q�它们可以看作是锥�ŞNAT的精��版本�?BR>


Symmetric NAT

A symmetric NAT, in contrast, does not maintain a consistent  port binding  between (private IP, private port) and (public IP, public port) across all sessions.

Instead, it assigns a new public port to each new session. For example, suppose Client A initiates two outgoing sessions from the same port as above, one with S1 and one with S2.  A symmetric NAT might allocate the public endpoint 155.99.25.11:62000 to session 1, and then allocate a different public endpoint 155.99.25.11:62001, when the application initiates session 2.  The NAT is able to differentiate between the two sessions for translation purposes because the    external endpoints involved in the sessions (those of S1 and S2) differ, even as the endpoint identity of the client application is lost across the address translation boundary.

对称NAT

对称NAT�Q�与Cone NAT是大不相同的�Q��ƈ不对会话�q�行端口�l�定�Q�而是分配一个全新的公网端口 �l�每一个新的会话�?BR>
�q�是上面那个例子�Q�如�?Client A (10.0.0.1:1234)同时发�v两个 "外出" 会话,分别发往S1和S2。对�U�Nat会分配公共地址155.99.25.11:62000�l�Session1�Q�然后分配另一个不同的公共地址155.99.25.11:62001�l�Session2。对�U�Nat能够区别两个不同的会话�ƈ�q�行地址转换�Q�因为在 Session1 �?Session2中的外部地址是不同的�Q�正是因��P��Client端的应用�E�序��p��失在�q�个地址转换边界�U�了�Q�因��个应用程序每发出一个会话都会��用一个新的端口，无法保障只��用同一个端口了�?BR>

screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window';}" border=0>'

The issue of cone versus symmetric NAT behavior applies equally to TCP and UDP traffic. Cone NAT is further classified according to how liberally the NAT accepts incoming traffic directed to an already-established (publicIP, public port) pair.  This classification generally applies only to UDP traffic, since NATs and firewalls reject incoming TCP connection attempts unconditionally unless specifically configured to do otherwise.

在TCP和UDP通信中， �Q�到底是使用同一个端口，�q�是分配不同的端口给同一个应用程序）�Q�锥形NAT和对�U�NAT各有各的理由。当焉��形NAT在根据如何公�q�_��NAT接受的连接直达一个已创徏的地址对上有更多的分类。这个分�c�M��般应用在Udp通信�Q�而不是Tcp通信上）�Q�因为NATs和防火墙��L��了试图无条�g传入的TCP�q�接�Q�除非明��设�|�NAT不这样做。这些分�c�d��下：

Full Cone NAT

After establishing a public/private port binding for a new outgoing session, a full cone NAT will subsequently accept incoming traffic to the corresponding public port from ANY    external endpoint on the public network.  Full cone NAT is also sometimes called "promiscuous" NAT.

全双工锥形NAT

当内部主机发��Z��个“外出”的�q�接会话�Q�就会创��Z��一�?公网/�U�网地址�Q�一旦这个地址对被创徏�Q�全双工锥�ŞNAT会接攉��后�Q何外部端口传入这个公��q��口地址的通信。因此，全双工锥形NAT有时候又被称�?��h��"NAT�?BR>

Restricted Cone NAT

A restricted cone NAT only forwards an incoming packet directed to a public port if its external (source) IP address matches the address of a node to which the internal host has previously sent one or more outgoing packets. A restricted cone NAT effectively refines the firewall principle of rejecting unsolicited incoming traffic, by restricting incoming traffic to a set of "known" external IP addresses.

受限制的锥�ŞNAT

受限制的锥�ŞNAT会对传入的数据包�q�行�{�选，当内部主机发出“外出”的会话�Ӟ��NAT会记录这个外部主机的IP地址信息�Q�所以，也只有这些有记录的外部IP地址�Q�能够将信息传入到NAT内部�Q�受限制的锥形NAT 有效的给防火墙提��g��{�选包的原则——即限定只给那些已知的外部地址“传入”信息到NAT内部�?BR>

Port-Restricted Cone NAT

A port-restricted cone NAT, in turn, only forwards an incoming packet if its external IP address AND port number match those of an external endpoint to which the internal host has previously sent outgoing packets. A port-restricted cone NAT provides internal nodes the same level of protection against unsolicited incoming traffic that a symmetric NAT does, while maintaining a private port's identity across translation.

端口受限制的Cone NAT

端口受限制的锥�ŞNAT�Q�与受限制的锥�ŞNAT不同的是�Q�它同时记录了外部主机的IP地址和端口信息，端口受限制的锥�ŞNAT�l�内部节�Ҏ��供了同一�U�别的保护，在维持端口“同一性”过�E�中�Q�将会丢弃对�U�NAT传回的信息�?BR>

Finally, in this document we define new terms for classifying the P2P-relevant behavior of middleboxes:

最后，在这��文档里我们��定义一�l�新的术�?�Q�以便更好的对P2P代理相关的行��行分�c�R�?BR>

P2P应用�E�序

P2P应用�E�序是指�Q�在已有的一个公共服务器的基��上，�q�分别利用自��q��U�有地址或者公有地址�Q�或者两者兼备）来徏立一个端到端的会话通信�?BR>
P2P-Application

P2P-application as used in this document is an application in which each P2P participant registers with a public registration server, and subsequently uses either its private endpoint, or public endpoint, or both, to establish peering sessions.

P2P-Middlebox

A P2P-Middlebox is middlebox that permits the traversal of P2P applications.

P2P代理

P2P代理是一个允�?P2P应用�E�序�q�行通信的代理机�?BR>

P2P-firewall

A P2P-firewall is a P2P-Middlebox that provides firewall functionality but performs no address translation.

P2P防火�?BR>
P2P防火墙是一个提供了防火墙的功能的P2P代理�Q�但是不�q�行地址转换.

P2P-NAT

A P2P-NAT is a P2P-Middlebox that provides NAT functionality, and may also provide firewall functionality. At minimum, a P2P-Middlebox must implement Cone NAT behavior for UDP traffic, allowing applications to establish robust P2P connectivity using the UDP hole punching technique.

P2P-NAT

P2P-NAT 是一�?P2P代理,提供了NAT的功�?也提供了防火墙的功能,一个最��的P2P代理必须��h�� 锥�ŞNAT对Udp通信支持的功�?�q�允许应用程序利用Udp打洞技术徏立强健的P2P�q�接�?BR>

Loopback translation

When a host in the private domain of a NAT device attempts to connect with another host behind the same NAT device using the public address of the host, the NAT device performs the equivalent of a "Twice-nat" translation on the packet as follows. The originating host's private endpoint is translated into its assigned public endpoint, and the target host's public endpoint is translated into its private endpoint, before the packet is forwarded to the target host. We refer the above translation performed by a NAT device as "Loopback translation".

回环转换

当NAT的私�|�内部机器想通过公共地址来访问同一台局域网内的机器的时�Q�NAT讑֤��{��h于做了两�ơNAT的事情，在包到达目标机器之前�Q�先��私有地址转换为公�|�地址�Q�然后再��公�|�地址转换回私有地址。我们把��h��上叙转换功能的NAT讑֤�叫做“回环�{换”设备�?BR>

爱饭�?/a> 2006-01-12 14:18 发表评论

P2P communication across middleboxes�Q�前�a��）

Thu, 12 Jan 2006 06:16:00 GMT

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

原文地址�Q?A target=_blank>http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

译文版权��x��Q�请引用此文的作者或�|�站注明出处�Q?BR>

http://blog.csdn.net/hxhbluestar�Q�以��重译者的力_��成果�Q?BR>
随着IPv6时代的到来，我也一直怀疑，是不是还有必要再��d��习NAT技术——因为网�l�的资源不再如IPv4时代匮乏�Q�而NAT技术正是�ؓ解决IP地址的紧�~��存在的�Q�如此，NAT便没有存在的必要了�?BR>
但是�Q�随着�q�篇文章的翻译，我的怀疑慢慢变成庆�q�，渐而又变�ؓ肯定�Q�通过��译所学到的东西，不再仅仅是翻译第一手资料带来的成就感，更多的是通过��译�Q�去领悟技术前辈们的智慧与�l�验�Q�也通过��译�Q�养成自�׃��W�一手资料获得信息的习惯�Q�从而将视野攑־�更宽�Q�让理解更�ؓ透彻——至��，很多东西都是要经�q�仔�l�斟酌才真正转化��己思想的一部分的。正是如此，我才坚定的要把这��文章翻译完�Q�也如之前所提到的，如果旉��允许的话�Q�我会用C#来写一些例子，让大家更好的理解NAT技术，掌握NAT技术（主要涉及到即旉��讯、文件对�{�传输和语音应用三个斚w��Q��?BR>
�q�篇文章主要是介�l�一下“代理”机制的起因以及�l�P2P应用带来的不便，不需要�Q何基��知识�Q�）

1. Introduction

1、简�?BR>

关键词：

middleboxe(s) —�?我翻译成“代理”，也许有更好的��译

host          —�?我翻译成“主机”，希望大家不要理解成服务器了，��L��是一台普通的�l�端�?BR>

Present-day Internet has seen ubiquitous deployment of "middleboxes" such as network address translators(NAT), driven primarily by the ongoing depletion of the IPv4 address space.  The asymmetric addressing and connectivity regimes established by these middleboxes, however, have created unique problems for peer-to-peer (P2P) applications and  protocols, such as teleconferencing and multiplayer on-line gaming. These issues are likely to persist even into the IPv6 world, where NAT is often used as an IPv4 compatibility mechanism [NAT-PT], and firewalls will still be commonplace even after NAT is no longer required.

在当今的Internet中，普遍存在使用“代理”设备来�q�行�|�络地址转换�Q�NAT�Q�，��D��q�种现象的原因是 IPV4 地址�I�间的资源耗尽危机。虽然不对称 asymmetric 的地址分配和连通性制度已�l�在代理中被定义�Q�但是却�l�端对端应用�E�序和协议制定造成了一些特�D�的问题。像电话会议和多媒体�|�络游戏。这些问题即使在IPV6世界中还是会存在�Q�因为NAT作�ؓIPV4的一�U�兼�Ҏ��机制经常被使用[NAT-PT]�Q��ƈ且防火墙��仍然将普遍存在�Q�即使不再需要NAT技术�?BR>

Currently deployed middleboxes are designed primarily around the client/server paradigm, in which relatively anonymous client machines actively initiate connections to well-connected servers having stable IP addresses and DNS names.

Most middleboxes implement an asymmetric communication model in which hosts on the private internal network can initiate outgoing connections to hosts on the public network, but external hosts cannot initiate connections to internal hosts except as specifically configured by the middlebox's ****istrator. In the common case of NAPT, a client on the internal network does not have a unique IP address on the public Internet, but instead must share a single public IP address, managed by the NAPT, with other hosts on the same private network.The anonymity and inaccessibility of the internal hosts behind a middlebox is not a problem for client software such as web browsers, which only need to initiate outgoing connections. This inaccessibility is sometimes seen as a privacy benefit.

当前使用的“代理”技术主要是�?客户�?服务�?C/S �l�构设计的，��Z��实现那些需要连接但是又没有固定IP地址的客��L��能够�q�接��C��台配�|�好的拥有固定IP和DNS域名的服务器�?BR> 大多数的“代理”��用一�U?asymmetric 通信模型�Q�即 �U�网�Q�局域网�Q?的主��发�v一个“外出”连接去�q�接公网上的��L��?但是公网上的��L��却无法发送信息给�U�网上的��L��Q�除非对“代理”进行特�D�的配置�Q�，NAPT�Q�网�l�地址端口转换�Q�的普通情冉|��Q�一个私�|�客��L��不需要一个公�|�的固定的IP地址�Q�但是必��要�׃�n一个由NAPT控制的公�|�的固定IP地址�Q�当然这个NAPT是处于同一个私�|�内部的�Q�。这��L��话，�q�些匿名的�ƈ且看��h��难以触及的藏在NAT之后的内�|�主机对于像 Web��览�?�q�种软�g来说��׃��是一个问�?因�ؓ内网的主机只需要发起向外部的连接就可以了。这样一来，无法触及也还是有他的优点的——那��是��h��保密性�?BR>

In the peer-to-peer paradigm, however, Internet hosts that would normally be considered "clients" need to establish communication sessions directly with each other. The initiator and the responder might lie behind different middleboxes with neither endpoint having any permanent IP address or other form of public network presence. A common on-line gaming architecture, for example, is for the participating application hosts to contact a well-known server for initialization and ****istration purposes. Subsequent to this, the hosts establish direct connections with each other for fast and efficient propagation of updates during game play.

Similarly, a file sharing application might contact a well-known server for resource discovery or searching, but establish direct connections with peer hosts for data transfer. Middleboxes create problems for peer-to-peer connections because hosts behind a middlebox normally have no permanently usable public ports on the Internet to which incoming TCP or UDP connections from other peers can be directed.

RFC 3235 [NAT-APPL] briefly addresses this issue, but does not offer any general solutions.

然而，在P2P的应用中�Q�Internet上的“客��h��”之间是需要徏立一个通信会话直连的。邀误��和响应者也�怼�处于不同的NAT之后�Q�也�总�们都没有固定IP或者即使有也不是公�|�的IP地址。�D例来��_��在一个普通的�|�络游戏体系�l�构中，都是通过客户端向一个具有公�|�固定IP的服务器发�v甌��q�行初始化�ƈ通过验证的。同�Ӟ��客户端之间也要徏立直�q�，才�ɾ|�络间传输的速度加快�Q�保证数据即时更斎ͼ�不然抢不到装备啊�Q�呵呵）�?BR>
同样的，一个文件共享应用程序也必须通过��C��个服务器上去查找它想要的资源�Q�然后再到拥有这个数据的��L��上去下蝲�Q�BT�|�站�Q�走了一个中介）�Q�“代理”造成了很多P2P直连的问题，因�ؓ藏在“代理”之后的的主机通常没有固定的端口来使其他的客户端发��L��TCP或UDP�q�接能够最�l�到达�?BR>
RFC 3235[NAT-APPL] ��要的提到了这个问题，但是没有�l�出��M��的解��x��案�?BR>

In this document we address the P2P/middlebox problem in two ways. First, we summarize known methods by which P2P applications can work around the presence of middleboxes. Second, we provide a set of application design guidelines based on these practices to make P2P applications operate more robustly over currently-deployed middleboxes. Further, we provide design guidelines for future middleboxes to allow them to support P2P applications more effectively. Our focus is to enable immediate and wide deployment of P2P applications requiring to traverse middleboxes.

在这��文章中�Q�我们用两种方式讨论 P2P/代理的问题。首先，概要的讲叙已有的P2P应用�E�序能够在现有的代理机制中的工作原理。然后，我们提供一�l�应用程序设计指南，��Z��已有的实践，在现有的配置好的代理上，来��得P2P应用�E�序操作更加有条理。最后，我们提供了设计指南，��Z��后的代理机制能够更方便支持P2P应用�E�序。讨论的焦点是如�?直接的、广泛的配置那些需要经�q�“代理”的P2P应用�E�序�?BR>

爱饭�?/a> 2006-01-12 14:16 发表评论

P2P之UDP�I�K��NAT的原理与实现 - 增强��?附修改过的源代码)

Thu, 12 Jan 2006 06:05:00 GMT

关键�? P2P UDP NAT 原理 �I�K�?Traveral Symmetric Cone
原始作�? Hwycheng Leo(FlashBT@Hotmail.com)
源码下蝲: http://bbs.hwysoft.com/download/UDP-NAT-LEO.rar
参考：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
   P2P之UDP�I�K��NAT的原理与实现(shootingstars)

文章说明:

关于UDP�I�K��NAT的中文资料在�|�络上是很少的，仅有<>�q�篇文章有实际的参考�h倹{��本��两年来也一直从事P2P斚w��的开发工作，比较有代表性的是个人开发的BitTorrent下蝲软�g - FlashBT(变态快�?. 对P2P下蝲或者P2P的开发感兴趣的朋友可以访问��Y件的官方主页: http://www.hwysoft.com/chs/ 下蝲看看�Q�说不定有收莗��写�q�篇文章的主要目的是懒的再每�ơ单独回�{�一些网友的提问, 一�ơ性写下来, 卌��省了自己的时��_��也方便了对于P2P的UDP�I�K��感兴趣的网友阅��d��理解。对此有兴趣和经验的朋友可以�l�我发邮件或者访问我的个人Blog留言: http://hwycheng.blogchina.com.
您可以自��p�{载此��文章，但是请保留此说明�?BR>
再次感谢shootingstars�|�友的早期�A�? 表示谢意�?BR>
------------------------------------------------------------------------------------------------------------

NAT(The IP Network Address Translator) 的概念和意义是什�?

NAT, 中文��译为网�l�地址转换。具体的详细信息可以讉K��RFC 1631 - http://www.faqs.org/rfcs/rfc1631.html, �q�是对于NAT的定义和解释的最权威的描�q�。网�l�术语都是很抽象和艰涩的�Q�除非是专业人士�Q�否则很难从字面中来准确理解NAT的含义�?BR>
要想完全明白NAT 的作用，我们必须理解IP地址的两大分�c�，一�c�L��U�有IP地址�Q�在�q�里我们�U�C��内网IP地址。一�c�L��非私有的IP地址�Q�在�q�里我们�U�C��公网IP地址。关于IP地址的概念和作用的介�l�参见我的另一��文�? http://hwycheng.blogchina.com/2402121.html

内网IP地址: 是指使用A/B/C�c�M��的私有地址, 分配的IP地址在全球不惧有唯一性，也因此无法被其它外网��L��直接讉K��?BR>公网IP地址: 是指��h��全球唯一的IP地址�Q�能够直接被其它��L��讉K��的�?BR>
NAT 最初的目的是�ؓ使用内网IP地址的计��机提供通过��数几台��h��公网的IP地址的计��机讉K��外部�|�络的功能。NAT 负责��某些内�|�IP地址的计��机向外部网�l�发出的IP数据包的源IP地址转换为NAT自己的公�|�的IP地址�Q�目的IP地址不变, �q�将IP数据包�{发给路由器，最�l�到辑֤�部的计算机。同时负责将外部的计��机�q�回的IP数据包的目的IP地址转换为内�|�的IP地址�Q�源IP地址不变�Q��ƈ最�l�送达到内�|�中的计��机�?BR>
      ----------------------                         ----------------------
      | 192.168.0.5       |  Internat host          | 192.168.0.6       |  Internat host
      ----------------------                         ----------------------
            ^ port:2809                                     ^port: 1827
            |                                              |
            V                                              V
      ----------------------                         ----------------------
      | 192.168.0.1       | NAT device             | 192.168.0.2       | NAT device
      | 61.51.99.86       |                         | 61.51.77.66       |
      ----------------------                         ----------------------
            ^                                              ^
            |                                              |
            V port:80                                     V port: 80
      ----------------------                         ----------------------
      | 61.51.202.88    | Internet host          | 61.51.76.102    | Internet host
      ----------------------                         ----------------------

                           图一: NAT 实现了私有IP的计��机分��n几个公网IP地址讉K��Internet的功能�?BR>
随着�|�络的普及，IPv4的局限性暴露出来。公�|�IP地址成�ؓ一�U�稀�~�的资源�Q�此时NAT 的功能局限也暴露出来�Q�同一个公�|�的IP地址�Q�某个时间只能由一台私有IP地址的计��机使用。于是NAPT(The IP Network Address/Port Translator)应运而生�Q�NAPT实现了多台私有IP地址的计��机可以同时通过一个公�|�IP地址来访问Internet的功能。这在很大程度上暂时�~�解了IPv4地址资源的紧张�?BR>
NAPT 负责��某些内�|�IP地址的计��机向外部网�l�发出的TCP/UDP数据包的源IP地址转换为NAPT自己的公�|�的IP地址�Q�源端口转�ؓNAPT自己的一个端口。目的IP地址和端口不�? �q�将IP数据包发�l��\由器�Q�最�l�到辑֤�部的计算机。同时负责将外部的计��机�q�回的IP数据包的目的IP地址转换内网的IP地址�Q�目的端口�{为内�|�计��机的端口，源IP地址和源端口不变�Q��ƈ最�l�送达到内�|�中的计��机�?BR>

            ----------------------                         ----------------------
            | 192.168.0.5       |  Internat host          | 192.168.0.6       |  Internat host
            ----------------------                         ----------------------
                     port: 2809    ^                ^ port: 1827
                                       \                /
                                       v             v
                                    ----------------------
                                    | 192.168.0.1       | NAT device
                                    | 61.51.99.86       |
                                    ----------------------
      map port:9882 to 192.168.0.5:2809 ^             ^ map port: 9881 to 192.168.0.6:1827
                                       /             \
                           port:80 v                v port:80
            ----------------------                         ----------------------
            | 61.51.202.88    | Internet host          | 61.51.76.102    | Internet host
            ----------------------                         ----------------------

                           图二: NAPT 实现了私有IP的计��机分��n一个公�|�IP地址讉K��Internet的功能�?nbsp;

在我们的工作和生�z�M��, NAPT的作用随处可见，�l�大部分公司的网�l�架构，都是通过1至N台支持NAPT的�\由器来实现公司的所有计��机�q�接外部的Internet�|�络的。包括本人在写这��文章的时候，也是在家中��用一台IBM�W�记本通过一台宽带连接的台式机来讉K��Internet的。我们本��文章主要讨论的NAPT的问题�?BR>
NAPT(The IP Network Address/Port Translator) ��Z��ȝ��了P2P软�g的应�?

通过NAPT 上网的特点决定了只能由NAPT内的计算��Z��动向NAPT外部的主机发赯��接，外部的主机想直接和NAPT内的计算机直接徏立连接是不被允许的。IM(��x��通讯)而言�Q�这意味着�׃��NAPT内的计算机和NAPT外的计算机只能通过服务器中转数据来�q�行通讯。对于P2P方式的下载程序而言�Q�意味着NAPT内的计算��Z��能接收到NAPT外部的连接，��D��q�接数用�q�少�Q�下载速度很难上去。因此P2P软�g必须要解决的一个问题就是要能够在一定的�E�度上解决NAPT内的计算��Z��能被外部�q�接的问题�?BR>
NAT(The IP Network Address Translator) �q�行UDP�I�K��的原理是什�?

TCP/IP传输时主要用到TCP和UDP协议。TCP协议是可靠的�Q�面向连接的传输协议。UDP是不可靠的，无连接的协议。根据TCP和UDP协议的实现原理，对于NAPT来进行穿透，主要是指的UDP协议。TCP协议也有可能�Q�但是可行性非常小�Q�要求更高，我们此处不作讨论�Q�如果感兴趣可以到Google上搜索，有些文章对这个问题做了探讨性的描述。下面我们来看看利用UDP协议来穿透NAPT的原理是什�?

                     ----------------------                         ----------------------
                     | 192.168.0.5       |  Internat host          | 192.168.0.6       |  Internat host
                     ----------------------                         ----------------------
                        UDP port: 2809       ^                ^ UDP port: 1827
                                             \                /
                                                v             v
                                             ----------------------
                                             | 192.168.0.1       | NAT device
                                             | 61.51.99.86       |
                                             ----------------------
  Session(192.168.0.6:1827 <-> 61.51.76.102:8098) ^             ^ Session(192.168.0.6:1827 <-> 61.51.76.102:8098)
            map port:9882 to 192.168.0.5:2809 /             \map port: 9881 to 192.168.0.6:1827
                              UDP port:8098 v                v UDP port:8098
                     ----------------------                         ----------------------
                     | 61.51.202.88    | Internet host          | 61.51.76.102    | Internet host
                     ----------------------                         ----------------------


                                    图三: NAPT 是如何将�U�有IP地址的UDP数据包与公网��L��q�行透明传输的�?BR>
UDP协议包经NAPT透明传输的说�?

NAPT为每一个Session分配一个NAPT自己的端口号�Q�依据此端口��h��判断��收到的公网IP��L��q�回的TCP/IP数据包�{发给那台内网IP地址的计��机。在�q�里Session是虚拟的�Q�UDP通讯�q�不需要徏立连接，但是对于NAPT而言�Q�的��要有一个Session的概念存在。NAPT对于UDP协议包的透明传输面��的一个重要的问题��是如何处理�q�个虚拟的Session。我们都知道TCP�q�接的Session以SYN包开始，以FIN包结束，NAPT可以很容易的获取到TCP Session的生命周期，�q�进行处理。但是对于UDP而言�Q�就�ȝ��了，NAPT�q�不知道转发出去的UDP协议包是否到达了目的��L��Q�也没有办法知道。而且鉴于UDP协议的特点，可靠很差�Q�因此NAPT必须强制�l�持Session的存在，以便�{�待��外部送回来的数据�q��{发给曄��发�v��h��的内�|�IP地址的计��机。NAPT具体如何处理UDP Session的超时呢�Q�不同的厂商提供的设备对于NAPT的实��C��q�相同，也许几分钟，也许几个��时�Q�些NAPT的实现还会根据设备的忙碌状态进行智能计��超时时间的长短�?BR>
               [192.168.0.6:1827]
                        | UDP Packet[src ip:192.168.0.6 src port:1827 dst ip:61.51.76.102 dst port 8098]
                        v
      [pub ip: 61.51.99.86]NAT[priv ip: 192.168.0.1]
                        | UDP Packet[src ip:61.51.99.86 src port:9881 dst ip:61.51.76.102 dst port 8098]
                        v
               [61.51.76.102:8098]

                                 囑֛�: NAPT ��内部发出的UDP协议包的源地址和源端口改变传输�l�公�|�IP��L��?BR>

               [192.168.0.6:1827]
                        ^
                        | UDP Packet[src ip:61.51.76.102 src port:8098 dst ip:192.168.0.6 dst port 1827]
      [pub ip: 61.51.99.86]NAT[priv ip: 192.168.0.1]
                        ^
                        | UDP Packet[src ip:61.51.76.102 src port:8098 dst ip:61.51.99.86 dst port 9881]
               [61.51.76.102:8098]

                                 图五: NAPT ��收到的公网IP��L��q�回的UDP协议包的目的地址和目的端口改变传输给内网IP计算机�?nbsp;
现在我们大概明白了NAPT如何实现内网计算机和外网��L��间的透明通讯。现在来看一下我们最兛_��的问题，��是NAPT是依据什么策略来判断是否要�ؓ一个请求发出的UDP数据包徏立Session的呢�Q�主要有一下几个策�?

A. 源地址(内网IP地址)不同�Q�忽略其它因�? 在NAPT上肯定对应不同的Session
B. 源地址(内网IP地址)相同�Q�源端口不同�Q�忽略其它的因素�Q�则在NAPT上也肯定对应不同的Session
C. 源地址(内网IP地址)相同�Q�源端口相同�Q�目的地址(公网IP地址)相同�Q�目的端口不同，则在NAPT上肯定对应同一个Session
D. 源地址(内网IP地址)相同�Q�源端口相同�Q�目的地址(公网IP地址)不同�Q�忽略目的端口，则在NAPT上是如何处理Session的呢�Q?BR>
D的情冉|��式我们关心和要讨论的问题。依据目的地址(公网IP地址)对于Session的徏立的军_��方式我们��NAPT讑֤�划分��Z��大类:

Symmetric NAPT:
对于到同一个IP地址�Q��Q意端口的�q�接分配使用同一个Session; 对于��C��同的IP地址, ��L��端口的连接��用不同的Session.
我们�U�此�U�NAPT�?Symmetric NAPT. 也就是只要本地绑定的UDP端口相同�Q?发出的目的IP地址不同�Q�则会徏立不同的Session.

      [202.223.98.78:9696] [202.223.98.78:9696] [202.223.98.78:9696]
            ^             ^                      ^
            |             |                      |
            v             v                      v
            9883          9882                   9881
                              |
                           \ [NAT] /
                              ^
                              |
                              v
                        [192.168.0.6:1827]

                        囑օ�: Symmetric 的英文意思是对称。多个端口对应多个主机，�q��的，对称�?

Cone NAPT:
对于到同一个IP地址�Q��Q意端口的�q�接分配使用同一个Session; 对于��C��同的IP地址�Q��Q意端口的�q�接也��用同一个Session.
我们�U�此�U�NAPT�?Cone NAPT. 也就是只要本地绑定的UDP端口相同�Q?发出的目的地址不管是否相同�Q?都��用同一个Session.

      [202.223.98.78:9696] [202.223.98.78:9696] [202.223.98.78:9696]

                     ^       ^       ^
                     \       |       /
                        v       v    v
                              9881
                              [NAT]
                                 ^
                                 |
                                 v
                        [192.168.0.6:1827]

                        图七: Cone 的英文意思是锥。一个端口对应多个主机，是不是像个锥�?

现在�l�大多数的NAPT属于后者，即Cone NAT。本人在��试的过�E�中�Q�只好��用了一台日本的Symmetric NAT。还好不是自��q��买的�Q�我从不买日�? 希望看这��文章的朋友也自觉的不要购买日本的东�ѝ��Win9x/2K/XP/2003�pȝ��自带的NAPT也是属于 Cone NAT的。这是值的庆幸的，因�ؓ我们要做的UDP�I�K��只能在Cone NAT间进行，只要有一��C��是Cone NAT�Q�对不�v�Q�UDP�I�K��没有希望了�Q�服务器转发吧。后面会做详�l�分�?

下面我们再来分析一下NAPT 工作时的一些数据结构，在这里我们将真正说明UDP可以�I�K��Cone NAT的依据。这里描�q�的数据�l�构只是��Z��说明原理�Q�不��h��实际参考�h��|��真正感兴��可以阅读Linux的中关于NAT实现部分的源码。真正的NAT实现也没有利用数据库的，呵呵�Q��ؓ了速度�Q?BR>
Symmetric NAPT 工作时的端口映射数据�l�构如下:

内网信息�?

[NAPT 分配端口] [ 内网IP地址 ] [ 内网端口 ] [ 外网IP地址 ] [ SessionTime 开始时�?]

PRIMARY KEY( [NAPT 分配端口] ) -> 表示依据[NAPT 分配端口]建立主键�Q�必��d��一且徏立烦引，加快查找.
UNIQUE( [ 内网IP地址 ], [ 内网端口 ] ) -> 表示�q�两个字�D�联合�v来不能重�?
UNIQUE( [ 内网IP地址 ], [ 内网端口 ], [ 外网IP地址 ] ) -> 表示�q�三个字�D�联合�v来不能重�?

映射�?

[NAPT 分配端口] [ 外网端口 ]

UNIQUE( [NAPT 分配端口], [ 外网端口 ] ) -> 表示�q�两个字�D�联合�v来不能重�?

Cone NAPT 工作时的端口映射数据�l�构如下:

内网信息�?

[NAPT 分配端口] [ 内网IP地址 ] [ 内网端口 ] [ SessionTime 开始时�?]

PRIMARY KEY( [NAPT 分配端口] ) -> 表示依据[NAPT 分配端口]建立主键�Q�必��d��一且徏立烦引，加快查找.
UNIQUE( [ 内网IP地址 ], [ 内网端口 ] ) -> 表示�q�两个字�D�联合�v来不能重�?

外网信息�?

[ wid 主键标识 ] [ 外网IP地址 ] [ 外网端口 ]

PRIMARY KEY( [ wid 主键标识 ] ) -> 表示依据[ wid 主键标识 ]建立主键�Q�必��d��一且徏立烦引，加快查找.
UNIQUE( [ 外网IP地址 ], [ 外网端口 ] ) -> 表示�q�两个字�D�联合�v来不能重�?

映射�? 实现一对多�Q�的

[NAPT 分配端口] [ wid 主键标识 ]

UNIQUE( [NAPT 分配端口], [ wid 主键标识 ] ) -> 表示�q�两个字�D�联合�v来不能重�?
UNIQUE( [ wid 主键标识 ] ) -> 标识此字�D�不能重�?

看完了上面的数据�l�构是更明白了还是更晕了�Q?呵呵! 多想一会儿��׃��明白了。通过NAT,内网计算��机向外�q�结是很�Ҏ��的，NAPT会自动处理，我们的应用程序根本不必关心它是如何处理的。那么外部的计算机想讉K��内网中的计算机如何实现呢�Q�我们来看一下下面的��程�Q?BR>
c 是一台在NAPT后面的内�|�计��机�Q�s是一台有外网IP地址的计��机。c ��d��?s 发�v�q�接��h��Q�NAPT依据上面描述的规则在自己的数据结构中记录下来�Q�徏立一个Session. 然后 c �?s 之间��可以实现双向的透明的数据传输了。如下面所�C?

c[192.168.0.6:1827] <-> [priv ip: 192.168.0.1]NAPT[pub ip: 61.51.99.86:9881] <-> s[61.51.76.102:8098]

由此可见�Q�一台外�|�IP地址的计��机惛_��NAPT后面的内�|�计��机通讯的条件就是要求NAPT后面的内�|�计��机��d��向外�|�IP地址的计��机发�v一个UDP数据包。外�|�IP地址的计��机利用收到的UDP数据包获取到NAPT的外�|�IP地址和映��的端口�Q�以后就可以和内�|�IP的计��机透明的进行通讯了�?BR>
现在我们再来分析一下我们最兛_��的两个NAPT后面的内�|�计��机如何实现直接通讯�? 两者都无法��d��发出�q�接��h��Q�谁也不知道�Ҏ��的NAPT的公�|�IP地址和NAPT上面映射的端口号。所以我们要靠一个公�|�IP地址的服务器帮助两者来建立�q�接。当两个NAPT后面的内�|�计��机分别�q�接了公�|�IP地址的服务器后，服务器可以从收到的UDP数据包中获取到这两个NAPT讑֤�的公�|�IP地址和这两个�q�接建立的Session的映��端口。两个内�|�计��机可以从服务器上获取到�Ҏ��的NAPT讑֤�公网IP地址和映��的端口了�?BR>
我们假设两个内网计算机分别�ؓA和B�Q�对应的NAPT分别为AN和BN�Q?如果A在获取到B对应的BN的IP地址和映��的端口后，�q�不急待的向�q�个IP
地址和映��的端口发送了个UDP数据包，会有什么情况发生呢�Q�依据上面的原理和数据结构我们会知道�Q�AN会在自己的数据结构中生成一条记录，标识一个新Session的存在。BN在收到数据包后，从自��q��数据�l�构中查询，没有扑ֈ�相关记录�Q�因此将包丢弃。B是个慢性子�Q�此时才慢吞吞的向着AN的IP地址和映��的端口发送了一个UDP数据包，�l�果如何呢？当然是我们期望的�l�构了，AN在收到数据包后，从自��q��数据�l�构中查扑ֈ�了记录，所以将数据包进行处理发送给了A。A 再次向B发送数据包�Ӟ��一切都时畅通无��M��。OK, 大工告成�Q�且慢，�q�时对于Cone NAPT而言�Q�对于Symmetric NAPT呢？呵呵�Q�自己分析一下吧...

NAPT(The IP Network Address/Port Translator) �q�行UDP�I�K��的具体情况分析!

首先明确的将NAPT讑֤�按照上面的说明分�? Symmetric NAPT �?Cone NAPT, Cone NAPT 是我们需要的。Win9x/2K/XP/2003 自带的NAPT也�ؓCone NAPT�?BR>
�W�一�U�情�? 双方都是Symmetric NAPT:

此情况应�l�不存在什么问题，肯定是不支持UDP�I�K��?BR>
�W�二�U�情�? 双方都是Cone NAPT:

此情冉|��我们需要的�Q�可以进行UDP�I�K��?BR>
�W�三�U�情�? 一个是Symmetric NAPT, 一个是Cone NAPT:

此情冉|��较复杂，但我们按照上面的描述和数据机构进行一下分析也很容易就会明白了, 分析如下,

假设: A -> Symmetric NAT, B -> Cone NAT

1. A 惌��?B, A 从服务器那儿获取�?B 的NAT地址和映��端�? A 通知服务器，服务器告�?B A的NAT地址和映��端�? B �?A 发�v�q�接�Q�A 肯定无法接收到。此�?A �?B 发�v�q�接�Q?A 对应的NAT建立了一个新的Session�Q�分配了一个新的映��端口， B �?NAT 接收到UDP包后�Q�在自己的映��表中查询，无法扑ֈ�映射��，因此��包丢弃了�?BR>
2. B 惌��?A, B 从服务器那儿获取�?A 的NAT地址和映��端�? B 通知服务�? 服务器告�?A B的NAT地址和映��端�?A �?B 发�v�q�接, A 对应的NAT建立了一个新的Session�Q�分配了一个新的映��端口B肯定无法接收到。此�?B �?A 发�v�q�接, �׃�� B 无法获取 A 建立的新的Session的映��端口，仍是使用服务器上获取的映��端口进行连接，因此 A 的NAT在接收到UDP包后�Q�在自己的映��表中查询，无法扑ֈ�映射��? 因此��包丢弃了�?BR>
�Ҏ��以上分析�Q�只有当�q�接的两端的NAT都�ؓCone NAT的情况下�Q�才能进行UDP的内�|�穿透互联�?BR>

NAPT(The IP Network Address/Port Translator) �q�行UDP�I�K��如何进行现实的验证和分�?

需要的�|�络�l�构如下:

三个NAT后面的内�|�机器，两个外网服务器。其中两台Cone NAPT�Q�一�?Symmetric NAPT�?BR>
验证�Ҏ��:

可以使用本程序提供的源码�Q�编译，然后分别�q�行服务器程序和客户端。修改过后的源码增加了客��L��之间直接通过IP地址和端口发送消息的命��o�Q�利用此命��o�Q�你可以手动的验证NAPT的穿透情��c��ؓ了方便操作，推荐你��用一个远�E�登陆��Y�Ӟ��可以直接在一台机器上操作所有的相关的计��机�Q�这样很方便�Q�一个�h��可以完成所有的工作了。呵呵，本�h��是�q�么完成的。欢�q�有兴趣和经验的朋友来信批评指正�Q�共同进步�?BR>

爱饭�?/a> 2006-01-12 14:05 发表评论

P2P�q�_��的关键技�?

Thu, 12 Jan 2006 05:57:00 GMT

P2P�Q�Peer-to-Peer�Q�计��是指不同系�l�之间通过直接交换�Q�实现计��机资源和服务共享、进行信息处理的�q�程�Q�这里，资源可以是处理器、缓存和��盘�I�间�{�，服务包括信息交换、数据计��等。P2P模式与传�l�客�?服务器模式的关键区别在于Peer与Peer在通信�q�程中，可以完全摒弃服务器的角色�Q�完成一�U�直接通信�Q�来获得�׃�n资源或服务�?BR>从P2P的发展史来看�Q�Internet的快速发展是P2P�pȝ��崛�v的催化剂�Q�在Internet上进行客�?服务器模式的讉K��Q��得信息源分布�q�于集中�Q�边�~�网�l�的资源被闲�|�和��费�Q�而P2P技术的引入�Q��得网�l�中��M��一个与�|�络相关的设备都可能为网�l�中的其他设备提供有效的内容服务�?BR>一般的P2P�pȝ��都有强烈的应用背景，�pȝ��实现也与应用�c�d��紧密相关。�ؓ了深入分析P2P�pȝ��的关键技术，我们��P2P�pȝ��划分为P2P�q�_��层和应用层，P2P�q�_��包含支撑P2P应用所需的基��l��g�Q�例如，发现机制、通信、安全、资源集成等�l��g。P2P应用层利用P2P�q�_��提供的功能，向用��h��供专门的服务。这�U�区分可界定P2P的关键技术，帮助我们设计和实现更多种�cȝ��P2P应用.
本文主要讨论P2P�q�_��的关键技术，全文按如下方式组�l�：�W?节描�q�C��P2P�pȝ��的特点，�W?节概括了Peer通信的各�U�技术，�W?节叙�q�C��P2P�q�_��的安全措施，�W?节讨��Z��P2P�q�_��的性能问题�Q�最后是全文��结�?BR>1�Q�P2P�pȝ��特点
在P2P�pȝ��中，每一个Peer都是�q�等的参与者，承担服务使用�?/FONT>�?FONT color=#ff0000>服务提供�?/FONT>两个角色。资源的所有权和控制权被分散到�|�络的每一个节点中。服务��用者和服务提供者之间进行直接通信�Q�可充分利用�|�络带宽�Q�减��网�l�的拥塞状况�Q��得资源的有效利用率大大提高（包括各种计算资源和存储资源）。同时由于没有中央节点的集中控制�Q�系�l�的伸羃性较强，也能避免单点故障�Q�提高系�l�的定w��性能�?BR>但由于P2P�|�络的分散性、自��L��、动态性等特点�Q�造成了某些情况下Peer的访问结果是不可预见的。例如，一个请求可能得不到��M��应答消息的反馈。P2P�pȝ��的匿名性等特点可能会带来系�l�的安全漏洞�?BR>P2P�pȝ��的这些特点也军_��了P2P 应用主要包括资源�׃�n和协作。资源共享主要是文�g�׃�n�pȝ��、文件分发系�l�（File Distribution System�Q�。通过P2P�|�络实现文�g�׃�n和文件分发，能够应付爆发式访问，�pȝ��的可伸羃性好�Q�可靠性好�?BR>此类典型�pȝ��?/STRONG>Napster[1]�Q�Gnutella[2]�Q�FreeNet[3]�Q�Chord-based System�Q�BitTorrent[4]�?BR>P2P协作应用的种�c�d��多，包括��x��消息�pȝ��、在�U�游戏、共享企业应用（在提供即时消息之外，�q�可�׃�n内容和进行共同的�z�d��如组内共同开发和�~�辑�Q�、文件搜索、pub/sub�pȝ��{��?BR>其中�Q?STRONG>��x��消息�pȝ��[5]有AOL AIM、Yahoo Messenger、MSN Messenger、Jabber[6,7]�{�；
在线游戏有星际争霸、Net-Z和DOOM�Q?BR>�׃�n企业应用有Groove[8]、Magi[9]�Q?BR>文�g搜烦�?/STRONG>YouSearch[10], OpenCola�{�；
pub/sub�pȝ��有Scribe、Herms�{�；
�q�有��Z��P2P�|�络构造的email�pȝ��?BR>而从P2P�pȝ��的典型特�Ҏ��分析�Q�常常被引证为P2P应用的科学计��系�l?A href="mailto:Seti@Home[11">Seti@Home[11]应该属于P2P的非典型应用。各�U�P2P�pȝ��׃��应用背景的差异，彼此互不兼容�Q�导致不同的P2P�|�络无法通信�Q�难以有效地利用�|�络资源提供服务。Sun公司�l�织开发的JXTA[12]��目�Q�希望通过提供一个简单通用的P2P�q�_��来解册��个问题。从上述应用可以看出�Q�P2P�pȝ��q�不能替代客�?服务器系�l�，它们两者是相辅相成的关�p�R�?BR>从P2P�pȝ��的基本特点和应用情况分析�Q�我们认为P2P�q�_��中的Peer的通信、��^台的安全和��^台的性能优化�q�三��Ҏ��术是P2P�pȝ��的成功与否的关键所在�?BR>
2 P2P通信
P2P通信旉��要解决的最基本的问题即�?STRONG>如何�q�接其它的终端获得信息、资源和服务。该问题可细分�ؓ以下一些问题：
1、P2P�|�络的拓扑结构和Peer节点的功能角色划分；
􀁺 2、资源和服务如何标识�Q?BR>􀁺 3、进行资源查找时如何�q�行Peer定位�Q?BR>􀁺 4、P2P�|�络中Peer节点的动态变化的处理�Q?BR>􀁺 5、如何穿��NAT�Q�Network Address Translation�Q�和防火墙进行Peer节点之间的直接通信�?BR>P2P�|�络的拓扑结构和Peer节点的角色划�?BR>在P2P�|�络中，有两�U�典型的拓扑�l�构�Q�即�U�P2P�|�络和�؜杂的P2P�|�络[13]�?BR>在纯P2P�|�络中，每个Peer都具有同�{�的责�Q和地位，不存在中间节点的协调。FreeNet、Gnutella都属于纯P2P�|�络。而在��h��的P2P�|�络中，存在着充当服务器角色的Peer节点或提供特�D�功能的Super-Peer节点�Q�这些节点保存其它Peer节点的基本状态和存储内容源信息，协助完成对其它节点的记录、查询等工作。Napster, Groove, Magi�{�系�l�均是典型的��h��型P2P�pȝ��?BR>每一个Peer�Ҏ��其提供的角色功能可以划分��Z��U�类型，即简单类型Peer节点�Q�super-peer节点和服务器型的peer节点。简单类型Peer节点仅仅是一个简单的�l�端用户�Q�它可以��h��获得服务�q��ؓ�|�络中的其它Peer提供服务。Super-peer节点除了��h��和简单Peer节点�c�M��的功能外�Q�还提供某些�Ҏ��功能。如JXTA�pȝ��中就存在路由器Peer节点和会聚点Peer节点[12]�Q�前者作��Z��个桥梁，使得被防火墙或NAT隔离的Peer可以�怺�通信�Q�后者�ؓ��单节�Ҏ��供查询定位信息的功能。服务器型的Peer节点主要提供�c�M��与客�?服务器模型下的服务器功能�Q�如提供一个全局�l�一的目录查询。在Napster�q�种��h��型的P2P�pȝ��中，有若�q�个��单Peer节点�怺�提供文�g下蝲功能的服务，�q�有一个目录服务器节点提供文�g条目的注册管理。Groove和Magi�pȝ��中也均存在这��L��服务器型节点。而在�U�P2P�|�络中，每一个Peer节点均充当了上述的三�U�角艌Ӏ?BR>资源的标�?BR>��Z��在P2P�|�络中准��地查找资源�q�行Peer定位�Q�还需要确定Peer中存贮资源的标识�Q�这里我们将在P2P�|�络中需要进行查扄��对象�l�称��源）。不同的应用场景均有适合自��n特点的资源标识方式�?BR>在以文�g�׃�n��Z��的应用中�Q�资源主要以文�g的名�U�、关键字、源数据�{�进行标识。而即时消息通讯�pȝ��往往采用�c�M��于电子邮件的命名方式�Q�如在Jabber�pȝ��中，Jabber的用户ID以[node@]domain/[resource]的�Ş式进行地址标识[7]�Q�提供一个全局�l�一的地址�I�间。其中，Domain是主要的ID标识�Q�是与多个用戯��接进行消息�{发的Jabber Server�Q�Node为用户姓名或�늧��Q�Resource属于一个Node�Q�标识属于一个用��L��多个资源。一个用户可以同时与同一服务器徏立多�ơ连接�?BR>以用户之间协作�ؓ�ȝ��P2P应用如Groove�pȝ��和Magi�pȝ��Q�由于在协作中对��x��消息通讯和文件共享的要求��D��有之，用户一般以用户名进行标识，而文件则以源数据标识[14]�?BR>JXTA作�ؓ一个解决不同P2P应用彼此不兼容的底层�q�_��Q�提��Z��一个统一的资源标识定义，卛_��告[12]
�Q�advertisement�Q�。广告是一个XML�l�构的文档，由Peer或相互协作共同完成一�U�应用Peer �l�进行发布，用来描述现有的资源、服务或实体Peer。Peer节点通过查询�q�告以获得各�U�资源的消息�Q�进行Peer定位�?BR>
Peer的定位方�?/STRONG>
在查找资源的�q�程中，可采用直接或间接方式定位Peer。直接定位Peer的方式比较简单，卛_��用广播或多播的�Ş式发出查询请求，�W�合查询要求的Peer节点�q�行应答�Q�然后徏立直接的通信�q�接。由于这�U�方式只能在局域网中��用，所以应用范围有限。当然这�U�方式可以和其它的定位方式结合��用以获得良好的查询效率�?BR>间接方式包括三种模型�Q�服务器模型、洪��模型、和路由模型�?BR>服务器模型：该模型是��Z��h��型的P2P拓扑�l�构。充当服务器的peer节点提供资源查询。peer��请求发送至服务器获得查询结果，随后�Q�直接与目标节点通信获取所需服务。但�q�种方式存在单点��p�|问题�Q�同�Ӟ��也存在�׾~�性问题。但因�ؓpeer节点仅在启动、停止及查询的时候才与服务器交互�Q�所以此时的伸羃性还是强于客�?服务器模式。典型系�l�有Napster�Q�Magi�Q�Groove和Jabber。Napster�pȝ��采用一个目录服务器记录资源索引�Q�Groove�pȝ��和Magi�pȝ��均是采用动态DNS查找用户的IP地址[14]。Jabber�pȝ��׃��其资源标识类��g��Email地址�Q�所以，利用DNS的MX记录�q�行IP地址的查询[7]�?BR>�z�流模型�Q�该模型��Z��U�P2P拓扑�l�构。Peer节点采用�z�流法将查询��h��不断地�{发至��d��节点�Q�直到到辄��标节点，获得查询�l�果。同时�ؓ了避免消息无限制的�{发，查询��h��中设定有TTL�Q�Time to Live�Q�或HTL(Hops to Live)�q�行转发控制。Gnutella是采用此�c�L��型的典型�pȝ��?BR>路由模型�Q�该模型也是��Z��U�P2P�|�络�l�构。首先�ؓ�|�络中的每一个peer赋予一个ID�Q�同�Ӟ��每个Peer存储的资源和服务也有�c�M��的ID。Peer节点的�\��p��中登��C��定数量的��d��节点。Peer的请求被转发至与所��h��的资源或服务的ID 最接近的Peer�Q�直到发现这个资源或服务[15]。插入一个新资源/服务的过�E�与查询�q�程�c�M��Q�也是通过查找该资�?服务ID来确定存储的正确位置。此�c�L��型主要用在文件共享系�l�中�Q�如FreeNet,Chord[16],CAN[17],Tapestry,Pastry�{��?BR>路由模型又可�l�分为非�l�构化�\由模型和�l�构化�\由模型。FreeNet�pȝ��属于典型的非�l�构化�\由模型。在查找到所需资源后，��Z��提高搜烦性能�Q�系�l�沿搜烦路径复制资源。这��P��׃��资源的存储位�|�不固定�Q�其行�ؓ不易观察�Q�不��定因素较大。所以相对于�l�构化�\由模型来��_��其资源分布的规律性不强，难以从全局上把握整个系�l�的资源分布状况。而结构化路由模型如Chord, CAN, Tapestry, Pastry均采用了DHT(Distributed Hash Table)作�ؓ主要的存储算法。DHT的主要思想是将资源定位用的索引�Q�烦引结构通常是两元组�Q�文件名�Q�实际的存储位置�Q�）分散存储到整个P2P�|�络上，�q�样�Q�哈希表的存储和查询操作��׃��涉及到P2P�|�络中的多个节点�?BR>以DHT思想�q�行路由模型的设计时�Q�首先需要确定通过Hash函数�q�行虚拟地址�I�间映射的规则。虚拟地址�I�间的设计有多种方式�Q?Chord采用的虚拟地址�I�间为m-位的循环地址�I�间[16]�Q�CAN�pȝ��采用的是多维的地址�I�间[17]。Peer节点的IP地址和端口号�l�过哈希函数映射到地址�I�间�Q�再��映��空间进行划分，每个节点负责存储属于自己�I�间的值对(key,value)。其�ơ需要确定�\��p��的存储内容�Q�即��d��节点的规模，以适应于不同的�|�络需求。这里需要对路由表项的规模与�|�络搜烦跌��{数进行综合考虑。在动态性较强的�|�络中，节点频繁加入和退出网�l�会使得规模较大的�\��p��更新频率�q�高�Q�操作费时。但规模较小的�\��p��在进行资源定位时�Q�又使得查找旉��q�长。再�ơ是��定在接收到一个资源的查询��h��Ӟ��从�\��p��中选择转发的邻居节点的规则。最后要��定新节点的插入和删除操作后�Q�虚拟的地址�I�间如何�q�行分裂和合�q��?BR>
P2P�|�络中节点的��d��和退�?/STRONG>
在服务器模型的P2P�|�络中，�׃��Peer节点的状态信息和��理的资源信息直接记录在服务器中�Q�Peer节点的登录和退��Z��需和服务器�q�行交互�Q�由服务器进行协调处理。如在Napster�pȝ��中，Peer节点��d��pȝ��后，向服务器发送当前的�|�络状态和所有的文�g列表信息�Q�由服务器更新目录烦引。在Jabber�{�即时消息通讯�pȝ��中，Peer节点往往是与用户�l�定的。服务器接收到用��L��d��消息或退出消息后�Q�通知订阅
该用户在�U�状态的所有在�U�用戗��?BR>非结构化路由模型FreeNet中，新节炚w��先需要获知网�l�中的若�q�可�q�接节点的信息，通过执行搜烦操作向整个网�l�宣布自��q��存在。在�l�构化�\由模型的P2P�|�络中，节点的登录和退出，��导致虚拟地址�I�间的分裂和合�ƈ。Peer节点��d��|�络的操作，�c�M��于一个资源的查找�q�程。Peer节点定位到所属的地址�I�间后，��地址�I�间以一定规则进行分裂。负责管理该地址�I�间资源的原节点��所属资源按分裂的规则，部分转移到新节点。同时两个节点的路由表项和其它相兌��点的路由表项均要�q�行修改。而Peer节点退出网�l�的�q�程�Q�则是登录网�l�的逆过�E�，资源需要�{�U�d��qӞ��相关节点的�\��p��同样需要更新�?BR>
防火墙和NAT的穿��?/STRONG>
在实际的�|�络通信中，Peer节点往往是一个私有网�l�中的节点，位于防火墙之后。这��P��Peer与Peer之间直接通信需要解决的一个关键问题是�I�越防火墙和NAT。由于防火墙会对IP�q�行�q��o�Q�限制了墙内外的�q�接�Q�而NAT技术虽然可以��得内部网�l�地址映射到外部网�l�地址�Q�但要求内部�|�络首先发�v对外�q�接�Q�否则外部网�l�机器无法达到内部网�l�[12]。穿��防火墙和NAT的策略有两个基本点：
�Q?�Q?需要��用在一般情况下可以通过防火墙的协议�Q�如��Z��h��/应答方式的HTTP协议�?BR>�Q?�Q?Peer之间�q�行通信�Ӟ��必须由内部网�l�的机器首先发�v�q�接��h��Q�如果通信双方均处于防火墙之后�Q�则需要有防火墙外的�{发节点进行消息�{发�?BR>在Napster�pȝ��中当Peer节点��h��下蝲的资源位于一个防火墙之后的节点上�Q�请求节点向服务器端发送需要进行�{换下载的��h�� (Alternate download request)�Q�由服务器通知被请求节炚w��先发��h��件下载的�q�接��h��。而Gnutella是在��查询的详细信息�q�回�l�请求者的同时发送资源文�Ӟ��以此方式解决文�g提供者位于防火墙之后的情��c�?BR>JXTA�q�_��中，其super-peer节点中的路由节点是提供防火墙和NAT�I�越功能的特�D�节炏V��若通信一方在防火墙之后，那么单向�I�越的过�E�由试图与防火墙后的peer A�q�接的peer节点B发�v�Q�节点B首先与�\由Peer�q�接�Q�同时peer A周期性地�q�接路由 Peer�Q�由于�\�?Peer对Peer A是可见的�Q�且不在防火墙后�Q�连接请求消息可作�ؓhttp的应�{�内容返回至peer A。若通信的双斚w��在防火墙之后�Q�那么需要两个�\�?peer。Peer1 通过路由节点1 转发消息�Q��\��p��?��消息�{发至路由节点 2�Q�Peer2周期性地向�\��p��?发送http��h��Q�获得消息后断开�q�接。JXTA�q�_��中�\��p��点的使用不仅可以�I�越防火墙，�q�可以解决瓶颈问题，解决�|�络传输的不兼容性[12]�?BR>3�Q�P2P�q�_��的安全机�?/STRONG>
与安全有紧密关系的是P2P�q�_��提供的匿名性�?BR>��Z��q�行自由的交互，避免引�v不必要的法律�U�纷�Q�所以，P2P�pȝ��允许匿名方式的信息交换[15]。匿名性可分�ؓ以下三种�c�d��Q?BR>􀁺 发布者匿名：发布者匿名地发布服务或资�?BR>􀁺 ��h��者匿名：��h��方匿名地��h��服务或资�?BR>􀁺 服务提供者匿名：P2P�|�络中的资源拥有者匿名地提供资源或服�?BR>提供匿名性的基本�Ҏ��有六�U�：
􀁺 �l�播�Q�采用IP�l�播�Ҏ��q�行资源发送可以达到请求者匿名的目的。但是这�U�方法需要底层网�l�如以太�|�的支持�?BR>􀁺 地址�ƺ骗�Q��用面向无�q�接协议如UDP�Q�可以更改地址�Q�达到地址�ƺ骗的目的�?BR>􀁺 �w�䆾�ƺ骗�Q�网�l�中的文件可能拥有多个备份，所以应�{�者往往�q�不是文件的提供者，如FreeNet��׃��用了�q�种�Ҏ��提供匿名性�?BR>􀁺 隐藏路径�Q�Peer之间�q�不是进行直接的消息通信�Q�而是通过若干的中间节点，�q�样可以辑ֈ�发送者匿名的要求�?BR>􀁺 别名�Q�每一个Peer在网�l�中均有一个别名，Peer之间通过别名�q�行消息传递，�q�种�Ҏ��需要一
个Proxy Server保存所有的Peer实体与别名的对应关系�?BR>􀁺 强制存放�Q�一个文件存攄��位置是由文�g本��n��定的，发布者无法选择�Q�从而实现发布者匿名，如基于Chord的系�l��?BR>上述�Ҏ��可以�l�合应用�Q�例如，FreeNet采用�U�P2P�|�络中的非结构化文档路由模型�Q�同时在发布文�g和查找文件的�q�程中，沿搜索�\径复制文件。通过隐藏路径和��n份欺骗的�Ҏ��辑ֈ�服务提供者匿名的目的�Q�通过隐藏路径的方法�Ş成请求者匿名，同时�׃��文�g的发布是一个根据文件名强制存放的过�E�，所以也完成了发布者匿名的功能�?BR>P2P�q�_��所��h��的上�q�特性可能会带来下列安全隐患�Q?/STRONG>
􀁺 拒绝服务��d��Q�P2P应用会消耗网�l�带宽，占用��盘�I�间�Q��得系�l�性能降低甚至完全瘫痪。如果被大量恶意��C��用，��׃��出现正常服务��h��得不到服务的现象。处理这�U�攻�ȝ��隄��在于如何��恶意节点和真正负蝲�q�重的节点区分开。从�Ҏ��上说�Q�限制网�l�服务请求的数量是解��x��l�服务攻�ȝ��Ҏ��Ҏ��。合理选择�|�络底层的拓扑结构，均衡�pȝ��中的负蝲和资源，加入��量控制�{�略�Q�这三种措施�l�合使用可��恶意节点�Ҏ��无法占用�q�多的资源，降低其对�pȝ��的媄响�?BR>􀁺 恶意软�g分发�Q�P2P无中央服务器控制�Q�允许匿名分发资源，对��Y件的分发�~�Z��控制�Q�如果P2P�pȝ��被恶意��用，会给�pȝ��用户带来安全隐患。通常的名誉评估系�l�可以用来跟�t�和处理Peer的状态，�q�根据得到的信息选择资源的提供者。但是这�U�方法比较消耗网�l�资源�?BR>􀁺 信息泄露和篡改：例如�Q�有些P2P�pȝ��在�\��p��中保存了一批网�l�地址�Q�这些信息可能会被泄露和��改�Q�有些P2P�pȝ��例如Napster、Gnutella允许直接讉K��用户��盘�Q�恶意用户可利用�q�个�Ҏ��察看和��改��盘信息。这些都需要有相应的策略加以解冻I��例如�Q�设计安全�\��q��略，可解册��\��p��信息泄露问题�?BR>4�Q�P2P�q�_��的性能改善技�?/STRONG>
P2P�q�_��的性能指标包括��h��响应旉��、公�q�x��等�?BR>��h��响应旉��与P2P�q�_��的拓扑结构有很大关系。对于有中央服务器的P2P�pȝ��如Napster�pȝ��?A href="mailto:Seti@Home">Seti@Home�pȝ��Q�Peer之间由服务器�q�行协调�Q�服务器变成了系�l�的瓉��Q�媄响系�l�性能。�ؓ了改善性能�Q�可采用层次性的��h��式结构，由每一个协调者负责一个Peer�l�，形成一个层�ơ的��理�l�构。在非集中式的P2P�|�络中，主要通过消息转发来获取和查询数据�Q�消息�{发的�ơ数影响带宽的消耗，因此要尽量减��消息的转发�ơ数[15]。采用复制的�Ҏ��可提供多个资源备份，提高定w��性，也减��了��h��节点到服务节点的距离�Q�减��了��h��响应旉��。但复制会带来数据一致性的问题�Q�另一�U�减��消息�{发次数的�Ҏ��是徏立智能�\由和�|�络�l�织�Q�寻扄��标文件到��h��节点的最��\径。该�c�L��法包括：在基于DHT的结构化路由模型中设计合乎应用背景要求的路由表存储结构，以减��网�l�中的消息蟩转数�Q�采用一些反馈机�Ӟ��地选择曄��命中�q�的Peer节点�q�行消息转发�Q�监��网�l�中的运行状态，�l�过一些负载较重的Peer节点。这些方法都可以�Ҏ��不同的��用背景获得较好的性能提升�?BR>除了通过复制改善�pȝ��的响应时间之外，�~�存的替换策略对响应旉��改善也有很大影响。SmallWorld模型�ȝ��了网�l�通信中的一个有��的特征�Q�在规则�|�络中随机地��d��量通�\�Q�能很好减短通信距离�Q�减��请求的响应旉��Q�它被用来改�q�FreeNet中的�~�存替换�{�略�Q�也获得了较好的性能改善[18]�?BR>P2P体系�l�构使得P2P�pȝ��中会出现“无政府��M��”行为，例如�Q�过量下载或有意让下载的文�g中包含广告等�Q�这些行为导致P2P信息交换的不公��^性。在P2P�|�络中，为避免每一个Peer享受服务而不提供服务的现象，需要实行一定的��理机制。在P2P�|�络中引入经��学中买卖交易的原理�Q�可以促�q�资源的�׃�n和交互。Stanford大学的P2P研究��组提出了RTR(right-to-respond)协议[19]�Q�用以解军_��z�流模型中，中间节点不愿消耗资源�{发请求的问题。RTR是指�Ҏ��询请求的响应权，Peer节点可以购买和出售系�l�中每个查询��h��的RTR。当某一Peer节点转发��h��Ӟ��其它Peer节点可以向其购买RTR。购��C��RTR的Peer节点可以执行两个操作�Q�一是响应该��h��Q�如果被��h��的发��选中�Q�就可以为其提供服务�q�收取费用；二是再将RTR售出�l�其它节炏V��通过�q�种�Ҏ��Q�Peer节点在经��利益的�׃��下会不断转发��h��Q�扩大搜索范围。同时可
以促�q�拥有类��D��源或服务的Peer节点频繁联系�Q��Ş成Peer Group�Q�提高搜索效率�?BR>另一个利用经��学原理的实例是数据交易(data trading)�Ҏ��的引入[20]。P2P�pȝ��l�常采用数据备䆾的机制来增强资源可用性，提高�pȝ��性能。而用户往往不愿无偿提供存储资源备䆾其它数据。这时利用数据交易的�Ҏ��提供�怺�备䆾�Q�即获得�Ҏ��存储�I�间或数据资源是以向�Ҏ��提供存储�I�间为前提的。系�l�中Peer节点之间建立了良好的�怺�备䆾关系�Q�将会减��搜索和讉K��的开销。以上这些实例均表明�Q�采用经��学中以交易为基��的资源管理机�Ӟ��可以提高P2P�pȝ��的资源��用率�?BR>5�Q�小�l?BR>P2P计算�Q�作为分布式计算的一个分支，目前不论是从技术研�I�还是��品开发来看，都已成�ؓ了一个重要的领域。P2P的算法、��^台和应用都将有进一步的发展�I�间。P2P的思想也被�q�泛地应用在很多其他的研�I��域。本文着重介�l�了P2P的发展背景、P2P�pȝ��的特点，在P2P�q�_��层识别出若干P2P�q�_��的关键技术，包括Peer的通信技术、P2P�q�_��的安全机制和P2P�q�_��的性能改善技术，�q�些技术的�ȝ��和分析能对设计和实现P2P�q�_��和应用�v��C��定的借鉴和指��g��用�?BR>参考文献：
[1] Napster Inc.http://www.naspter.com
[2] Gnutella,http://www.gnutelliums.com
[3] Freenet,http://freenetproject.org/lang/en
[4] BitTorrent, http://bitconjurer.org/BitTorrent/
[5] Sixto Ortiz Jr., "Instant Messaging: No Longer Just Chat", IEEE Computer,March 2001
[6] Jeremie Miller, "Jabber, Peer-to-Peer:Harnessing the Power Of Disruptive Technologies,�?O'Reilly, March 2001
[7] Peter Saint-Andre, “Jabber Technology Overview�?BR>[8] Preeti Mehra,Groove,16th November,2001,ECE-579
[9] Gregory Alan Bolcer,Michael Gorlick,”Peer-to-Peer Architectures and the Magi Open-Source Infrastructure�? Endeavors Technology ,2000
[10] Mayank Bawa,Roberto J.Bayardo Jr.,Sridhar Rajagopalan,Eugene J.Shekita, “Make it Fresh,Make it Quick�Q�Searching a Network of Personal Webservers�?BR>[11] Seti@Home, http://setiathome.ssl.berkeley.edu/
[12] Jxta Book,http://www.brendonwilson.com/projects/jxta
[13] Siu Man Lui, Sai Ho Kwok, “Interoperablility of Peer-To-Peer File Sharing Protocols�?ACM SIGecom Exchanges,Vol.2,No.2,August 2002
[14] Dana Moore,John Hebeler, 苏忠,战晓��L��? 《对�{�网》，清华大学出版�C?2003.2
[15] Dejan S.Milojicic,Vana Kalogeraki Rajan Lukose,Kiran Nagaraja,Jim Pruyne,Bruno Richard,Sami Rollins,Zhichen Xu,HP Laboratories Palo Alto,�?Peer-to-Peer Computing�?University of California
[16] Ion Stoica,Robert Morris,Divid Liben-Nowell,David R.Karger,M.Grans Kaashoek,Frank Dabek,Hari Balakrishnan. ”Chord: A scalable Peer-to-peer Lookup Protocol for Internet Applications�?BR>[17] S.Ratnasamy,P,Francis, M. Handley, R.Karp,and S.Shenker,”A Scalable Content-Addressable Network�?ACM SIGCOMM �?1,San Diego,CA,USA,2001
[18] Hui Zhang, Ashish Goel and Ramesh Govindan. Using the Small-World Model to Improve Freenet Performance. IEEE Infocom, 2002.
[19] B.Yang,S.Kamvar,and H.Garcia-Molina Addressing the non-cooperation problem in competitive P2P systems.Stanford University Database Group Technical Report,2003
[20] Mayank Bawa,Brian F.Cooper,Arturo Crespo. Peer-to-Peer Research at Stanford,Stanford

爱饭�?/a> 2006-01-12 13:57 发表评论

中文字幕日本人妻久久久免费,久久影视综合亚洲,精品久久久久久亚洲

P2P communication across middleboxes�Q�前�a����）

P2P之UDP�I�K��NAT的原理与实现 - 增强��?附修改过的源代码)

P2P�q�_��的关键技�?

P2P communication across middleboxes�Q�前�a��）