两个对称 NAT 后面的对等点之间的 ICE 协商是否会导致需要两个 TURN 服务器？

Question

我阅读了RFC6577和RFC8445 ，但我觉得 TURN 的使用方式与 ICE实际使用relay candidates.

TURN RFC 描述了使用单个 TURN 服务器在客户端和对等点之间传输数据。TURN 服务器上的transport addressTURN 服务器通过 TURN 消息接受来自客户端的数据流，而 TURN 服务器relayed transport address通过 UDP 接受来自对等方的数据流。这听起来很棒——一台 TURN 服务器和双向数据流。

然而，在阅读有关 ICE 的文章时，我觉得这种情况从未发生过。调用者和被调用者都独立地在可能的两个 TURN 服务器上进行分配，然后将各自的信息发送relayed transport addresses给对方。更像是一种I can be reached via this relayed transport address东西。然后进行连接检查，因此，这里最终使用两个 TURN 服务器，其中数据仅沿一个方向流经分配给relayed transport address每个参与者的 TURN 服务器。

这是真的？

TURN RFC 中的内容如下：

客户端可以安排服务器将数据包转发到某些其他主机（称为对等点），并可以控制转发方式的各个方面。客户端通过获取服务器上的 IP 地址和端口（称为中继传输地址）来完成此操作。当对等方将数据包发送到中继传输地址时，服务器会将数据包中继到客户端。当客户端向服务器发送数据包时，服务器使用中继的传输地址作为源将其中继到适当的对等点。

然而，我看不到通过 ICE 协商，数据会通过传输地址从客户端流向对等点的情况。呼叫者和被呼叫者都在 TURN 服务器上独立分配并发送给relayed transport addresses对方以进行联系。

基本上，TURN可以进行双向数据流，但是对于两个对称 NAT 之间的 ICE，它不会。它是否正确？

Answer 1

它有点复杂......请耐心等待。仅阅读 TURN RFC 是不够的，您还需要ICE 上的RFC 5245的上下文。

以下场景是基准案例：

1. 客户端A分配中继地址8.8.8.8:43739，发送给客户端B
2. 客户端B发送UDP数据包到8.8.8.8:43739
3. TURN 服务器将数据包包装在 stun 消息中，并将其发送给客户端 A

现在正如你所说，通常客户端 B 也会分配自己的中继地址并将其发送到 A。为什么不一直（或一半时间）使用它？毕竟，候选人的优先顺序是平等的。然而，决定选择哪对的候选对优先级包括一个充当决胜局的因素：

      pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Where G>D?1:0 is an expression whose value is 1 if G is greater than
D, and 0 otherwise.

这意味着使用呼叫者（假设其控制代理）中继地址的对具有比使用被叫者中继地址的对更高的优先级。

此外，游戏中还有另一个候选端口，用于客户端 B 用于发送到端口 8.8.8.8:43739 的端口。这通常来自本地候选者之一，并且 TURN 服务器看到（并将其放入数据指示中）客户端 B 的公共（NAT 后）IP。在客户端 A 上，这将显示为远程 srflx 候选者 - 这具有比中继候选者更高的优先级，因此将被使用。

现在，如果 B 在对称 NAT 后面（我认为），TURN 服务器将看到来自客户端 B 的端口与客户端 A 添加权限的任何端口不同。这通常意味着 TURN 服务器将丢弃数据包，并且该对将无法工作。

如果客户端 A 不在对称 NAT 后面，则基线过程将在另一个方向重复。优先级稍低，但在延迟方面是相同的，因此用户不会注意到。

如果两个客户端（现在我们终于遇到了您所询问的情况）都位于对称 NAT 之后，则两者都不起作用，并且将使用中继-中继对。这种情况相当罕见（可能<1%），即使两个客户端位于不同的 TURN 服务器上，延迟影响通常也微不足道。