《【2017年整理】点对点UDP连接(UDP hole punching)》由会员分享，可在线阅读，更多相关《【2017年整理】点对点UDP连接(UDP hole punching)（4页珍藏版）》请在金锄头文库上搜索。
1、点对点 UDP 连接（UDP hole punching）2006-08-04 09:02以下文章为整理，感谢各位网络技术高人。点对点 UDP 连接UDP hole punching当两个需要通讯的主机可能都在 middlebox 后面的时候，UDP hole punching 依赖于 cone NAT 和普通防火墙的一些特性，允许合适的 P2P 应用程序以punch holes方式通过 middlebox 并且建立彼此之间直接的连接。这种技术在 RFC 3027NAT- PORT的 5.1 节中简要的提及，并且在英特网KEGEL非证实的提到，也在最近的一些协议TEREDO, ICE中用到。正
2、如名字中的所提到的，这种技术只能用于 UDP 连接。我们将会考虑两个特别情况，并且考虑应用程序如何完善的处理两者之间的握手连接。第一种情况下，也是较为普通的情况，两个在不通的 NAT 后面的客户端要求直接的进行 P2P 连接。第二种情况，两台客户端位于同一个 NAT 后面，但不能肯定(两台客户端位于同一个 NAT 后面)。1、位于不同 NAT 后面(Peers behind different NATs)假设客户端 A 和 B 都有自己的私有 IP 地址，也都位于不同的 NAT 后面。P2P 应用程序在 A、B 和服务器 S 上运行，用的都是 UDP 端口 1234。A 和 B 各自和服务器
3、S 建立 UDP 通讯连接，使 NAT A为 A 的连接分配一个自己的公共端口 62000，而 NAT B 为 B 的连接分配的是 31000 端口。Server S18.181.0.31:1234|+-+-+| |NAT A NAT B155.99.25.11:62000 138.76.29.7:31000| | |Client A Client B10.0.0.1:1234 10.1.1.3:1234现在推想一下，客户端 A 想要直接和 B 建立一个 UDP 通讯会话。假设 A 简单的发一个 UDP 信息包到 B 的公共地址 138.76.29.7:31000，然而 NAT B 将会丢弃这
4、些进入的数据信息(除非它是一个FULL cone NAT)，原因是 NAT B 和 S 已经建立的外部会话，而 A 发送的信息中的源地址和端口号是和 S 不匹配的(可以参照一下上面的内容，匹配才能接受)。同样，假如 B 发送一个条 UDP 数据包给 A 的公网地址，NAT A 也会丢弃。但是，假设 A 发出一个 UDP 数据信息给 B 的公网 IP 地址，同时也通过服务器 S 传递一个请求给B，要求 B 也发一个 UDP 信息给 A 的公网 IP 地址。A 直接向 B 的公共 IP 地址(138.76.29.7:31000)发送的数据包会让 NAT A 在 A 的私有地址和 B 的公网地址之间
5、建立了一个新的连接会话。同时，B 到 A 的公网地址(155.99.25.11:62000)的信息会导致 NAT B 在 B 的私有地址和 A 的公共地址之间建立一个新的连接会话。一旦这种新的 UDP 连接在两者之间建立起来，客户端 A 和 B 就不需要服务器 S 的介绍就能彼此直接通讯了。UDP hole punching 技术有几个很有用的特点。一旦在两个位于 middlebox 后面的客户端建立了一个直接的 P2P 连接，在连接中的任何一方都可以扮演一个介绍人的角色，依次继续和另一个客户端建立连接，减少了最初的服务器 S 的负担。如果说有STUN的话，假如两个中的任意一个或两个都碰巧不在
6、 middlebox 后面，上述应用程序将同样可以建立 P2P 通讯通道，应用程序不需要尝试明确 middlebox 的类型。Hole punching 技术甚至可以自动的运用在多级 NAT 下面，多重NAT 就是那些客户端需要经历多级地址转换才能进入公网。2、位于同一 NAT 后(Peers behind the same NAT)现在考虑两台客户端(但并不确定)都在同一个 NAT 后面的情况，因此会有私有 IP 地址空间。客户端 A 与服务器 S 建立一个 UDP 会话，NAT 会分配一个公共端口 62000。客户端 B 与服务器 S 也建立一个简单的连接，NAT 为此分配一个公共端口 6
7、2001。 Server S18.181.0.31:1234|NATA-S 155.99.25.11:62000B-S 155.99.25.11:62001|+-+-+| |Client A Client B10.0.0.1:1234 10.1.1.3:1234假想 A 和 B 使用 UDP hole punching 技术与服务器 S 的建立一个外部的通讯路线做为中间介绍。然后 A 和 B 将可以通过服务器 S 得到各自公共 IP 地址和端口号，然后使用这些地址各自向对方发送数据。两个客户能够以这种方式彼此通讯，只要 NAT 不仅仅允许外网上的主机可以和内网上的主机进行 UDP 传输会话，也
8、可以允许内网上的主机可以和其他内网的主机进行 UDP 会话。我们在loopback translation中设计到这种情况，因为来自私有网络的数据包到达 NAT 后，会looped back到私有网络上就象从公网来的一样。例如，当 A 向 B 的公共 IP 地址发送一个 UDP 包，这个包的包头有一个源 IP 地址和端口，是 10.0.0.1:1234，而目的地址是 155.99.25.11.62001。NAT接受到这个包，会把源地址转换(映射)为 155.99.25.11:62000(就是 A 的公网地址)，把目的地址转换为 10.1.1.3:1234，然后发给 B。即使 NAT 支持回环映
9、射，NAT 的转换和发送步骤看上去是多余的，在 A 和 B 通讯时似乎为 NAT 添加了潜在的负担。这个问题的解决方法是直接的。当 A 和 B 一开始在服务器 S 上交换地址信息时，它们就可以包含他们自己的 IP 地址和端口号，并且是可见的，对服务器 S 也是可见的。客户端根据它们得到的地址同时开始向对方发数据包，并建立成功的通讯。假如这两个客户端都在同一 NAT 后面，数据包象通讯一开始就能直接到达，而不需要通过 NAT 就能建立直接连接。假如这两个客户端位于不同的 NAT 后，到达彼此私有地址的数据包会被丢弃，但是客户端可以通过各自的公共地址来建立连接。重要的是这些数据包需要通过一些方法去
10、鉴别，然而，在这种情况下，A 发到 B 的私有地址的数据包完全有可能到达 A 私网内其他无关的终端，B 发到 A 的包也是这样。3、Peers separated by multiple NATs(多级 NAT)在有多重 NAT 设备的拓扑结构中，如果没有一些拓扑的知识，在两个客户端之间建立理想的 P2P链路是不可能的。看看下面的举的例子。 Server S18.181.0.31:1234|NAT XA-S 155.99.25.11:62000B-S 155.99.25.11:62001|+-+-+| |NAT A NAT B192.168.1.1:30000 192.168.1.2:3100
11、0| | |Client A Client B10.0.0.1:1234 10.1.1.3:1234假设 NAT X 是由一个英特网服务提供者(ISP)设置的一个大型 NAT，在一些公网 IP 地址上拥有许多用户，NAT A 和 B 是小用户群的 NAT 网关，由 ISP 的用户自己独自配置，有各自的私有网络和用户群，使用的是 ISP 提供的 IP 地址。只有 SERVER S 和 NAT X 有自己全球固定的 IP 地址，而NAT A 和 B 用的公共IP 地址实际上是 ISP 地址域中私有地址，而客户端 A 和 B 的地址对 NAT A和 B 来说也是私有的地址。每当客户端需要和服务器 S
12、 建立一个外部的连接，都会导致 NAT A 和B 和客户端建立一个单独的公共/私有连接，然后让 NAT X 为每个连接会话建立一个公共/私有连接。现在推想客户 A 和 B 尝试建立一个直接的 P2P UDP 连接。对客户端 A 来说，最佳的方法是发送一个数据信息到客户端 B 在 NAT B 上，属于 ISP 的地址域的公共 IP 地址 192.168.1.2:31000，对客户端 B 来说就是发信息到 A 在 NAT A 的公共 IP 地址 192.168.1.1:30000(原文是 NAT B，是不是笔误，还是我理解有问题？)。不幸的是，A 和 B 并没有知道这些地址的方法，因为服务器 S
13、只能看到客户端全局的公共 IP 地址，就是 155.99.25.11:62000 和 155.99.25.11:62001。甚至当 A 和B 有某些方法可以得到这些地址，但他们依然不能保证这些地址是有用的，因为这些由 ISP 的私有地址域分配的地址可能与客户自己分配的私有地址由冲突。客户端因此没有选择只能使用由服务器 S 知道的公共 IP 地址来通讯，并且依赖 NAT X 来提供 loopback translation。4、Consistent prot binddings(保持端口绑定)hole punching 技术有一个需要注意的地方：它只能工作在两台 NAT 都是 cone NAT(或没有 NAT 防火墙)的情况下，只要 UDP 端口还在使用，它就需要保持一个固定的端口把一个给定(私有 IP，私有 UDP 端口)和一个(公共 IP，公共 UDP 端口)绑定。象对称 NAT 一样，为每个新的连接会话分配一个新的公共端口，对一个 UDP 应用程序来说，为了和不同的外部通讯重用一个已经存在的地址转换是不可以的。(这边稍微有点糊涂，再多看看。) 既然 cone NAT 运用是相当普遍的，UDP hole punching 技术应用的也相当广泛，但是还有一小部分是对等 NAT 配置，因此不能支持这种技术。
