在 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作为一种后备选项是必不可少的。