我正在开发一个 P2P 应用程序，我需要使用 STUN 和/或 TURN 进行 NAT 穿越。我已经研究了仅使用 STUN 时出现的问题（基本上它并不总是有效，因为它是基于 UDP 的，并且一些防火墙不喜欢这样 - 根据我的问题，原因并不那么有趣），我一直看到关于使用 STUN 和 TURN 进行后备的建议（ICE 方案）。
但无论我在哪里看，我都认为人们 STUN 是“不太可能总是工作”。我正在寻找的是一些具体的数字/统计数据。我可能会尝试自己生成它们，但我没有足够的客户来获取大量样本。
所以我想知道是否有人可以了解有关使用 STUN 进行 NAT 遍历的成功率的统计数据。如果我没有使用 TURN 作为后备，有多少对等方将无法连接？
【问题讨论】：
根据您的客户是谁、他们在哪里以及他们使用的设备类型（PC 与移动），结果可能会有所不同。
在实践中（根据我的经验），仅使用 STUN 的 ICE 连接在台式机和笔记本电脑上的成功率约为 85%。但是，如果它对特定的一对端点起作用一次，则更有可能用于这些相同主机的后续连接（假设网络拓扑没有改变）。移动设备的情况有些不同。
以下是影响 P2P 成功“连接”（基于 UDP 或 TCP）的一些因素。
NAT 类型。如果两个端点都落后于表现良好的“端口限制”NAT 或更好，那么 STUN 成功的机会就很高。这是具有良好 ISP 的家庭 NAT 的常见情况，例如美国的那些。但移动运营商和企业防火墙通常会实施“对称 NAT”，因为它具有多层 NAT 和网络配置。这基本上意味着端口映射不一致 - 并且像 ICE 这样的 P2P 算法更难与之建立连接。
防火墙或企业配置。即使防火墙允许出站 UDP 数据包并接受返回的数据包，它通常也是对称 NAT 配置。
移动运营商。通常（但不总是）对称 NAT 类型。
【讨论】：