问题描述
我阅读了 RFC6577 和 RFC8445 但我觉得如何使用 TURN 与使用ICE 实际上如何利用中继候选.
I read RFC6577 and RFC8445 but I feel like there is a bit of a disconnect between how TURN can be used versus how ICE actually utilizes the relay candidates.
TURN RFC 描述了使用单个 TURN 服务器在客户端和对等端之间传输数据.TURN 服务器上的传输地址通过 TURN 消息接受来自客户端的数据流，而 中继传输地址通过 UDP 接受来自对等方的数据流.这听起来很棒 - 一个 TURN 服务器和双向数据流.
The TURN RFC describes the use of one single TURN server to ferry data between a client and a peer. The transport address on the TURN server accepts data flow from a client via TURN messages, whereas the relayed transport address accepts data flow from peer(s) via UDP. This sounds great - one TURN server and bidirectional data flow.
但是在阅读有关 ICE 的内容时，我觉得这从未发生过.调用者和被调用者都在潜在的两个 TURN 服务器上独立分配，然后将各自的中继传输地址发送给对方.更像是一个我可以通过这个中继传输地址 之类的东西.然后进行连接检查，因此，这里最终使用了两个 TURN 服务器，其中数据仅在一个方向上通过每个参与者分配的 TURN 服务器的中继传输地址流动.
However in reading about ICE, I feel like this never happens. Both caller and callee independently allocate on potentially two TURN servers, and then send their respective relayed transport addresses to each other. More like an I can be reached via this relayed transport address sort of thing. Connectivity checks then occur and thus, two TURN servers end up being used here where data only flows in one direction through the relayed transport address of each participants allocated TURN server.
这是真的吗?
来自 TURN RFC，它说:
From the TURN RFC, it says the following:
客户端可以安排服务器来回转发数据包某些其他主机(称为对等方)并且可以控制中继完成.客户端通过获取 IP 地址和服务器上的端口，称为中继传输地址.当同行向中继传输地址发送数据包，服务器中继包给客户端.当客户端向客户端发送数据包时服务器，服务器使用中继将其中继到适当的对等方传输地址作为源.
但是，我看不到通过 ICE 协商，数据会通过传输地址从客户端流向对等方的场景.调用者和被调用者都在 TURN 服务器上独立分配，并相互发送中继传输地址以供访问.
However, I can't see a scenario whereby through ICE negotiations, data would ever flow through the transport address from the client to the peer. Both the caller and the callee independently allocate on a TURN server and send relayed transport addresses to each other to be reached on.
基本上，TURN 可以进行双向数据流，但是在两个对称 NAT 之间使用 ICE，它不会.这是正确的吗?
Basically, TURN can do bidirectional data flow, but with ICE between two symmetric NAT's, it wont. Is this correct?
推荐答案
它有点复杂......请耐心等待.仅阅读 TURN RFC 是不够的，您还需要来自 ICE 上的 RFC 5245 的上下文.
Its a bit complicated.... bear with me. Reading just the TURN RFC isn't enough, you need context from RFC 5245 on ICE too.
以下场景是基准案例:1)客户端A分配一个中继地址8.8.8.8:43739，发送给客户端B2)客户端B向8.8.8.8:43739发送UDP包3) TURN 服务器将数据包包裹在一个 stun 消息中，发送给客户端 A
The following scenario is the baseline case:1) client A allocates a relay address 8.8.8.8:43739, sends it to client B2) client B sends a UDP packet to 8.8.8.8:437393) TURN servers wraps the packet in a stun message, sends it to client A
现在正如您所说，通常客户端 B 也会分配自己的中继地址并将其发送给 A.为什么不一直使用(或一半时间)?毕竟候选人的优先级是平等的.然而，候选对优先权决定了选择哪对包括一个因素作为决胜局:
Now as you say, typically client B will also allocate its own relay address and send it to A. Why isn't that used all the time (or half the time)? The priorities of the candidates are equal after all.However the candidate pair priority which determines which pair to pick includes a factor which acts as a tie-breaker:
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.
这意味着使用调用者(假设其控制代理)中继地址的对比使用被调用者中继地址的对具有更高的优先级.
This means the pair where the callers (assuming its the controlling agent) relay address is used has a higher priority than the pair with the callees relay address.
此外，这里还有另一个候选端口，用于客户端 B 用于发送到端口 8.8.8.8:43739 的端口.这通常来自本地候选者之一，并且 TURN 服务器看到(并将数据指示放入)客户端 B 的公共(post-nat)ip.在客户端 A 上，这将显示为远程 srflx 候选者——其中具有比中继候选者更高的优先级，因此将被使用.
Additionally, there is another candidate in the game here for the port client B uses to send to port 8.8.8.8:43739. This will typically be from one of the local candidates and the TURN server sees (and puts into the data indication) the public (post-nat) ip of client B. On client A this will show up as a remote srflx candidate -- which has a higher priority than a relayed candidate and will therefore be used.
现在，如果 B 位于对称 NAT 之后(我认为)，TURN 服务器将看到来自客户端 B 的端口与客户端 A 添加了权限的任何端口不同.这通常意味着 TURN 服务器将丢弃数据包并且该数据包将无法工作.
Now if B is behind a symmetric NAT (I think) the TURN server will see a different port from client B than anything for which client A has added a permission. This will typically mean the TURN server will drop the packet and that pair won't work.
如果客户端 A 不在对称 NAT 后面，则基线过程将在另一个方向重复.优先级稍低，但在延迟方面相同，因此用户不会注意到.
If client A is not behind a symmetric NAT, the baseline process will be repeated in the other direction. Slightly less priority but its the same in terms of latency so users won't notice.
如果两个客户端(现在我们终于在您所询问的情况下)都在对称 NAT 之后，则两者都将不起作用，并且将使用中继中继对.这种情况相当罕见(
If both clients are (and now we are finally at the case you're asking about) are behind symmetric NAT, neither will work and a relay-relay pair will be used. This is fairly rare (<1% probably) and the latency impact is typically insignificant even when both clients are on different TURN servers.
这篇关于两个对称 NAT 后面的对等点之间的 ICE 协商会导致需要两个 TURN 服务器吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！