我正在编写一个P2P应用程序。对等体定期ping主服务器以更新其当前的IP /端口，因此当对等体想要到达另一个时，它可以向服务器询问该信息。现在，对等体使用UPnP配置NAT（用于经典家庭设置）可从外部访问。
所以一切正常，除非对等方的客户端试图到达另一个（或同一个）对等方的服务器，并且两者都在同一个NAT之后。 由于在这种情况下客户端正在尝试从NAT后面到达自己的“外部”（公共）IP地址，因此NAT不会进行端口转发，也无法路由IP数据包。
目前我正在考虑两种解决方案：
您能想到其他解决方案吗？主流P2P应用程序实施哪些策略来解决这个问题？
答案 0 :(得分：6)
因为在那种情况下客户端正试图达到自己的“外部” （公共）从NAT后面的IP地址，NAT不做端口 转发，无法路由IP数据包。
这被称为发夹状况。并非所有路由器/ NAT都能正确解决此问题解决方案是：
a）检查您的路由器/ NAT是否可以配置为启用“发夹”。如果您控制部署中的所有路由器/ NAT，此解决方案将起作用。
b）购买另一个路由器/节点，允许这样做。就像a）一样，如果您控制部署中的所有路由器/ NAT，它都可以工作。
c）如果您可以从UPnP获取端口信息，这也是一个解决方案，但并非所有路由器/ NAT都知道或支持UPnP。它并未涵盖大型部署中的所有情况。
d）使用多播来“发现”局域网上的其他节点，甚至与它们通信是这个问题的常见解决方案。您需要就IP地址达成一致并让同行听取它。
e）在服务器上存储私有IP地址也是一种解决方案，但它需要服务器上的存储容量比解决方案d更多。还要处理超时（即数据有效期到期）。
f）在对等体之间使用类似TURN的通信（即，节点之间的通信通过中央服务器）。这种解决方案非常坚固，但在带宽消耗方面并不是最有效的。
希望这有帮助。
答案 1 :(得分：0)
交互式连接建立（ICE）专门用于解决此类NAT问题。它使用STUN和TURN来实现结果，并用于现代p2p应用程序。 （例如，语音聊天）
PJNATH图书馆有document解释
与独立的STUN解决方案不同，它（ICE）解决了发夹问题，因为它也提供了候选人。