根据:
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 服务器主机,无法重用该客户端套接字向不同的对等方发送数据。