摘要

  • STUN 报告一个服务器反射传输地址，这是从服务器视角进行的观察，而非普遍可达性或持久身份的保证。
  • 可达性、同意、安全和回退决策仍然是周边用法的责任，超出了 STUN 的观察范围。
  • 早期 STUN (RFC 3489) 旨在实现全面的 NAT 分类和地址重用，但因其复杂性和不可靠性而最终缩减了这一雄心。
  • 现代 STUN (RFC 5389, RFC 8489) 作为模块化工具，提供证据供 ICE (RFC 8445) 等高层协议用于候选者交换和点对点连接检查。

一次往返留下的证据

先看一次数据包往返留下的状态变化，而不是先谈“能否连通”的结论：一个客户端应用程序，在网络地址转换器 (NAT) 后面运行，发起一个会话遍历实用程序 (STUN) Binding 请求。该请求从客户端已知的特定本地 IP 地址和端口发送。当数据包穿过 NAT 时，NAT 设备会重写源 IP 地址和端口，将其转换为面向公众的传输地址。当此请求到达 STUN 服务器时，服务器会记录从该数据包接收到的源传输地址。然后，STUN 服务器构建一个 Binding 响应，将此观察到的源传输地址嵌入到 XOR-MAPPED-ADDRESS 属性中，并将其发送回客户端 ^1^。此返回的地址是 STUN 服务器在该特定时刻针对该特定事务的特定观察。

先看今天的规范边界

当前的 STUN 标准 [^4^ RFC 8489] 保持了这种更窄、更集中的工具和用途边界。它定义了发现服务器反射传输地址的核心机制，并指定了其他属性，例如用于诊断目的的 ERROR-CODE。至关重要的是，RFC 8489 阐明，高层协议和应用程序负责解释和利用这一观察结果。它们拥有与时间、处理各种属性、选择 STUN 服务器和选择传输协议相关的决策。

ICE 把这条边界落实为步骤：依照 [^5^ RFC 8445]，观测到的地址先作为候选，而不是直接当作可达性证明。 ICE 不会盲目信任单个 STUN 观察到的地址作为点对点可达性的证据。 相反，ICE 将服务器反射地址与主机候选者和中继候选者（通过 TURN 获得）一起视为一种“候选者”。 ICE 然后通过与对等方交换多个候选者对，并对这些对进行明确的点对点连接检查，从而参与一个复杂的过程。 这种系统检查建立了实际的可达性，而不是从单一观察中推断出来。 不同的目的地、各种协议、NAT 设备的状态、不断变化的防火墙规则或替代网络路径都可以独立影响特定观察到的地址是否确实可供对等方使用。 仅一个 STUN 响应无法揭示映射的生命周期、其对每个可能目的地的行为、特定的防火墙策略，或者远程对等方是否已同意通信。 STUN 中的身份验证和完整性机制保护了定义的交换，但不会将映射的元组转换为通用权限或对每个潜在对等方的可达性保证。 因此，周围的用途明确拥有候选者交换、执行连接检查、管理同意、确保新鲜度、选择最佳路径、处理重传、实施回退策略以及决定何时通过 TURN 服务器诉诸中继行为的责任。

早期设想从何而来

从历史上看，STUN，如 [^2^ RFC 3489] 中最初记载的，曾怀抱更宏大的愿景。它不仅旨在揭示这个服务器反射地址，还寻求对存在的 NAT 设备类型进行分类——例如全锥型、受限锥型或端口受限锥型——并提供一个完整的点对点连接遍历解决方案。潜在的假设是，通过理解 NAT 类型并观察外部映射，客户端可以可靠地预测其他对等方将如何看待其地址，从而促进直接连接。这种方法旨在将单一观察转化为可达性的普遍声明。

为什么必须收缩

然而，实际部署和操作经验揭示了严重的局限性。真实世界 NAT 实现、防火墙和网络拓扑的复杂性和可变性意味着 NAT 分类通常不可靠或具有误导性。通过 STUN 学习的地址可能对某些对等方可用，但对其他对等方不可用，或者其映射生命周期可能不可预测。RFC 3489 作为独立遍历解决方案的宏大愿景被证明是不充分的。这一关键的重新评估导致了 [^3^ RFC 5389]，其中明确记录了放弃经典 RFC 3489 完整解决方案雄心壮志的原因。它重新定位了 STUN 的角色，将其从一个全面的遍历机制重新定位为由高层用途使用的基本工具。STUN 服务器观察到的地址是宝贵的证据，但它既不是持久的公共身份，也不是对等方可以使用相同映射进行通信的证明。