参考：
Kavirajan ST : What is WebRTC and How to Setup STUN/TURN Server for WebRTC Communication?
Andrey B. ：Еnvironment: signaling, STUN and TURN servers
Meddane ： Demystifying NAT Traversal with STUN TURN and ICE
STUN
STUN 的唯一目的是让防火墙后面的设备在向外发送 UDP 流量时发现自己的 NAT 地址和端口。
两个客户端 通过 STUN 直到自己的公有 IP 和 端口后，直接点对点，不经过任何第三方进行媒体通信
TURN
STUN 仅适用于安全性较低的 NAT，即所谓的 完全锥形NAT（full-cone）。不能用于对称性 NAT，这时候就需要 TURN
两个客户端 通过 STUN 知道自己的公有 IP 和端口后，为了穿越防火墙，通过 TURN 进行媒体通信。
但TURN服务器成本较高，因为在建立更多客户端连接的情况下，服务器利用率和带宽占用量都很大。
完全锥形 NAT 和 对称 NAT
NAT
属于四层负载均衡（网络层负载均衡，改变 IP 地址）
- 客户端发送外部请求到NAT：数据包的目的IP和端口本来是这个NAT设备的。NAT 要修改目的IP和端口，使其为真实服务器地址，从而转发到服务器。
- 内部服务器通过NAT发送响应给客户端：这个数据包的源地址是服务器自己的IP和端口，一般都是内部地址，非公网IP。如果直接发送给客户端，客户端是不认识这个地址的，所以要将源地址由服务器地址改为NAT 均衡器地址。
完全锥型 NAT（full-cone），静态 NAT
来自【同一内部 IP 地址和端口的所有请求】都映射到同一外部 IP 地址和端口
对称 NAT（Symmetric），动态 NAT
从【同一内部 IP 地址和端口到特定目标 IP 地址和端口的所有请求】都映射到同一外部 IP 地址和端口。如果内部同一主机发送具有相同源地址和端口的数据包，但发送到不同的目的地，则使用不同的映射。此外，只有接收到数据包的外部主机才能将UDP数据包发送回内部主机。
为什么对称 NAT 不可以使用 STUN？
Jdoe --> Jsmith 共同的步骤
- jdoe 请求 Stun 服务器获取其自己的公共 IP 和端口 15.1.2.1:19222
- 通过 SDP INVITE 将 15.1.2.1:19222 发送给 jsmith
- 当被叫设备 jsmith 收到 INVITE 时，它会请求 Stun 服务器以获得自己的公共 IP 和端口 13.1.2.1:19999
- 然后被叫端点 jsmith 在 SDP 响应中包含此 NAT 化的 IP和端口 13.1.2.1:19999
信令完成后，两个端点都有各自的公共 IP 地址和端口，将用于建立 RTP 或媒体通信，并且它们可以开始连接检查阶段。
1、全锥NAT （full-cone）
- Jdoe 向 jsmith 的公共 IP 地址 13.1.2.1:19999 发送模拟音频媒体流量的 UDP 数据包（STUN 数据包）。该数据包经过 Jdoe 的防火墙进行 NAT 转换后，Jdoe 的内部源IP 改变为源地址 15.1.2.1:19222 （因为全锥形NAT，所以到 Jsmith 与到 STUN 是一样的IP和端口）。同时 Jdoe 的防火墙建立一个连接条目：Src: 15.1.2.1:19222 和 Dst: 13.1.2.1:19999
- 一旦该数据包到达 jsmith 的防火墙，就会被防火墙丢弃，因为它是从外部不可信区域发起到内部可信区域的。
- jsmith 也向 jdoe 的公共 IP地址 15.1.2.1:19222 发送模拟音频媒体流量的 UDP 数据包（STUN 数据包）。该数据包经过 jsmith 的防火墙进行 NAT 转换后， Jsmith 的内部源IP 改变为源地址 13.1.2.1:19999（因为全锥形NAT，所以到 Jsmith 与到 STUN 是一样的IP和端口）。
- 该数据包会被 jdoe 的防火墙允许，因为它是由 jdoe 发起的 Stun 数据包创建的现有连接的一部分，Jdoe 的防火墙已经添加了这个连接条目 Src: 15.1.2.1:19222 和 Dst: 13.1.2.1:19999。所以连接检查将成功。
2、对称NAT（Symmetric）
- Jdoe 向 jsmith 的公共 IP 地址 13.1.2.1:19999 发送模拟音频媒体流量的 UDP 数据包（STUN 数据包）。该数据包经过 Jdoe 的防火墙进行 NAT 转换后，Jdoe 的内部源IP 改变为源地址 15.1.2.1: 20200（因为对称 NAT，请求到 Jsmith 与请求到 STUN（15.1.2.1:19222） ，是不一样的源端口） 。同时 Jdoe 的防火墙建立一个连接条目：Src: 15.1.2.1:20200 和 Dst: 13.1.2.1:19999
- 一旦该数据包到达 jsmith 的防火墙，就会被防火墙丢弃，因为它是从外部不可信区域发起到内部可信区域的。
- jsmith 也向 jdoe 的公共 IP地址 15.1.2.1:19222 发送模拟音频媒体流量的 UDP 数据包（STUN 数据包）。该数据包经过 jsmith 的防火墙进行 NAT 转换后， Jsmith 的内部源IP 改变为源地址 13.1.2.1:19777（因为对称 NAT，请求到 Jdoe 与请求到 STUN （13.1.2.1:19999），是不一样的源端口）。
- 连接检查将失败，因为 jdoe 的防火墙期望接收具有与条目的连接表匹配的 L3/L4 信息 Src: 15.1.2.1:20200 和 Dst: 13.1.2.1:19999 的数据包。
交互式建立连接 Interactive Connectivity Establishment (ICE)
RFC 8445 中定义的交互式连接建立 (ICE) 是一个结合了 STUN 和 TURN 的框架。
ICE 在两个节点之间建立尽可能直接的连接。ICE 强制要求默认情况下使用 STUN，因为 TURN 通信需要连续使用 TURN 服务器，连接不是对等的，并且会使用更多的服务器资源。
- 如果它们之间可以直接连接，则会应用 STUN 协议。
- 如果无法实现直接媒体连接，端点将回退到 TURN 服务器并集中发送其 UDP 流量，而不是点对点。
- 通过 STUN 以发现端点的 NATed IP 和端口。
- Turn 发现 ：Turn 服务器的中继公共 IP（例如 Expressway-E（Cisco的））
- 发现最佳 RTP 路径，或者在端点之间直接 RTP 流（如果使用专用公共 IP），或者通过中继转向服务器（例如 Expressway-E（Cisco的）），或者通过传统 RTP 流（例如，对于 MRA 端点通过 Expressway-C）
