ICE-Lite 模式原理与 STUN 服务器角色分析
Mediasoup 不需要单独部署 STUN 服务器的核心原因在于其实现了 ICE-Lite（轻量级 ICE） 规范，这使其在公网部署时，服务器端能够省略传统 ICE-Full 流程中必需的 STUN 地址探测环节。以下是详细的技术解析：
1. ICE 模式对比：Full vs Lite
ICE 协议定义了两种 Agent 角色：Full Implementation 和 Lite Implementation。它们在 NAT 穿越中的职责和需求有本质区别：
| 特性 | ICE-Full 模式 | ICE-Lite 模式 (Mediasoup采用) |
|---|---|---|
| 角色定位 | 通信双方均为完整 ICE Agent，需进行对等连通性检查。 | 一端为完整 Agent（客户端），另一端为 Lite Agent（公网服务器）。 |
| STUN 服务器依赖 | 必需。双方都需要通过 STUN 服务器获取自身的公网反射地址（Server Reflexive Candidate）。 | 服务器端无需。Lite Agent 已知自身公网地址，无需向外部 STUN 发起探测请求。 |
| 连通性检查发起方 | 双方都主动发起 STUN Binding Request。 | 仅完整 Agent（客户端）发起请求；Lite Agent（服务器）仅被动响应。 |
| 候选地址收集 | 需收集 Host、Server Reflexive（通过STUN）、Relayed（通过TURN）等多种候选地址。 | Lite Agent 通常只需提供其公网 Host Candidate。 |
| 部署复杂度 | 高，需为所有端点配置 STUN 服务器。 | 低，公网服务器侧无需额外 STUN 设施。 |
2. Mediasoup 作为 ICE-Lite 的具体工作流程
当 Mediasoup 部署在拥有静态公网 IP 的环境中时，其内部处理 WebRTC 连接的步骤如下：
-
候选地址生成 ：
Mediasoup 在启动时绑定到公网 IP 和端口。在生成 SDP Offer/Answer 时，它直接将此公网地址作为 Host Candidate 写入
candidate属性。例如：sdpa=candidate:1 1 UDP 1685987327 203.0.113.25 40000 typ host此处的
203.0.113.25:40000即是服务器可直接路由的公网地址。 -
信令交换 ：
服务器通过信令通道（如 WebSocket）将包含此公网候选地址的 SDP 发送给客户端。
-
客户端（ICE-Full Agent）行为：
- 客户端收到 SDP 后，启动完整的 ICE 流程。
- 客户端会收集自己的候选地址，这通常包括：
- Host Candidate：本地 IP。
- Server Reflexive Candidate ：通过向一个独立的 STUN 服务器 发送
Binding Request获得。这是客户端获取其 NAT 后公网映射地址的关键步骤。 - （可选）Relayed Candidate：通过 TURN 服务器获得。
- 客户端根据 ICE 算法，开始向所有远程候选地址（即 Mediasoup 提供的公网地址）发送 STUN
Binding Request，以进行连通性检查。
-
Mediasoup（ICE-Lite Agent）的响应：
- 当 Mediasoup 收到客户端发来的
Binding Request时，它不会发起对客户端的检查请求。 - 它严格遵循 RFC 5389，构造并返回一个 STUN
Binding Response。此响应包含一个关键的XOR-MAPPED-ADDRESS属性。 XOR-MAPPED-ADDRESS的作用 ：该属性告知客户端"从我的网络视角看到的你的源地址是X.X.X.X:Y"。这个地址正是客户端经过 NAT 设备映射后的公网地址（即客户端的 Server Reflexive Candidate）。- 通过这一响应，客户端不仅确认了到服务器的通路是通的，更重要的是间接验证了它自己通过 STUN 服务器获取到的公网反射地址是正确且可用的。
- 当 Mediasoup 收到客户端发来的
3. 为何无需为服务器部署独立 STUN
基于以上流程，可以明确以下几点：
- 服务器无需自我探测：STUN 的核心功能是帮助位于 NAT 后的端点发现自己的公网映射地址。Mediasoup 服务器本身位于公网，其绑定的 IP 就是最终通信地址，不存在地址发现的需求。因此，它不需要向任何 STUN 服务器发送探测请求。
- 客户端仍需 STUN 服务 ：需要注意的是，客户端仍然需要一个 STUN 服务器 来获取自己的 Server Reflexive Candidate。这个 STUN 服务器可以是公共的（如
stun:stun.l.google.com:19302），也可以是自己搭建的。只是对于 Mediasoup 服务器这一端来说，不需要单独为其部署一个。 - STUN 协议的双重用途 ：在 ICE-Lite 模式下，STUN 协议在服务器侧的作用发生了转变。服务器不再将其用作地址发现工具 ，而是将其用作连通性检查与地址确认的响应协议 。客户端发来的
Binding Request同时充当了"心跳保活"和"触发服务器返回客户端公网地址"的双重角色。
4. 架构优势与典型场景
这种设计带来了显著的架构简化：
- 降低运维成本：减少了需要部署、监控和维护的网络组件（STUN 服务器）。
- 提升连接效率：客户端与媒体服务器直接进行 STUN 交互，减少了网络跳数，可能有助于降低初始连接延迟。
- 增强系统可靠性：媒体服务的可用性不再依赖于另一个外部服务（STUN 服务器）的可用性。
典型应用场景 ：
该模式完美契合以 Mediasoup、SRS 为代表的 SFU 架构。在这种架构中，中心化的媒体服务器部署在公网，负责接收并转发所有客户端的流。成千上万的客户端位于各式各样的 NAT 和防火墙之后。ICE-Lite 模式使得服务器能够以最精简的方式，高效协助每一个客户端完成 NAT 穿越。
总结
总而言之，Mediasoup 在公网环境下无需单独部署 STUN 服务器，根源在于其 ICE-Lite 实现 。服务器利用自身已知的公网地址直接作为候选地址，并通过被动响应客户端 STUN 请求的方式，在完成连通性检查的同时，向客户端反馈其所需的公网映射信息。这移除了服务器侧对 STUN 地址发现功能的依赖，从而实现了架构的简化和优化。