根据：
https://en.wikipedia.org/wiki/Network_address_translation
有 4 种类型的 NAT 配置：
全锥、地址限制、端口限制和对称。
现在，假设我们的客户端 A 和客户端 B 位于不同的网络上，并且隐藏在各自单独的 NAT 后面。
如果要进行 p2p 通信，“客户端 A NAT 类型”+“客户端 B NAT 类型”的哪些组合需要 TURN 服务器参与（即无法通过 STUN 协议解决）？
例如， 我怀疑：
” 客户端 A NAT = 对称 + 客户端 B NAT = 对称 ” 需要 TURN 服务器。
剩下的组合是什么？
对称到对称：TURN
与端口限制对称：TURN
与地址限制对称：STUN（但可能不可靠）
与圆锥体对称：STUN
其他一切都可以通过STUN来完成。
存在已知的技术，可以猜测对称 NAT 的端口分配算法（通常对称 NAT 只是继续使用下一个增量端口号）。因此，如果您通过 STUN 知道 NAT 是对称的，并通过 STUN 测试观察到两个不同地址的端口映射仅相差 1，则可以猜测下一个端口分配并将其用作候选地址。
即使对于上面列出的 STUN 配对，STUN 也不是 100% 可靠，并且 TCP 的可靠性不如 UDP。云端中继让您更接近 100% 遍历。
位于对称 nat 后面的客户端只能在客户端-服务器模式下进行对话。作为客户端开始与之对话的 STUN 服务器主机，无法重用该客户端套接字向不同的对等方发送数据。