**
原文版权： Copyright (C) The Internet Society (2003). ? All Rights Reserved.
原文地址： http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
**
** 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 想与 C LIENT 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?：)，不得不痛苦的再翻一遍。不过，有得必有失，第二次翻译流畅多了，希望大家读来还顺口。