对于UDP：一种是Cone NAT，简单说就是NAT每次分配给内网的端口是一样的，即使连接不同的主机，NAT上的端口还是不变（除非过期）。类似这样的NAT或防火墙，已经有比较可靠的解决方法：Peer-to-Peer (P2P) communication across middleboxes
另外一种是Symmetric NAT，对于这种NAT，内网连接不同的其他主机，NAT分配给它的是不同的端口。这种情况下，使用上面的方法就已经无效了。可能的办法就是猜测NAT下次将要分配的端口，也有算法可以比较准确得猜测到端口：Symmetric NAT Traversal using STUN
虽然还是没有办法完全猜对，但也是一种办法。我已经用实现Cone NAT，因为考虑到现在大部分的NAT不是Symmetric的，因此，就不去考虑Symmetric的实现了，也许日后有时间可以考虑。
对于TCP，也有办法： Establishing TCP Connections Between Hosts Behind NATs
TCP现在还没用上，估计很快就要用到了。
这里总结一下UDP穿透NAT：
对于Cone NAT，是这样的情况：
Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235
| |
| |
+----------------------+----------------------+
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 155.99.25.11:62000 v | v 155.99.25.11:62000 v
|
Cone NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
|
Client A
10.0.0.1:1234
下面是Symmetric NAT
Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235
| |
| |
+----------------------+----------------------+
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 155.99.25.11:62000 v | v 155.99.25.11:62001 v
|
Symmetric NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
v 10.0.0.1:1234 v | v 10.0.0.1:1234 v
|
Client A
10.0.0.1:1234
我实现的是Cone NAT，所有就说说Cone NAT：
Server S
|
|
+----------------------+----------------------+
| |
NAT A（NAip:NAport) NAT B(NBip:NBport)
| |
| |
Client A Client B
假设上图中的NATA和NATB都是Cone NAT。
现在ClientA要向ClientB发送数据（比如文件），首先ClientA和B分别通过他们的NATA和B在ServerS上登记，ServerS记录他们NAT的IP和端口号（因为是NAT和ServerS通信的，所以ServerS能也只能得到NAT的地址和端口号）。现在ClientA通过NATA告诉ServerS说要传文件给Client，ServerS就把ClientA的NATA的IP和端口号发送给NATB（因为B的NAT端口已经在ServerS上有记录了），ClientB收到后发送连接数据给NATA，这个时候NATA是不会接受ClientB发过来的包的，因为ClientA没有连接过B，NATA就不会接受B的数据了。虽然B连接A不成功，但是B已经连接过A了，NATB记住了，这时B告诉ServerS叫A过来连，A收到命令后连接B就成功了，于是建立连接，后面的传输就成功了！
整个过程如下：
ClientA-->NATA-->ServerS(A在S登记NAip:NAport)
ClientB-->NATB-->ServerS (B在S登记NBip:NBport)
ClientA-->NATA-->ServerS(A告诉S，要发数据给B)
ServerS-->NATB-->ClinetB(S把NAip:NAport发给B，并告诉B，A要发数据给你了)
ClientB-->NATB-->NATA(NAip:NAport)-->Dropped-->ClientA (B发的包别NATA丢掉了，A是收不到了)
ClientB-->NATB-->ServerS(B等不到A的回应，就告诉S，叫A过来连我吧)
ServerS-->NATA-->ClinetA(S把NBip:NBport发给A，并告诉A，B连不到你，你连B吧)
ClientA-->NATA-->NATB(NBip:NBport)-->ClinetB(B收到A的连接请求，要发送应答给A)
ClientB-->NATB-->NATA-->ClientA(A收到B的应答，后面可以发送数据给NBip:NBport了)
ClientA-->NATA-->NATB-->ClientB(现在开始就从这条路发数据了)
……
一般防火墙原理：
防火墙的设置分未界内根界外，就像以前使用的AtGuard，如果设置界内，就是对从外面发起的连接进行检测，如果规则设置阻挡，那么从外面访问进来的连接就被阻挡。但是，这不是说这样单方面的通信，很多人对这个不清楚，以为防火墙都不让外面进来了，那文件是怎么传的？其实，如果从里面发起连接，然后外面就可以连接进来了。虽然我没有关于防火墙确切的资料，但根据我的掌握的理论，我想我的推理是正确的。先由里面发起连接对方的请求，防火墙就会记住这个信息（也许是建立了一个session，一定时间内会释放或过期），对方收到请求，反过来连接防火墙是允许的。所以，对于上面的NAT原理，当然是可以用于一般的防火墙，而且更简单，因为得到的“NAT”的IP和端口都是本机的。
实现：
NAT信息的获取和发送：
理论上解决了，实现这个就简单了。本来做这个就是因为自己的客户端JBQ的需要，因此直接在JBQ客户端上面做。而服务器（用于p2p的服务器另外写）。原来的JBQ消息和文件都是通过服务器中转，现在就是把文件这部分改成p2p。
按照上面的原理，发送方需要把自己在NAT上的地址信息发送给接受方，然后由接受方向发送方连接，这样就可以在接受方的防火墙上面开个session，以让发送方进行后面的连接。但接受方连接不成功的时候，把自己的NAT信息再通过服务器发送给发送发送方，然后发送方再次连接接受方，于是建立连接。这里用到的服务器有两个，一个用来发送NAT信息，还有一个用来获取NAT信息。
本来这个两个应该是用同一个服务器，但是我们有原来的聊天服务器，因此，发送NAT信息的任务就交给聊天服务器，现在只要完成获取NAT信息的服务器就可以了。不管是Tcp还是UDP，连接双方都可以直接得到对方得IP和端口，因为只要由需要自己的NAT信息的客户端向p2p服务器发一个消息，p2p把跟它连接的客户端使用的NAT信息发回给客户端就可以。客户端收到p2p服务器发回来的消息以后，就可以把这个消息通过聊天服务器发给对方。
其他的握手和连接通过上面的理论都可以比较容易的写出来。
存在的问题：这种方法只适用于Cone NAT，对于 Symmetric NAT还需要通过猜测端口。
另外，同样不适用于TCP，因为TCP的三次握手在这样的连接中必定失败。但也可以通过一点的办法解决，这个上面提到过。
总结：总的来说，上面用的方法可以解决的这一类NAT（防火墙的问题），可以让都处于NAT或防火墙后面的双方直接连接。上面的实现解决了我的JBQ客户端里面的一系列问题，视频等都已经在这个基础上实现p2p了。
[table=98%][tr][td] 正文：
先介绍一下需要穿透的对象。英文的词很会打马虎眼，叫做 middlebox，直译为中间盒。主要就是两种：防火墙和 NAT设备。物理设备有时侯是合二为一的。
防火墙
防火墙用于限制公网和私网之间的通信，一般是丢弃未经认证的报文。防火墙不会修改报文的 IP地址和 TCP/UDP端口信息。
NAT设备
检查过往报文，并且修改包头地址 /端口信息。
P2P的大量应用改变了互联网的规则，比如说流量模型 2-8改为 5-5。根本就在于 P2P强调了端到端的直接联接。而现有的网络模式是按照 C-S的模式构建的。因此，开展 P2P应用，就不可避免的遇到了许多问题（另文总结），穿透 NAT只是其中的一个。
1. UDP 打洞
用的比较广泛的技术之一： UDP打洞技术。
本技术的限制，其一，依赖于具体的防火墙；其二，只能是 UDP的穿透。
具体的做法分几种情况：
（ 1）
A要和 B建立直接的 UDP连接：
A如果直接向 B的公网地址 138.76.29.7:31000发送 UDP连接请求， NAT B会直接丢弃这个请求报文。 对于向内的请求， NAT 会直接丢弃。没办法了？
我们注意到一般 NAT还有一个特性。
假设 Client B成功地连接过 server 18.181.0.31:1234，则 NAT B对于源地址为 18.181.0.31:1234的请求报文，则不会丢弃。
完整的连接过程为：
1) A向 B的公网地址 138.76.29.7:31000发送 UDP连接请求è NAT A 为①打开一条通路；
2) A同时通过 server S 向 B发出请求，要求 B向 A的公网地址 155.99.25.11:62000发送 UDP连接请求è NAT B为②打开一条通路；
3) 双向通路打开， client A和 client B可以直接通信了。
这个过程中，还是需要具有公网地址的 server在中间的。一旦 client A 和 client B能够直接通信后，双方就能为其它 client端充当 server的角色了。估计 SKYPE也是大量地使用了这种方式。
（ 2）
和（ 1）的通信过程基本一样。只不过双方在通过 server为中继进行连接时， NAT设备“看”到通信的双方都是内网用户，所以就使双方进行直接通信。
这个过程叫做“ loopback translation”。 NAT设备要支持这个功能才行。
（ 3）多层 NAT转换。叙述起来太麻烦，道理基本相同，感兴趣可以自己钻研。
说明：使用 UDP打洞技术的限制在于 NAT设备必须能够保持端口绑定。即—— [ 私有 IP ，私有 UDP 端口 ]对和 [ 公网 IP ，公网 UDP 端口 ]对的一一对应。国内现在用的 NAT设备基本都满足这一要求。
2. TCP 穿透
其实核心思想还是一样：就是解决一个对内连接的问题。如果对内连接在 NAT看来是一个已经激活的连接（根据就是 IP地址：端口号），则对内的连接就会放行。
（ 1）同步连接方式
详细过程：
Client A发送一个TCP SYN 包给 Client B，我们把这个SYN包叫做 SYN A,包含的信息如下：
SrcAddress：10.0.0.1 Tcp port ：1234
DestAddress：138.76.29.7 Tcp port：310000
同时，Client B发送一个TCP SYN包给Client A，我们把这个包叫做 SYN B,包含的信息如下：
SrcAddress：10.1.1.3 Tcp port ：1234
DestAddress：155.99.25.11 Tcp port：620000
SYN A首先通过NAT A（必须在SYN B到达NAT A之前），NAT A看到这个包并将其地址信息进行转换为：
SrcAddress：155.99.25.11 Tcp port ：620000
DestAddress：138.76.29.7 Tcp port：310000
我们把这个经过 NAT A转换的包叫做 SYN A’
同样， SYN B首先通过NAT B（也必须在SYN A到达NAT B之前），NAT B看到这个包并进行地址转换为：
SrcAddress：138.76.29.7 Tcp port：310000
DestAddress：155.99.25.11 Tcp port ：620000
我们把这个经过NAT B转换的包叫做 SYN B’
这时，NAT A和NAT B都在自己的TCP连接表中存储了含有上面两个公网IP地址和端口信息，因此，只要看到包含这两个信息的SYN包，都会让其通过。
就在这个瞬间， SYN A’到达了NAT B，NAT B检查了一下 SYN A’，发现它的地址信息和自己TCP连接表中的信息相符，便让 SYN A’通过了，并将 SYN A’的地址信息转换为：我们称这个包为 SYN A’’
SrcAddress：155.99.25.11 Tcp port ：620000
DestAddress：10.1.1.3 Tcp port：1234
以使这个包能够到达内部网中Client B上
也就在这个瞬间， SYN B’到达了NAT A，NAT A检查了一下 SYN B’，发现它的地址信息和自己TCP连接表中的信息相符，便让 SYN B’通过了，并将 SYN B’的地址信息转换为：我们称这个包为 SYN B’’
SrcAddress：138.76.29.7 Tcp port ：310000
DestAddress：10.0.0.1 Tcp port：1234
以使这个包能够到达内部网中Client A上
这时，Client A收到了 SYN B’’，Client B收到了 SYN A’’，并返回给对方ACK，经过三次握手，这个P2P的TCP连接就建立了。
（2）异步连接方式另文叙述。
[/td][/tr][tr][td]-- 作者：admin
-- 发布时间：2006-2-8 21:13:00
-- communication across middleboxes（术语篇）
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，以尊重译者的劳动成果！
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.
在这一章节中，首先概要的介绍一下“代理”技术的一些术语。然后集中讨论两种造成P2P应用问题的代理机制。
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.
防火墙
防火墙限制了私网与公网的通信，它主要是将（防火墙）认为未经授权的的包丢弃，防火墙只是检验包的数据，并不修改数据包中的IP地址和TCP/UDP端口信息。
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:
网络地址转换（ NAT ）
当有数据包通过时，网络地址转换器不仅检查包的信息，还要将包头中的IP地址和端口信息进行修改。以使得处于NAT之后的机器共享几个仅有的公网IP地址（通常是一个）。网络地址转换器主要有两种类型：
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 将私网主机的私有IP地址转换成公网IP地址，但并不将TCP/UDP端口信息进行转换。基础NAT一般用在当NAT拥有很多公网IP地址的时候，它将公网IP地址与内部主机进行绑定，使得外部可以用公网IP地址访问内部主机。（译者注：实际上是只将IP转换，192.168.0.23 <-> 210.42.106.35,这与直接设置IP地址为公网IP还是有一定区别的，特别是对于企业来说，外部的信息都要经过统一防火墙才能到达内部，但是内部主机又可以使用公网IP）
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.
网络地址和端口转换 （ NAPT ）
这是最普遍的情况，网络地址/端口转换器检查、修改包的IP地址和TCP/UDP端口信息，这样，更多的内部主机就可以同时使用一个公网IP地址。
请参考[NAT-TRAD]和[NAT-TERM]两个文档了解更多的NAT分类和术语信息。另外，关于NAPT的分类和术语，[STUN]在最近做了更多的定义。当一个内部网主机通过NAT打开一个“外出”的TCP或UDP会话时，NAPT分配给这个会话一个公网IP和端口，用来接收外网的响应的数据包，并经过转换通知内部网的主机。这样做的效果是，NAPT在 [私有IP:私有端口] 和[公网IP:公网端口]之间建立了一个端口绑定。
端口绑定指定了NAPT将在这个会话的生存期内进行地址转换任务。这中间存在一个这样的问题，如果P2P应用程序从内部网络的一个[私有IP地址:端口]对同时发出多条会话给不同的外网主机，那么NAT会怎样处理呢？请看以下几种方案。
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
（译者注：为什么叫做锥形呢？请看以下图形,终端和外部服务器，都通过NAT分派的这个绑定地址对来传送信息，就象一个漏斗一样，筛选并传递信息）
当建立了一个 [私有IP:端口]-[公网IP:端口] 端口绑定之后，对于来自同一个[私有IP:端口]会话，锥形NAT服务器允许发起会话的应用程序 重复使用这个端口绑定，一直到这个会话结束才解除（端口绑定）。
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（元组）, 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.
例如，假设 Client A（IP地址信息如上图所示）通过一个 锥形NAT 同时发起两个外出的连接，它使用同一个内部端口（10.0.0.1:1234）给公网的两台不同的服务器，S1和S2。锥形NAT 只分配一个公网IP和端口（155.99.25.11:62000）给这个两个会话，通过地址转换可以 确保 Client使用端口的“同一性”（译者注：即这个Client只使用这个端口）。而基础NATs和防火墙却不能修改经过的数据包端口号，它们可以看作是锥形NAT的精简版本。
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，与Cone NAT是大不相同的，并不对会话进行端口绑定，而是分配一个全新的 公网端口 给每一个新的会话。
还是上面那个例子：如果 Client A (10.0.0.1:1234)同时发起两个 "外出" 会话,分别发往S1和S2。对称Nat会分配公共地址155.99.25.11:62000给Session1，然后分配另一个不同的公共地址155.99.25.11:62001给Session2。对称Nat能够区别两个不同的会话并进行地址转换，因为在 Session1 和 Session2中的外部地址是不同的，正是因为这样，Client端的应用程序就迷失在这个地址转换边界线了，因为这个应用程序每发出一个会话都会使用一个新的端口，无法保障只使用同一个端口了。
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通信中， （到底是使用同一个端口，还是分配不同的端口给同一个应用程序），锥形NAT和对称NAT各有各的理由。当然锥形NAT在根据如何公平地将NAT接受的连接直达一个已创建的地址对上有更多的分类。这个分类一般应用在Udp通信（而不是Tcp通信上），因为NATs和防火墙阻止了试图无条件传入的TCP连接，除非明确设置NAT不这样做。这些分类如下：
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
当内部主机发出一个“外出”的连接会话，就会创建了一个 公网/私网 地址，一旦这个地址对被创建，全双工锥形NAT会接收随后任何外部端口传入这个公共端口地址的通信。因此，全双工锥形NAT有时候又被称为"混杂"NAT。
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会对传入的数据包进行筛选，当内部主机发出“外出”的会话时，NAT会记录这个外部主机的IP地址信息，所以，也只有这些有记录的外部IP地址，能够将信息传入到NAT内部，受限制的锥形NAT 有效的给防火墙提炼了筛选包的原则——即限定只给那些已知的外部地址“传入”信息到NAT内部。
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，与受限制的锥形NAT不同的是：它同时记录了外部主机的IP地址和端口信息，端口受限制的锥形NAT给内部节点提供了同一级别的保护，在维持端口“同一性”过程中，将会丢弃对称NAT传回的信息。
Finally, in this document we define new terms for classifying the P2P-relevant behavior of middleboxes:
最后，在这篇文档里我们将定义一组新的术语 ，以便更好的对P2P代理相关的行为进行分类。
P2P 应用程序
P2P应用程序是指，在已有的一个公共服务器的基础上，并分别利用自己的私有地址或者公有地址（或者两者兼备）来建立一个端到端的会话通信。
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应用程序进行通信的代理机制
P2P-firewall
A P2P-firewall is a P2P-Middlebox that provides firewall functionality but performs no address translation.
P2P 防火墙
P2P防火墙是一个提供了防火墙的功能的P2P代理，但是不进行地址转换.
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代理必须具有 锥形NAT对Udp通信支持的功能,并允许应用程序利用Udp打洞技术建立强健的P2P连接。
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的私网内部机器想通过公共地址来访问同一台局域网内的机器的时，NAT设备等价于做了两次NAT的事情，在包到达目标机器之前，先将私有地址转换为公网地址，然后再将公网地址转换回私有地址。我们把具有上叙转换功能的NAT设备叫做“回环转换”设备。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=177793
[/td][/tr][tr][td]-- 作者：admin
-- 发布时间：2006-2-8 21:15:00
-- P2P) communication across middleboxes（前言篇）
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，以尊重译者的劳动成果！
随着IPv6时代的到来，我也一直怀疑，是不是还有必要再去学习 NAT技术——因为网络的资源不再如 IPv4时代匮乏，而 NAT技术正是为解决 IP地址的紧缺而存在的，如此， NAT便没有存在的必要了。
但是，随着这篇文章的翻译，我的怀疑慢慢变成庆幸，渐而又变为肯定，通过翻译所学到的东西，不再仅仅是翻译第一手资料带来的成就感，更多的是通过翻译，去领悟技术前辈们的智慧与经验，也通过翻译，养成自己从第一手资料获得信息的习惯，从而将视野放得更宽，让理解更为透彻——至少，很多东西都是要经过仔细斟酌才真正转化为自己思想的一部分的。正是如此，我才坚定的要把这篇文章翻译完，也如之前所提到的，如果时间允许的话，我会用C#来写一些例子，让大家更好的理解NAT技术，掌握NAT技术（主要涉及到即时通讯、文件对等传输和语音应用三个方面）。
这篇文章主要是介绍一下“代理”机制的起因以及给P2P应用带来的不便，不需要任何基础知识：）
1. Introduction
1、简介
关键词：
middleboxe(s) —— 我翻译成“代理”，也许有更好的翻译
host —— 我翻译成“主机”，希望大家不要理解成服务器了，主机就是一台普通的终端机
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中，普遍存在使用“代理”设备来进行网络地址转换（NAT），导致这种现象的原因是 IPV4 地址空间的资源耗尽危机。虽然不对称 asymmetric 的地址分配和连通性制度已经在代理中被定义，但是却给端对端应用程序和协议制定造成了一些特殊的问题。像电话会议和多媒体网络游戏。这些问题即使在IPV6世界中还是会存在，因为NAT作为IPV4的一种兼容性机制经常被使用[NAT-PT]，并且防火墙将仍然将普遍存在，即使不再需要NAT技术。
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 administrator. 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 结构设计的，为了实现那些需要连接但是又没有固定IP地址的客户端能够连接到一台配置好的拥有固定IP和DNS域名的服务器。
大多数的“代理”使用一种 asymmetric 通信模型，即 私网（局域网） 的主机能发起一个“外出”连接去连接公网上的主机。 但是公网上的主机却无法发送信息给私网上的主机（除非对“代理”进行特殊的配置），NAPT（网络地址端口转换）的普通情况是，一个私网客户端不需要一个公网的固定的IP地址，但是必须要共享一个由NAPT控制的公网的固定IP地址（当然这个NAPT是处于同一个私网内部的）。这样的话，这些匿名的并且看起来难以触及的藏在NAT之后的内网主机对于像 Web 浏览器 这种软件来说就不是一个问题,因为内网的主机只需要发起向外部的连接就可以了。这样一来，无法触及也还是有他的优点的——那就是具有保密性。
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 administration 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的应用中，Internet上的“客户机”之间是需要建立一个通信会话直连的。邀请者和响应者也许会处于不同的NAT之后，也许他们都没有固定IP或者即使有也不是公网的IP地址。举例来说，在一个普通的网络游戏体系结构中，都是通过客户端向一个具有公网固定IP的服务器发起申请进行初始化并通过验证的。同时，客户端之间也要建立直连，才使网络间传输的速度加快，保证数据即时更新（不然抢不到装备啊，呵呵）。
同样的，一个文件共享应用程序也必须通过到一个服务器上去查找它想要的资源，然后再到拥有这个数据的主机上去下载（BT网站，走了一个中介），“代理”造成了很多P2P直连的问题，因为藏在“代理”之后的的主机通常没有固定的端口来使其他的客户端发起的TCP或UDP连接能够最终到达。
RFC 3235[NAT-APPL] 简要的提到了这个问题，但是没有给出任何的解决方案。
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.
在这篇文章中，我们用两种方式讨论 P2P/代理 的问题。首先，概要的讲叙已有的P2P应用程序能够在现有的代理机制中的工作原理。然后，我们提供一组应用程序设计指南，基于已有的实践，在现有的配置好的代理上，来使得P2P应用程序操作更加有条理。最后，我们提供了设计指南，为以后的代理机制能够更方便支持P2P应用程序。讨论的焦点是如何 直接的、广泛的 配置那些需要经过“代理”的P2P应用程序。
下一章节将介绍 学术术语
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=159761
[/td][/tr][tr][td]-- 作者：admin
-- 发布时间：2006-2-8 21:16:00
-- communication across middleboxes（翻译4）
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.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应用程序想要与其他外部客户端进行通话，就无法重复使用已经建立好的通信转换。
伴随着 cone NAT 的推广，“UDP打洞技术”也被越来越广泛的应用。然而，仍存在一小部分使用 symmetric NAT 的网络，那么在这小部分网络环境中，就不能使用“UDP打洞技术”。
（注：因为我国的国情，网络技术应用得比较晚，所以可以说绝大部分的网络都是cone NAT，所以 UDP打洞技术基本上可以畅通无阻的使用，只是还要注意对NAT是否支持“loopback translation”的测试）
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=108878
[/td][/tr][tr][td]-- 作者：admin
-- 发布时间：2006-2-8 21:17:00
-- communication across middleboxes（翻译5）
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，以尊重译者的劳动成果！
注：在看这篇文章之前，读者需要了解TCP的基础知识，了解TCP建立连接的基本步骤
3.5. Simultaneous TCP open 同时开放 TCP 连接
There is a method that can be used in some cases to establish direct peer-to-peer TCP connections between a pair of nodes that are both behind existing middleboxes. Most TCP sessions start with one endpoint sending a SYN packet, to which the other party responds with a SYN-ACK packet. It is possible and legal, however, for two endpoints to start a TCP session by simultaneously sending each other SYN packets, to which each party subsequently responds with a separate ACK. This procedure is known as a "simultaneous open."
这里有一种方法能够在某种情况下建立一个穿透NAT的端对端TCP直连。我们知道，绝大多数的TCP会话的建立，都是通过一端先发送一个SYN包开始，另一方则回发一个SYN-ACK包的过程。然而，这里确实存在另外一种情况，就是P2P的双方各自同时地发出一个SYN包到对方的公网地址上，然后各自都单独地返回一个ACK响应来建立一个TCP会话，这个过程被称之为：“Simultaneous open”（“同时开放连接”）。
If a middlebox receives a TCP SYN packet from outside the private network attempting to initiate an incoming TCP connection, the middlebox will normally reject the connection attempt by either dropping the SYN packet or sending back a TCP RST (connection reset) packet. If, however, the SYN packet arrives with source and destination addresses and port numbers that correspond to a TCP session that the middlebox believes is already active, then the middlebox will allow the packet to pass through. In particular, if the middlebox has just recently seen and transmitted an outgoing SYN packet with the same addresses and port numbers, then it will consider the session active and allow the incoming SYN through.
If clients A and B can each correctly predict the public port number that its respective middlebox will assign the next outgoing TCP connection, and if each client initiates an outgoing TCP connection with the other client timed so that each client/'s outgoing SYN passes through its local middlebox before either SYN reaches the opposite middlebox, then a working peer-to-peer TCP connection will result.
如果一个NAT接收到一个来自私有网络外面的 TCP SYN 包，这个包想发起一个“引入”的 TCP 连接，一般来说，NAT会拒绝这个连接请求并扔掉这个SYN 包，或者回送一个TCP RST（connection reset，重建连接）包给请求方。但是，有一种情况，当这个接收到的 SYN 包 中的源IP地址和端口、目标IP地址和端口都与NAT登记的一个已经激活的TCP会话中的地址信息相符时，NAT将会放行这个SYN 包，让它进入NAT内部。特别要指出，如果NAT恰好看到一个刚刚发送出去的一个SYN包也和上面接收到的SYN包中的地址信息相符合的话，那么NAT将会认为这个TCP连接已经被激活，并将允许这个方向的SYN包进入NAT内部。
如果 Client A 和 Client B 能够彼此正确的预知对方的NAT将会给下一个TCP连接分配的公网TCP端口，并且两个客户端能够同时地发起一个“外出”的TCP连接，并在对方的 SYN 包到达之前，自己刚发送出去的SYN包都能顺利的穿过自己的NAT的话，一条端对端的TCP连接就成功地建立了。
（好似一个间谍活动
Unfortunately, this trick may be even more fragile and timing-sensitive than the UDP port number prediction trick described above. First, unless both middleboxes are simple firewalls or implement cone NAT behavior on their TCP traffic, all the same things can go wrong with each side/'s attempt to predict the public port numbers that the respective NATs will assign to the new sessions. In addition, if either client/'s SYN arrives at the opposite middlebox too quickly, then the remote middlebox may reject the SYN with a RST packet, causing the local middlebox in turn to close the new session and make future SYN retransmission attempts using the same port numbers futile. Finally, even though support for simultaneous open is technically a mandatory part of the TCP specification [TCP], it is not implemented correctly in some common operating systems. For this reason, this trick is likewise mentioned here only for historical reasons; it is NOT recommended for use by applications. Applications that require efficient, direct peer-to-peer communication over existing NATs should use UDP.
不幸的是，这个诡计比3.4节所讲的UDP端口预言更容易被粉碎，并且对时间的敏感性的依赖更多！ 首先，除非双方的NAT都是Simple firewalls 或者都像cone NAT那样处理TCP通信，否则两个客户端还是无法建立这个TCP直连，因为它们无法预知对方的NAT会分配给新的会话的端口号是多少。 另外，如果双方的 SYN 到达对方的NAT 速度太快（举例来说，就是SYN A的还未穿过NAT A时，SYN B已经提早到达了NAT A），对方的NAT会将这个SYN扔掉，并返回一个 RST 包，这样就使得这个发快了的一方NAT关闭原来的会话，又重新建立一个新的会话，再利用这个新的会话重发一个SYN，这时端口预言就失效了，因为再次分配到相同的端口地址的几率太小了。
最后，尽管在“TCP规范”中说明了“Simultaneous open”是一种支持的标准技术，但是在一些公共操作系统中，对这种技术的支持并不好。基于这个原因，我们也在这里郑重申明，并不推荐使用这个技术。如果您的应用程序想要穿透NAT并进行高效率高性能的P2P的通信，应该使用UDP技术！
这里我将这个技术的详细过程描述如下，欢迎大家指正：
Client A发送一个TCP SYN 包给 Client B，我们把这个SYN包叫做 SYN A,包含的信息如下：
SrcAddress：10.0.0.1 Tcp port ：1234
DestAddress：138.76.29.7 Tcp port：310000
同时，Client B发送一个TCP SYN包给Client A，我们把这个包叫做 SYN B,包含的信息如下：
SrcAddress：10.1.1.3 Tcp port ：1234
DestAddress：155.99.25.11 Tcp port：620000
SYN A首先通过NAT A（必须在SYN B到达NAT A之前），NAT A看到这个包并将其地址信息进行转换为：
SrcAddress：155.99.25.11 Tcp port ：620000
DestAddress：138.76.29.7 Tcp port：310000
我们把这个经过 NAT A转换的包叫做 SYN A’
同样， SYN B首先通过NAT B（也必须在SYN A到达NAT B之前），NAT B看到这个包并进行地址转换为：
SrcAddress：138.76.29.7 Tcp port：310000
DestAddress：155.99.25.11 Tcp port ：620000
我们把这个经过NAT B转换的包叫做 SYN B’
这时，NAT A和NAT B都在自己的TCP连接表中存储了含有上面两个公网IP地址和端口信息，因此，只要看到包含这两个信息的SYN包，都会让其通过。
就在这个瞬间， SYN A’到达了NAT B，NAT B检查了一下 SYN A’，发现它的地址信息和自己TCP连接表中的信息相符，便让 SYN A’通过了，并将 SYN A’的地址信息转换为：我们称这个包为 SYN A’’
SrcAddress：155.99.25.11 Tcp port ：620000
DestAddress：10.1.1.3 Tcp port：1234
以使这个包能够到达内部网中Client B上
也就在这个瞬间， SYN B’到达了NAT A，NAT A检查了一下 SYN B’，发现它的地址信息和自己TCP连接表中的信息相符，便让 SYN B’通过了，并将 SYN B’的地址信息转换为：我们称这个包为 SYN B’’
SrcAddress：138.76.29.7 Tcp port ：310000
DestAddress：10.0.0.1 Tcp port：1234
以使这个包能够到达内部网中Client A上
这时，Client A收到了 SYN B’’，Client B收到了 SYN A’’，并返回给对方ACK，经过三次握手，这个P2P的TCP连接就建立了。
[/td][/tr][tr][td]-- 作者：admin
-- 发布时间：2006-2-8 21:18:00
--
FW的解决方案
作者：吴伟 2004年12月24日 14:03 来源:中国电信网
1 引言
目前NGN（软交换）技术已逐步从试验走向商用，在应用过程中遇到了很多实际问题，特别是NGN用户的接入问题。NGN是一个基于分组网承载的网络，用户接入都是通过IP地址来寻址的。由于IP地址紧缺以及安全等各种原因，所以大量的企业网和驻地网都采用私有IP地址通过出口的NAT/FW接入公网。
NGN网络最大的好处就是能为用户提供丰富的业务，特别是为企业用户提供语音、数据、视频融合的IP Centrex业务，但是像H.323、SIP、MGCP、H.248等在IP上承载语音和视频的协议的控制通道/媒体通道难以穿越传统的NAT/FW设备与公网进行互通，或者说目前的NAT/FW大多只是支持HTTP的数据应用协议穿透，而无法支持这种会话型业务的控制与媒体的NAT/FW穿透，因此私网穿越问题的解决显得更加迫切，成为目前NGN网络业务开展的最大障碍。目前，解决这一问题的主要方案有ALG、STUN、MidCom和Proxy等。
2 穿越技术介绍
2.1 ALG方案
NAT和NAPT只能对IP报文的头部地址和TCP/UDP头部的端口信息进行转换，对于报文的数据部分可能包含IP地址或端口信息的特殊协议（如H.323、SIP、MGCP等），则无法实现有效的转换，这就可能导致问题发生。例如，一个使用内部IP地址的FTP服务器可能在和外网主机建立会话的过程中需要将自己的IP地址发送给对方，而这个地址信息是放在IP报文的数据部分，NAT无法对它进行转换，当外网主机接收到这个私有地址并使用它，这时FTP服务器将表现为不可达。
解决这些特殊协议的NAT转换问题的一个方法就是在NAT实现中采用ALG（Application Level Gateway，应用级网关）功能。ALG是能够识别指定IP协议（如H.323、SIP或MGCP）的设备。它通过与NAT交互以建立状态，使用NAT的状态信息来改变封装在IP报文数据部分中的特定数据，并完成其他必需的工作以使应用协议可以跨越不同范围运行。例如，一个“目的站点不可达”的ICMP报文，该报文数据部分包含了造成错误的数据报A的首部（注意，NAT在发送A之前进行了地址转换，所以源地址不是内部主机的真实地址）。如果开启了ICMP ALG功能，在NAT转发ICMP报文之前，它将与NAT交互，打开ICMP报文并转换其数据部分的报文A首部的地址，使这些地址表现为内部主机的确切地址形式，并完成其他一些必需工作后，由NAT降这个ICMP报文转发出去。
ALG可以是单独的连接于外网和内网之间的设备，也可以是内置于NAT内的插件。ALG典型的组网方式如图1所示。
ALG是支持NCN应用最简单的方式，但由于目前网络中已大量部署了不支持NCN业务应用的NAT/FW设备，因此不推荐采用这种方式，理由如下：
（1）目前网上大量的NAT/FW设备因不具备ALG能力而需要更换或升级；
（2）NGN业务的ALG生产厂商少，没有一套产品特性需求基线；
（3）NAT/FW设备厂商一般不是IP业务领域的专业厂商，难以支持业务的变化（如SIP的扩展多种多样）；
（4）用户普遍希望运营商在不改变已有网络设备（NAT）的情况下就可以提供新的IP业务，用户不愿意重新购买NAT/FW设备，更无法判断各种ALG的可行性。
2.2 MidCom方案
MidCom（Middlebox Communications）方案是通过在第三方实体和FW/NAT之间建立中间盒来通信，使FW/NAT设备变为可控的一种新的概念。如图2所示，MidCom包括MidCom Agent和Middlebox，Agent通过MidCom协议通知Middlebox建立相应的NAT映射表项。
一般情况下，Middlebox集成在NAT或FW设备中，Agent可在软交换、代理服务器或终端上实现。
由于应用业务识别的智能从Middlebox移到外部的MidCom Agent上，因此，根据MidCom的架构，在不需要更改Middlebox基本特性的基础上，通过对MidCom Agent的升级就可以支持更多的新业务。这是相对于NAT/ALG方式的一个很大的优势。
从安全性考虑，MidCom方式支持控制报文和媒体流的加密，因此安全性比较高。
2.3 协议修改
由于目前的多媒体应用协议无法穿越NAT/FW，因此可以考虑通过修改协议以适应NAT/FW。
对于H.323，SIP，MGCP，H.248等协议，为支持NAT/FW穿越而做的修改尚未形成标准，还在起步研究阶段，因此本文不做详细探讨。
2.4 STUN方案
STUN（Simple Traversal of UDP Through NATs）是由IETF研制的一种UDP流协议穿透NAT的协议。如图3所示，位于内部网络的STUN client（NAT内）通过UDP发送请求STUN消息给外部网络的STUN Server（NAT外），STUN Server收到请求消息后产生响应消息（响应消息中携带请求消息的源端口，即STUN Client在NAT上对应的外部端口），响应消息通过NAT发送给STUN Client，STUN Client通过响应消息体中的内容得知其在NAT上对应的外部地址，然后将该地址填入以后的呼叫协议的UDP负载中，并且告知对端，本端的RTP接收地址和端口号为NAT外的地址和端口号。由于通过STUN协议已在NAT上预先建立媒体流的NAT映射表项，因此媒体流可顺利穿越NAT。
需要注意的是，终端设备需要集成STUN Client功能，STUN Server可以集成在相应的应用所属的部件上（如在NGN应用中可以集成到SoftSwtich上）或者是由独立的设备提供。
STUN协议最大的优点是无需现有NAT/FW设备做任何改动。目前，网络中已有大量的NAT/FW，而且这些NAT/FW并不支持VoIP应用。如果采用MidCom或NAT/ALG方式，则需要替换现有的NAT/FW，实施起来难度较大，且MidCom方式无法实现对多级NAT的有效控制。如果采用STUN方式，不但无需改动NAT/FW，而且能够很好地适应多个NAT串联的网络环境。
但STUN也有以下几个方面的局限性：
（1）需要应用程序支持STUN Client的功能，即NGN的网络终端需具备STUN Client功能；
（2）STUN不支持TCP连接的穿越，也就表示不支持H.323协议；
（3）STUN方案不支持NGN业务对FW的穿越，不能穿越对称NAT（Symmetric NAT）类型（在安全性要求较高的企业网中，出口NAT通常就是采用这种类型）。
2.5 Proxy方案
Proxy方案是指通过对私网内用户呼叫的信令和媒体同时做Relay来实现出口NAT/FW的穿越。对于NGN网络的私网穿越问题，目前业界已基本倾向Proxy方式，并且在Proxy方案中还增加了网络安全、防止终端漫游等特性。
Proxy设备是在原来网络结构的基础上，采用网络叠加方式，部署在IP网络的边缘或汇聚层，是会话信令和媒体的聚合点。信令Proxy与媒体Proxy可以在一个设备上实现，也可以分离实现，当在同一个设备上实现时称为Full Proxy。NGN终端通过Proxy设备连接到软交换上，如图4所示。
在网络中，信令Proxy和媒体Proxy各自担负着不同的工作。
（1）信令Proxy：Proxy设备对NCN用户而言，可看作是软交换系统，即用户的注册和呼叫消息都会发给Proxy设备，Proxy设备经过信令处理后再转发给软交换系统。同时，Proxy设备对软交换系统又可看作是用户，软交换系统首先将呼叫被叫的请求发给Proxy设备，Proxy设备经过信令处理后再转发给真正的被叫用户。Proxy设备通过对信令进行处理和分析，得到本次会话的地址变换状况、带宽需求等信息，并根据当前网络资源占用情况等信息来决定媒体流是否通过Full Proxy设备网关，从而起到网络保护、防止带宽盗用等作用。
（2）媒体Proxy：Proxy设备是媒体流的必经之处，所有域内用户与外界互通的媒体流都经过Proxy设备进行处理和转发。Proxy设备网关首先检查报文的合法性，并根据信令处理结果来制定媒体流转发策略（如FW、QoS和地址转换策略），通过指定内网/外网用户RTP流的接收地址和端口这种方式来确保无论采用何种组网方案，媒体流都能得到正确转发和严格的QoS保证、安全控制。
Full Proxy方式由于不用对运营商和客户端的现有网络设备进行任何会话型业务用户改造，具有很强的适应性，组网灵活，可满足NGN初期多样化的组网和用户接入。除了解决NAT问题外，功能还可以大大扩展，同时可在接入层实现对会话业务QoS和安全的处理，可以发展成为NGN网络的用户接入平台。 [/td][/tr][tr][td]-- 作者：admin
-- 发布时间：2006-2-8 21:18:00
-- 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. Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=331289
[/td][/tr][tr][td]-- 作者：admin
-- 发布时间：2006-2-8 21:19:00
-- P2P) communication across middleboxes（翻译7）
Copyright (C) The Internet Society (2003).? All Rights Reserved.
原文版权：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，以尊重译者的劳动成果！
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方式支持控制报文和媒体流的加密，因此安全性比较高。 Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=332104
[/td][/tr][tr][td]-- 作者：admin
-- 发布时间：2006-2-8 21:23:00
-- 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.3. UDP hole punching UDP 打洞技术
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.
第三种技术，也是这篇文章主要要研究的，就是非常有名的“UDP打洞技术”，UDP打洞技术依赖于由公共防火墙和cone NAT，允许适当的有计划的端对端应用程序通过NAT“打洞”，即使当双方的主机都处于NAT之后。这种技术在 RFC3027 的5.1节[NAT PROT] 中进行了重点介绍，并且在Internet[KEGEL]中进行了非正式的描叙，还应用到了最新的一些协议，例如[TEREDO,ICE]协议中。不过，我们要注意的是，“术”如其名，UDP打洞技术的可靠性全都要依赖于UDP。
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.
这里将考虑两种典型场景，来介绍连接的双方应用程序如何按照计划的进行通信的，第一种场景，我们假设两个客户端都处于不同的NAT之后；第二种场景，我们假设两个客户端都处于同一个NAT之后，但是它们彼此都不知道(他们在同一个NAT中)。
3.3.1. Peers behind different NATs 处于不同NAT之后的客户端通信
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 都拥有自己的私有IP地址，并且都处在不同的NAT之后，端对端的程序运行于 CLIENT A,CLIENT B,S之间，并且它们都开放了UDP端口1234。 CLIENT A和CLIENT B首先分别与S建立通信会话，这时NAT A把它自己的UDP端口62000分配给CLIENT A与S的会话，NAT B也把自己的UDP端口31000分配给CLIENT B与S的会话。如下图所示：
Now suppose that client A wants to establish a UDP communication session directly with client B.? If A simply starts sending UDP messages to B/'s public address, 138.76.29.7:31000, then NAT B will typically discard these incoming messages (unless it is a full cone NAT), because the source address and port number does not match those of S, with which the original outgoing session was established. Similarly, if B simply starts sending UDP messages to A/'s public address, then NAT A will typically discard these messages.
假如这个时候 CLIENT A 想与 CLIENT B建立一条UDP通信直连，如果 CLIENT A只是简单的发送一个UDP信息到CLIENT B的公网地址138.76.29.7:31000的话，NAT B会不加考虑的将这个信息丢弃（除非NAT B是一个 full cone NAT），因为 这个UDP信息中所包含的地址信息，与CLIENT B和服务器S建立连接时存储在NAT B中的服务器S的地址信息不符。同样的，CLIENT B如果做同样的事情，发送的UDP信息也会被 NAT A 丢弃。
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 的公网地址上，与此同时，他又通过S中转发送了一个邀请信息给CLIENT B，请求CLIENT B也给CLIENT A发送一个UDP信息到 CLIENT A的公网地址上。这时CLIENT A向CLIENT B的公网IP(138.76.29.7:31000)发送的信息导致 NAT A 打开一个处于 CLIENT A的私有地址和CLIENT B的公网地址之间的新的通信会话，与此同时，NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公网地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对方打开了，CLIENT A和CLIENT B之间就可以直接通信，而无需S来牵线搭桥了。 ( 这就是所谓的打洞技术)！
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打洞技术有很多实用的地方：第一，一旦这种处于NAT之后的端对端的直连建立之后，连接的双方可以轮流担任 对方的“媒人”，把对方介绍给其他的客户端，这样就极大的降低了服务器S的工作量；第二，应用程序不用关心这个NAT是属于cone还是symmetric，即便要，如果连接的双方有一方或者双方都恰好不处于NAT之后，基于上叙的步骤，他们之间还是可以建立很好的通信通道；第三，打洞技术能够自动运作在多重NAT之后，不论连接的双方经过多少层NAT才到达Internet，都可以进行通信。
译后小记：本来已经翻译好了，是在网文快捕中翻译的，结果，一个全选把所有翻译的内容全部删除了(网文快捕的Bug?：)，不得不痛苦的再翻一遍。不过，有失必有得，第二次翻译流畅多了，希望大家读来还顺口。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=102387
[/td][/tr][tr][td]-- 作者：admin
-- 发布时间：2006-2-8 21:24:00
-- P2P) communication across middleboxes（翻译1）
将陆续翻译 Peer-to-Peer (P2P) communication across middleboxes 这篇文章,并没有按照章节次序来，请读者见谅。 原文版权：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.4. UDP port number prediction UPD 端口号预言
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:
让我们来考虑这样一种情况，有两个客户端 A 和 B，他们都藏在不同的NAT后面，他们都开放了一个UDP连接给具有固定IP的Server S：如下图
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，用来保持 客户端A 与 服务器S 的通信会话， NAT B 也分配了31000端口，用来保持 客户端B 与 服务器S 的通信会话。通过与 服务器S的对话，客户端A 和 客户端B 都相互知道了对方所映射的真实IP和端口。
客户端A发送一条UDP消息到 138.76.29.7:31001(请注意到端口号的增加)，同时 客户端B发送一条UDP消息到 155.99.25.11:62001。如果NAT A 和NAT B继续分配端口给新的会话，并且从A-S和B-S的会话时间消耗得并不多的话，那么一条处于客户端A和客户端B之间的双向会话通道就建立了。
客户端A发出的消息送达B导致了NAT A打开了一个新的会话，并且我们希望 NAT A将会指派62001端口给这个新的会话，因为62001是继62000后，NAT会自动指派给 从服务器S到客户端A之间的新会话的端口号；类似的，客户端B发出的消息送达A导致了 NAT B打开了一个新的会话，并且我们希望 NAT B 将会指派31001这个端口给新的会话；如果两个客户端都正确的猜测到了对方新会话被指派的端口号，那么这个 客户端A－客户端B的双向连接就被打通了。其结果如下图所示：
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.
明显的，有许多因素会导致这个方法失败：如果这个预言的新端口（62001和31001） 恰好已经被一个不相关的会话所使用，那么NAT就会跳过这个端口号，这个连接就会宣告失败；如果两个NAT有时或者总是不按照顺序来生成新的端口号，那么这个方法也是行不通的。
如果隐藏在NAT A后的一个不同的客户端X（或者在NAT B后）打开了一个新的“外出”UDP 连接，并且无论这个连接的目的如何；只要这个动作发生在 客户端A 建立了与服务器S 的连接之后，客户端A 与 客户端B 建立连接之前；那么这个无关的客户端X 就会趁人不备地“偷” 到这个我们渴望分配的端口。所以，这个方法变得如此脆弱而且不堪一击，只要任何一个NAT方包含以上碰到的问题，这个方法都不会奏效。
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.
自从使用这种方法来实践P2P的应用程序以来,在处于 cone NAT 系列的网络环境中这个方法还是实用的；如果有一方为 cone NAT 而另外一方为 symmetric NAT，那么应用程序就应该预先发现另外一方的 NAT 是什么类型，再做出正确的行为来处理通信，这样就增大了算法的复杂度，并且降低了在真实网络环境中的普适性。
最后，如果P2P的一方处在两级或者两级以上的NAT下面，并且这些NATs 接近这个客户端是 symmetric的话， 端口号预言 是无效的！
因此，并不推荐使用这个方法来写新的P2P应用程序，这也是历史的经验和教训！
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=100193
扫一扫
303
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
