当一个 STUN 服务器收到来自两个不同 STUN 代理的具有相同事务 ID 的请求时，它应该如何表现？
问问题
459 次
3 回答
1
来自 STUN 绑定请求的事务 ID 只是在 STUN 绑定响应中回显。服务器不会尝试将这个值解释为除了日志之外的任何内容。它也不会尝试管理或处理重复的请求或重复的事务 ID。如果两个不同的客户端发送一个具有相同事务 ID 的绑定请求，那么它们都将在其相应的响应中获得相同的事务 ID。
交易 ID 只是为了客户的利益。如果客户端收到来自服务器的响应，其事务 ID 与请求中使用的不同，它应该简单地忽略它。因为该数据包可能是先前 STUN 会话的延迟到达。
唯一可能存在重复事务 ID 的情况是客户端超时等待响应并再次重新发送绑定请求。RFC 5389 在第 6 节中提到了这一点： Resends of the same request reuse the same transaction ID。
于 2016-04-22T07:10:52.780 回答
1
这不应该发生，但是如果服务器应该检查 5 元组（客户端 IP 地址和端口、服务器 IP 地址和端口以及传输协议（当前是 UDP、TCP 或 TLS 之一）的组合）。如果 5 元组不匹配，则服务器应继续将其视为有效事务，否则应按照 RFC-5766 行事。
于 2016-04-18T23:30:54.610 回答
0
我不认为你应该准备你的软件来处理这种奇怪的情况。事务 id 是客户端生成的随机值，您不太可能在 stun 客户端中看到此类错误。
事务 ID 是一个 96 位的标识符，用于唯一标识 STUN 事务。对于请求/响应事务，事务 ID 由 STUN 客户端为请求选择，并由服务器在响应中回显。
如果不是随机的，那么很可能是由一个伪造的客户端软件引起的，最终您最终只会向该客户端发送错误的答案，直到其开发人员找到并修复他们的软件。
于 2016-04-18T14:02:15.510 回答