STUN 如何对候选对执行 ICE 连通性检查？
How does STUN perform ICE connectivity check on Candidate Pairs?
我已经阅读了 RFC 5389 和 RFC 5245 以及更新的 RFC 8445。
我了解 STUN 如何返回服务器反身地址或中继地址。请求被发送到 STUN 服务器。
我的基本问题是关于使用 STUN 检查 ICE 连接性。 RFC 8445 第 10 页上的状态：
"...At the end of
this process, each ICE agent has a complete list of both its
candidates and its peer's candidates. It pairs them up, resulting in
candidate pairs. To see which pairs work, each agent schedules a
series of connectivity checks. Each check is a STUN request/response
transaction that the client will perform on a particular candidate
pair by sending a STUN request from the local candidate to the remote
candidate."
对于检查候选对的连通性检查，STUN 消息必须至少提供目标 IP 地址、端口、Proto。在哪里描述了这个 STUN 消息结构？我在哪里可以获得有关 STUN 如何完成此连接检查的详细信息？
您会在 RFC-5389 第 6 节中找到 STUN 消息结构。https://www.rfc-editor.org/rfc/rfc5389#page-10。
值得注意的描述：
STUN messages are encoded in binary using network-oriented format
(most significant byte or octet first, also commonly known as big-
endian). The transmission order is described in detail in Appendix B
of RFC 791 [RFC0791]. Unless otherwise noted, numeric constants are
in decimal (base 10).
All STUN messages MUST start with a 20-byte header followed by zero
or more Attributes. The STUN header contains a STUN message type,
magic cookie, transaction ID, and message length.
The most significant 2 bits of every STUN message MUST be zeroes.
This can be used to differentiate STUN packets from other protocols
when STUN is multiplexed with other protocols on the same port.
The message type defines the message class (request, success
response, failure response, or indication) and the message method
(the primary function) of the STUN message. Although there are four
message classes, there are only two types of transactions in STUN:
request/response transactions (which consist of a request message and
a response message) and indication transactions (which consist of a
single indication message). Response classes are split into error
and success responses to aid in quickly processing the STUN message.
我能理解解释过程的 RFC 描述的困难。我正在尝试简化：-
假设我最终获得了候选对：-
- IP1,P1
- RIP2,P2
- TIP3,P3
同样我的同伴也有他自己的集合
- (B)IP1,P4
- (B)RIP2,P5
- (B)TIP3,P6
让我们快进到未来，我们将拥有良好的媒体流。显然，对于媒体从 A->B 的方向，我们有两个传输地址。由于 UDP 用于发送媒体，因此套接字具有源地址和目标地址。我们称它们为 SrcIP_A、SrcPort_A 和 SrcIP_B、SrcPort_B.
必须明确SrcIP_A,SrcPort_A是A的部分候选对，SrcIP_B,SrcPort_B是A的部分候选对B.
现在，来到当前时间，从A的角度来看，为了实现从A->B的流畅媒体流，我们只需要从我们已经设置的集合中锁定我们最终将使用的对有。
这就是 STUN 发挥作用的地方。请记住，STUN 请求需要发送到特定的 IP、端口。响应告诉 STUN 服务器在请求中注意到的 NATted 外部地址。
因此，A 创建了 9 对，将其自身的候选对中的每个条目与其对等项进行匹配。然后它从它自己的每个候选集中的 RFC 8445 Page 14 碱基向每个远程候选对发送 STUN 请求。现在，当远程端 B 在其候选对上接收到任何流量时，它必须在自己的端实现一个 STUN 服务器逻辑。因此，基本上，套接字在接收任何数据包时都需要能够区分媒体数据包和 STUN 数据包。如果是后者，它将发回一个 STUN 响应，指示它从哪里收到请求。
让我们假设迭代 A 是以下组合。
- IP1,P1 Vs RIP2,P5 这里reuest可能到达B，因为RIP2,P5的自反地址会到达NAT内部。返回的观察地址将是 IP1,P1 的反射地址。在A侧，当收到响应时，它会丢弃这个集合，因为包含的地址不是IP1，P1。
- RIP2,P2 Vs (B)IP1,P4 这显然会失败。由于您不能发送到 IP1，P4 这是一个私有地址。
- RIP2,P2 Vs RIP2,P5 这里reuest可能到达B，因为RIP2,P5的自反地址会到达NAT内部。观察到的返回地址也将是 RIP2,P2。所以这可以标记为“有效对”。
希望我已经说清楚了。
我已经阅读了 RFC 5389 和 RFC 5245 以及更新的 RFC 8445。 我了解 STUN 如何返回服务器反身地址或中继地址。请求被发送到 STUN 服务器。
我的基本问题是关于使用 STUN 检查 ICE 连接性。 RFC 8445 第 10 页上的状态：
"...At the end of
this process, each ICE agent has a complete list of both its
candidates and its peer's candidates. It pairs them up, resulting in
candidate pairs. To see which pairs work, each agent schedules a
series of connectivity checks. Each check is a STUN request/response
transaction that the client will perform on a particular candidate
pair by sending a STUN request from the local candidate to the remote
candidate."
对于检查候选对的连通性检查，STUN 消息必须至少提供目标 IP 地址、端口、Proto。在哪里描述了这个 STUN 消息结构？我在哪里可以获得有关 STUN 如何完成此连接检查的详细信息？
您会在 RFC-5389 第 6 节中找到 STUN 消息结构。https://www.rfc-editor.org/rfc/rfc5389#page-10。
值得注意的描述：
STUN messages are encoded in binary using network-oriented format (most significant byte or octet first, also commonly known as big- endian). The transmission order is described in detail in Appendix B of RFC 791 [RFC0791]. Unless otherwise noted, numeric constants are in decimal (base 10).
All STUN messages MUST start with a 20-byte header followed by zero or more Attributes. The STUN header contains a STUN message type, magic cookie, transaction ID, and message length.
The most significant 2 bits of every STUN message MUST be zeroes. This can be used to differentiate STUN packets from other protocols when STUN is multiplexed with other protocols on the same port.
The message type defines the message class (request, success response, failure response, or indication) and the message method (the primary function) of the STUN message. Although there are four message classes, there are only two types of transactions in STUN: request/response transactions (which consist of a request message and a response message) and indication transactions (which consist of a single indication message). Response classes are split into error and success responses to aid in quickly processing the STUN message.
我能理解解释过程的 RFC 描述的困难。我正在尝试简化：-
假设我最终获得了候选对：-
- IP1,P1
- RIP2,P2
- TIP3,P3
同样我的同伴也有他自己的集合
- (B)IP1,P4
- (B)RIP2,P5
- (B)TIP3,P6
让我们快进到未来，我们将拥有良好的媒体流。显然，对于媒体从 A->B 的方向，我们有两个传输地址。由于 UDP 用于发送媒体，因此套接字具有源地址和目标地址。我们称它们为 SrcIP_A、SrcPort_A 和 SrcIP_B、SrcPort_B.
必须明确SrcIP_A,SrcPort_A是A的部分候选对，SrcIP_B,SrcPort_B是A的部分候选对B.
现在，来到当前时间，从A的角度来看，为了实现从A->B的流畅媒体流，我们只需要从我们已经设置的集合中锁定我们最终将使用的对有。
这就是 STUN 发挥作用的地方。请记住，STUN 请求需要发送到特定的 IP、端口。响应告诉 STUN 服务器在请求中注意到的 NATted 外部地址。
因此，A 创建了 9 对，将其自身的候选对中的每个条目与其对等项进行匹配。然后它从它自己的每个候选集中的 RFC 8445 Page 14 碱基向每个远程候选对发送 STUN 请求。现在，当远程端 B 在其候选对上接收到任何流量时，它必须在自己的端实现一个 STUN 服务器逻辑。因此，基本上，套接字在接收任何数据包时都需要能够区分媒体数据包和 STUN 数据包。如果是后者，它将发回一个 STUN 响应，指示它从哪里收到请求。
让我们假设迭代 A 是以下组合。
- IP1,P1 Vs RIP2,P5 这里reuest可能到达B，因为RIP2,P5的自反地址会到达NAT内部。返回的观察地址将是 IP1,P1 的反射地址。在A侧，当收到响应时，它会丢弃这个集合，因为包含的地址不是IP1，P1。
- RIP2,P2 Vs (B)IP1,P4 这显然会失败。由于您不能发送到 IP1，P4 这是一个私有地址。
- RIP2,P2 Vs RIP2,P5 这里reuest可能到达B，因为RIP2,P5的自反地址会到达NAT内部。观察到的返回地址也将是 RIP2,P2。所以这可以标记为“有效对”。
希望我已经说清楚了。