STUN，TURN，ICE，WebRTC

参考：

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 共同的步骤

1. jdoe 请求 Stun 服务器获取其自己的公共 IP 和端口 15.1.2.1:19222
2. 通过 SDP INVITE 将 15.1.2.1:19222 发送给 jsmith
3. 当被叫设备 jsmith 收到 INVITE 时，它会请求 Stun 服务器以获得自己的公共 IP 和端口 13.1.2.1:19999
4. 然后被叫端点 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）