这是在 NAT 后面的两台主机之间建立 P2P 连接的合理技术吗？答案

【问题标题】：Is this a reasonable technique to establish P2P connections between two hosts behind a NAT?这是在 NAT 后面的两台主机之间建立 P2P 连接的合理技术吗？
【发布时间】：2013-01-09 22:27:48
【问题描述】：

为了让两个不同 NAT 后面的两个主机能够建立 P2P 连接，它们都必须具有彼此的公共端点（地址/端口）。为了让每个主机知道它自己的公共端点，它可以与一个已知的公共服务器通信，该服务器将它的公共端点返回给主机，如服务器所见。请参阅 STUN (RFC5389)。

为了使这种机制起作用，NAT 必须始终如一地将同一个私有端点转换为同一个公共端点，而不管目标端点是什么。

实现一个依赖于这种特定 NAT 行为的 P2P 应用程序是否是个好主意（即它是否足够普遍）？ Skype 和/或其他流行的 P2P 应用程序是否有其他回退机制？

编辑：它看起来像一个 NAT，其中每个目标选择不同的端口被称为“对称 NAT”。此外，一些对称 NAT 会增加端口号，从而可以猜测正确的端口。

现在我想问题是：大约有多少百分比的 NAT 是对称 NAT，其中有多少百分比使用随机端口分配与递增之类的东西？

【问题讨论】：

谷歌的“nat punchthrough”，我认为这应该是你的拿手好戏，但我不是 100% 确定。
@dutt 是的，谢谢。这或多或少是一个概念。根据jenkinssoftware.com/raknet/manual/natpunchthrough.html，看起来会出现问题的 NAT 类型被称为“对称 NAT”
使用 UPnP 抽象 NAT 问题怎么样？
en.wikipedia.org/wiki/Interactive_Connectivity_Establishment
这是我的“简而言之”答案：stackoverflow.com/questions/8523330/programming-p2p-application/…

标签： networking udp p2p firewall nat

【解决方案1】：

您可以使用 IETF 的标准 STUN/TURN/ICE 协议： http://rtcbits.blogspot.com/2012/10/what-is-ice-interactive-connectivity.html

根据 Google Gtalk 统计数据，这些机制在 92% 的情况下无需中继流量即可解决 P2P 连接问题。 https://developers.google.com/talk/libjingle/important_concepts

【讨论】：

【解决方案2】：

STUN 只能处理 85% 的情况！ TURN 可以处理 100%，但使用起来确实很昂贵。那么用什么呢？两者都不是

使用 ICE。它是STUN服务器和TURN服务器的直接组合！这样，您将拥有 100% 的可靠性，但您只能在服务器上中继 15% 的流量。

【讨论】：