在 WebRTC 中，STUN（Session Traversal Utilities for NAT）和 TURN（Traversal Using Relays around NAT）是用于NAT穿透的两种不同的技术，它们解决的问题不同，因此在某些情况下需要同时使用。

STUN（Session Traversal Utilities for NAT）

STUN 是一个协议，它允许位于 NAT（网络地址转换）后面的设备发现它们的公网IP地址和端口号。STUN 服务器位于公网上，能够告诉客户端它从外部世界看起来的公网IP地址和端口号, 以便客户端可以直接与其他客户端通信。这通常被用于P2P（点对点）通信，使得两个位于不同NAT后面的设备能够直接通信。

但是，STUN不是万能的。有些类型的NAT，特别是对称型NAT（Symmetric NAT），对于每一个不同的外部目标地址和端口会分配一个不同的端口号。这意味着，即使STUN能够发现出口端口号，但因为每个连接都有不同的映射，所以两个位于对称型NAT后面的设备无法直接建立P2P连接。

TURN（Traversal Using Relays around NAT）

TURN 是为那些不能通过STUN建立直接通信的情况设计的。TURN服务器充当中继，所有数据都通过这个中继服务器转发。当STUN失败时，TURN可以用来确保通信仍然可能进行，尽管它可能会增加延迟和带宽成本，因为所有的数据都需要通过中继服务器。

简而言之，TURN是一种备用方案。当两个设备不能通过STUN直接通信时（比如当它们都位于对称型NAT后面时），它们可以使用TURN服务器作为中继来通信。TURN服务器在WebRTC中尤其重要，因为它提供了一种保证连接建立的方式，即使在最严格的NAT环境下也能工作。

结合使用 STUN 和 TURN

在实际的WebRTC应用中，通常会先尝试使用STUN来建立直接的P2P连接，因为这样通信效率更高，延迟更低，成本也更低。如果STUN尝试失败，应用程序会回退到使用TURN服务器。在WebRTC的ICE（Interactive Connectivity Establishment）框架中，这个过程是自动进行的。

因此，尽管STUN在很多情况下足以建立连接，但为了确保可靠性，TURN作为一种后备选项是必不可少的。

参考：STUN, TURN, ICE介绍-阿里云开发者社区

TURN与STUN的区别、实施条件 - 哔哩哔哩

实际中的WebRTC：STUN，TURN以及信令（五） | WebRTC中文网-最权威的RTC实时通信平台