【ZeroRange WebRTC】RFC 5389：STUN 协议规范（中文整理与译注）
RFC 5389：STUN 协议规范（中文整理与译注）
说明：本文对 RFC 5389（Session Traversal Utilities for NAT, STUN）进行中文整理与译注，聚焦工程所需的核心章节与要点，并辅以图示帮助理解。
参考：RFC 5389（https://datatracker.ietf.org/doc/html/rfc5389）[0]
摘要（Abstract）
- STUN 是一种“用于其他协议穿越 NAT 的辅助手段”。
- 终端可用 STUN 获取其被 NAT 分配的“对外可见 IP 与端口”（即服务器反射地址 srflx），也可以用于端到端连通性检查与 NAT 映射保活。
- STUN 并非独立的 NAT 穿越完整解决方案，而是“在穿越方案上下文中使用的工具”。这是与旧版 RFC 3489 的重要区别（RFC 5389 废除 RFC 3489）。
运行概览（Overview of Operation）
- STUN 采用“事务”模型：客户端发送请求（Binding Request），服务端返回响应（Binding Success/Binding Error）。
- 客户端通常使用 UDP 与服务器交互，亦支持 TCP/TLS‑over‑TCP；在 NAT 环境下，服务器响应中包含客户端的“对外可见地址与端口（XOR‑MAPPED‑ADDRESS）”。
- STUN 可用于：
- NAT 映射发现（srflx）；
- 连通性检查（用于 ICE）；
- 保活与刷新 NAT 映射（周期性发送绑定请求）。
- STUN 支持报文完整性与认证（MESSAGE‑INTEGRITY、USERNAME、REALM、NONCE），并可携带 FINGERPRINT（CRC32C）用于快速检测报文是否被破坏或误判为其他协议。
术语与定义（Terminology & Definitions）
- Endpoint（端点）：执行 STUN/ICE 等操作的客户端。
- NAT：网络地址转换器，将内网地址/端口映射为公网地址/端口。
- Server‑Reflexive Address（srflx）：通过 STUN 服务器反射得到的“终端在外部看到的地址与端口”。
- Transaction（事务）：请求与响应的一次往返交互；由事务 ID 标识。
- Attribute（属性）：STUN 消息中的扩展字段，例如 XOR‑MAPPED‑ADDRESS、USERNAME、MESSAGE‑INTEGRITY 等。
报文结构（Message Structure）
- 报文头（20 字节）：
- Message Type（2 字节）：指示请求/响应类型（如 Binding Request / Binding Success Response / Binding Error）。
- Message Length（2 字节）：后续属性字段总长度（不含头部）。
- Magic Cookie（4 字节）：固定值 0x2112A442，用于与事务 ID 混合以防止被识别成其他协议。
- Transaction ID（12 字节）：随机数，标识一次事务。
- 属性（Attributes）：TLV 结构，常见属性如下。
常见属性（Attributes, 精选）
- XOR‑MAPPED‑ADDRESS：
- 携带客户端“对外可见的地址与端口”，用于 NAT 映射发现；采用与 Magic Cookie 或事务 ID 的 XOR 编码以防中间设备误处理。
- USERNAME：
- 用于认证（短期/长期凭证机制）。
- MESSAGE‑INTEGRITY：
- HMAC‑SHA1 校验字段，覆盖报文中选定头部与属性，保证完整性与认证（基于共享密钥）。
- REALM、NONCE：
- 与长期/短期凭证认证流程配合，服务端可要求客户端携带这两项重新请求（挑战/防重放机制）。
- FINGERPRINT：
- CRC32C 校验，便于快速检测损坏或避免被某些中间网络设备误识别为其他高层协议。
- ERROR‑CODE：
- 错误类型与原因说明（例如 401 未授权、438 Stale Nonce）。
基本流程（Base Protocol Procedures）
- 形成请求：客户端构造 Binding Request，设置事务 ID、必要的属性（USERNAME、MESSAGE‑INTEGRITY 等）。
- 发送：
- UDP 场景：直接向 STUN 服务器发送；
- TCP/TLS：以流式连接发送，适用于某些受限网络或策略环境。
- 接收与处理：
- Success Response：包含 XOR‑MAPPED‑ADDRESS（终端在外部看到的地址与端口）。
- Error Response：可能要求带上 REALM/NONCE 或提示凭证无效，客户端据此重试。
认证与完整性（Authentication & Integrity）
- 短期凭证（Short‑Term Credential）：
- ICE 场景常用；服务端下发临时用户名/口令，客户端用 MESSAGE‑INTEGRITY 完成 HMAC 校验，服务端验证成功后返回响应。
- 长期凭证（Long‑Term Credential）：
- TURN 场景常用；基于 REALM/NONCE 挑战与防重放，客户端带上 USERNAME、MESSAGE‑INTEGRITY 并遵循相应流程；服务端可返回 401/438 要求刷新或重试。
- 两者目的：既保证报文未被篡改，又识别请求主体（用于配额、计费与反滥用）。
DNS 发现与备用服务器（Discovery & Alternate‑Server）
- STUN 服务器可通过 DNS SRV/NAPTR/域名解析获得；规范提供了发现流程建议。
- Alternate‑Server：服务端可在错误响应中提供备用地址，客户端根据策略重定向以提升成功率。
与 NAT 穿越方案的关系（Usage in NAT Traversal）
- STUN 自身不是完整的穿越方案，而是工具：
- 在 ICE 中用于“候选收集、连通性检查与保活”；
- 在 TURN 中辅助认证与控制面交互（但实际媒体中继由 TURN 完成）。
- 关键结论：srflx 只提供“外部可见地址”，真正能打通需要“双方同时向彼此候选地址发送 Binding Request”（双向检查），在圆锥型 NAT 下打洞成功率高；对称 NAT 下常需回退到 TURN。
工程要点（Practical Notes）
- 选择 UDP 优先，必要时 TCP/TLS；
- 合理实现认证与完整性（短期/长期凭证）；
- 结合 ICE 的提名策略与 consent freshness 保持会话稳定；
- 配合企业网络策略（仅开放 80/443）时考虑使用 TLS 与端口 443 的 STUN/TURN 服务。
参考
- [0] RFC 5389 - Session Traversal Utilities for NAT (STUN): https://datatracker.ietf.org/doc/html/rfc5389