我在寫一個P2P應用程序。同行們定期ping主服務器來更新他們當前的IP /端口，所以當對方想要到達另一個服務器時，它可以向服務器詢問這些信息。現在，同行使用UPnP將NAT（用於經典家庭設置）配置爲可從外部訪問。NAT翻譯不能從網絡內部工作（髮夾狀態）
所以一切正常，當同行的客戶端試圖到達另一個（或相同）等的服務器，除了兩者是相同的NAT後面。 由於在這種情況下，客戶端試圖從NAT後面到達自己的「外部」（公共）IP地址，NAT不會執行端口轉發，也無法路由IP數據包。
現在我正在考慮兩種解決方案：
你能想到其他解決方案？主流P2P應用實施哪些策略來解決這個問題？
因爲在這種情況下，客戶端嘗試從NAT後面到達了自己的「外部」 （公共）IP地址，NAT沒有做端口 轉發和無法路由的IP數據包。
這被稱爲髮夾條件。並非所有的路由器/ NAT都能正確解決這個問題解決方案是：
a）檢查您的路由器/ NAT是否可以配置爲啓用'發展'。如果您控制部署中的所有路由器/ NAT，則此解決方案可以正常工作。
b）購買另一個允許這個的路由器/節點。就像a）一樣，如果你控制你的部署中的所有路由器/ NAT，它就可以工作。
c）如果您能得到獲得來自UPnP的端口信息，這是一個解決方案太多，但並不是所有的路由器/ NAT知道或支持UPnP。它並未涵蓋大型部署中的所有情況。
d）利用多播來「發現」的LAN上的其它節點甚至與它們進行通信是對這一問題的常見解決方案。你需要同意一個IP地址並讓同行聽取它。
e）存儲在服務器上的私有IP地址是一個解決方案太多，但它需要的服務器解決方案相比在d更多的存儲容量。有一個超時（即數據有效期滿）也可以處理。 f）使用對等節點之間的類似TURN的通信（即，節點之間的通信經過中央服務器）。該解決方案堅如磐石，但在帶寬消耗方面不是最高效的。
希望這會有所幫助。
Interactive Connectivity Establishment（ICE）是專門爲解決這類NAT問題而開發的。它使用STUN和TURN來實現結果，並用於現代p2p應用程序。 （例如。有空視頻）
的PJNATH庫有document解釋
不像獨立的STUN解決方案，它（ICE）解決hairpinning問題，因爲它也提供了主機的候選人。
謝謝，我不知道那裏有個名字。 a），b）和f）在我的情況下不起作用（我不控制路由器，並且有太多數據要傳輸），所以我可能必須堅持其中3個，或者可能所有這些......在d）中，你的意思是「端口」而不是「IP地址」？ – 2011-05-20 10:53:18
關於d），它是端口和多播地址（兩者）。 – JVerstry 2011-05-20 15:44:40
如果這是你的網絡，你可能想避免髮夾，並使用拆分DNS。但問題是軟件作者可以做些什麼來緩解這個問題。 – 2017-04-27 07:53:23