STUN如何在候选对上执行ICE连接检查？

Question

我已经阅读了RFC 5389和RFC 5245以及较新的RFC 8445。 我了解STUN如何返回服务器自反地址或中继地址。该请求被发送到STUN服务器。

我的基本问题是关于使用STUN进行ICE连接检查。 RFC 8445状态在第10页：

id

对于检查候选对的连接性检查，STUN消息必须至少提供目标IP地址，端口，协议的准备。该STUN消息结构在哪里描述？在哪里可以获得STUN如何完成此连接检查的详细信息？

Answer 1

您将在RFC-5389第6节https://tools.ietf.org/html/rfc5389#page-10中找到STUN消息结构。

说明中的重要部分：

  

STUN消息使用面向网络的格式以二进制编码      （最高有效字节或八位字节优先，也通常称为big-      字节序）。传输顺序在附录B中有详细说明      RFC 791 [RFC0791]。除非另有说明，否则数值常数为      以十进制（以10为底）。

     

所有STUN消息必须以20字节的报头开头，后跟零      或更多属性。 STUN标头包含STUN消息类型，      魔术cookie，交易ID和消息长度。

     

每个STUN消息的最高2位务必为零。      这可用于区分STUN数据包与其他协议      当STUN与其他协议在同一端口上多路复用时。

     

消息类型定义消息类（请求，成功      响应，失败响应或指示）和消息方法      （主要功能）STUN消息。虽然有四个      消息类，STUN中只有两种类型的事务：      请求/响应事务（包括请求消息和      响应消息）和指示交易（包括      单个指示消息）。响应类分为错误      和成功响应，有助于快速处理STUN消息。

Answer 2

我可以理解解释该过程的RFC描述的困难。我正在尝试简化：-

假设我最终获得的候选对为：-

1. IP1，P1
2. RIP2，P2
3. TIP3，P3

类似地，我的同伴也将自己设置为

1. （B）IP1，P4
2. （B）RIP2，P5
3. （B）TIP3，P6

让我们前进到拥有良好媒体流的未来。显然，对于从A-> B的媒体方向，我们有两个传输地址。由于使用UDP发送媒体，因此套接字具有源地址和目标地址。让我们将它们称为SrcIP_A，SrcPort_A和SrcIP_B，SrcPort_B。

必须清楚，SrcIP_A，SrcPort_A是A候选对的一部分，而SrcIP_B，SrcPort_B是B候选对的一部分。

现在，从A的角度出发，到现在，为了实现A-> B的平滑媒体流，我们只需要锁定最终将要使用的那对就可以使用。

这是STUN出现的地方。请记住，需要将STUN请求发送到特定的IP端口。然后响应告诉STUN服务器在请求中注意到哪个是NATted外部地址。

因此，A创建9对，将其候选对中的每个条目与其对等项进行匹配。然后，它从该对的RFC 8445 Page 14基对向每个远程候选对发送一个STUN请求，该请求来自其对每个候选集。现在，当远端B在其候选对上接收到任何流量时，它必须在自己的一侧实现STUN服务器逻辑。因此，基本上，套接字在接收任何数据包时需要能够区分媒体数据包和STUN数据包。如果是后者，它将发回STUN响应，指示从何处接收到该请求。

我们假设在迭代A时采用以下组合。

1. IP1，P1与RIP2，P5 在这里，请求者可能到达B，因为RIP2，P5的自反地址将到达NAT内部。返回的观察到的地址将是IP1，P1的反射地址。在A端，当收到响应时，由于包含的地址不是IP1，P1，它将丢弃此集合。
2. RIP2，P2与（B）IP1，P4 显然会失败。由于您无法发送到IP1，P4，这是一个专用地址。
3. RIP2，P2与RIP2，P5 在这里，请求者可能到达B，因为RIP2，P5的自反地址将到达NAT内部。返回的观察到的地址也将是RIP2，P2。因此，可以将其标记为“有效对”。

希望我已经清楚了。