我对 webrtc 的 STUN 服务器的理解是，当客户端在 NAT 之后（在大多数情况下，如果不是全部），STUN 服务器将帮助 webrtc 客户端识别它们的地址和端口。我还阅读了一些文章，说 webrtc 客户端需要一个信令服务器。信令服务器可以是 Web 服务器、socket.io，甚至可以通过电子邮件发送 url。我的第一个问题是：STUN 服务器是信令服务器吗？
实际上，现在我构建了一个非常简单的基于 socket.io 的服务，它将客户端的会话描述广播给所有其他客户端。所以我相信基于socket.io的服务器应该对客户端的地址和端口信息有足够的了解。如果是这种情况，我们为什么还要费心拥有另一个 STUN 服务器？
【问题讨论】：
STUN 服务器不是信令服务器。
信令服务器的目的是在会话开始时在对等方之间传递信息（他们如何在不知道发送给谁的情况下发送报价？）。此信息包括在报价和答案上创建的 SDP，以及任何一方创建的任何 Ice Candidate。
拥有 STUN 服务器的原因是两个对等方可以相互发送媒体。媒体流不会到达您的信令服务器，而是直接到达另一方（点对点连接的定义），使用 TURN 服务器的情况除外。
媒体不能神奇地通过 NAT 或防火墙，因为双方不能直接访问对方（就像他们在同一个 LAN 上一样）。
简而言之，当双方不在同一个网络上时（为了获得对等媒体流的有效连接候选）并且信令服务器总是，大部分时间都需要 STUN 服务器/em> 需要（无论它们是否在不同的网络上）以便可以进行协商和连接建立。 Good explanation of the connection and streaming process
【讨论】：
STUN 用于实现 ICE 协议，该协议试图在两个客户端之间找到有效的网络路径。 ICE 还将使用 TURN 中继服务器（如果在 RTCPeerConnection 中配置）用于两个客户端（由于 NAT/防火墙限制）无法进行直接对等连接的情况。
STUN 服务器用于识别互联网上计算机使用的外部地址（NAT 外部地址），并尝试设置对等方可用的端口映射（如果 NAT 不是“对称的” ") -- 联系 STUN 服务器将告诉您尝试在 ICE 中使用的外部 IP 和端口。这些是包含在 SDP 或涓流 ICE 消息中的候选 ICE。
对于几乎保证的连接性，服务器应该有 TURN 服务器（最好支持 UDP 和 TCP TURN，尽管 UDP 是首选）。请注意，与 STUN 不同，TURN 可以使用可观的带宽，因此托管可能需要花钱。幸运的是，大多数连接都无需使用 TURN 服务器即可成功（即它们运行点对点）
【讨论】：
NAT（网络地址转换）用于将仅在局域网中有效的“私有IP”转换为在广域网中有效的“公共IP”。 问题是“公共 IP”只能从外部看到，所以我们需要 STUN 或 TURN 服务器将“公共 IP”发回给您。 这个过程使 WebRTC 对等点能够为自己获取一个可公开访问的地址，然后通过信号机制将其传递给另一个对等点
STUN 服务器用于获取外部网络地址。 如果直接（对等）连接失败，TURN 服务器用于中继流量。 更多内容也可以参考以下链接：https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#what-is-signaling
【讨论】：
在你的情况下，你需要 STUN。大多数客户端将在 NAT 之后，因此您需要 STUN 来获取客户端的公共 IP。但是如果你的两个客户端都不在 NAT 之后，那么你就不需要 STUN。更一般地说，不，STUN 服务器不是严格要求。我知道这一点是因为我成功连接了 2 个没有 stun 服务器的 WebRTC 对等体。我使用了来自 aiortc 的example code，这是一个 python WebRTC/ORTC 库，两个客户端都在我的笔记本电脑上本地运行。信令通道使用了我的手动复制粘贴。我从字面上将 SD（会话描述）从一个对等方复制到另一个对等方。然后，再次将 SD 从 2nd peer 复制到 1st peer。
来自 WebRTC 使用的 ICE RFC (RFC8445)
ICE 代理应该收集服务器自反和中继的候选人。 但是，在某些情况下，使用 STUN 和 TURN 服务器可能不必要 网络和 TURN 服务器的使用可能很昂贵，因此有些 部署可以选择不使用它们。
不清楚 STUN 是 ICE 的要求，但上面说它可能是不必要的。
但是，信号与它无关。这个问题实际上源于不了解STUN 的作用，以及STUN 如何与信号交互作用。我认为这里的其他 3 个答案实际上并没有回答这两个问题。
先决条件：了解 NAT 的基本概念。 STUN 是一个绕过 NAT 的工具，所以你必须了解它。
信令：简而言之，在 WebRTC 中，您需要实现自己的信令策略。您可以在另一个对等点中手动键入一个对等点创建的本地会话描述，使用 WebSockets、socket.io 或任何其他方法（我看到一个可以使用 smoke 信号 的笑话，但是如何您将通过烟雾信号传递以下会话描述（又名。SDP message）。同样，我复制粘贴了与下面非常相似的内容：
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
当两个对等点不在 NAT 之后，您不需要 STUN 服务器，因为 IP 地址位于会话描述中（上面的 c= 字段，称为 connection data）每个对等点生成的数据足以让每个对等点相互发送数据报或数据包。在上面的示例中，他们提供了域名而不是 IP 地址， host.anywhere.com，但这可以解析为 A 记录。 （研究 DNS 以获得更多信息）。
在这种情况下，您为什么不需要 STUN 服务器？来自 RFC8445：
有不同类型的候选人；有些是从物理或逻辑网络接口派生的，有些是通过 STUN 和 TURN 发现的。
如果您不使用 NAT，客户端已经知道对等方可以直接寻址的 IP 地址，因此 STUN 生成的额外 ICE 候选将没有帮助（它只会为您提供您已经知道的相同 IP 地址大约）。
但是当客户端在 NAT 之后，他们认为他们不会帮助对等点联系他们的 IP。就像告诉你我的 IP 地址是 192.168.1.235，它确实是，但它是我的私有 IP。 NAT 可能在路由器上，您的客户端可能无法请求公共 IP。所以 STUN 是处理这个问题的工具。具体来说，
它为端点提供了一种方法来确定与其私有 IP 地址和端口相对应的 NAT 分配的 IP 地址和端口。
STUN 基本上是让客户端找出 IP 地址。如果您从笔记本电脑托管《使命召唤》服务器，并在路由器设置中将端口转发到您的计算机，您仍然需要从https://whatismyipaddress.com/ 之类的网站查找您的公共 IP 地址。 STUN 允许客户端自己完成此操作，而无需您访问浏览器。
最后，STUN 如何与信号相互作用？ ICE 候选者是在本地生成的，并且在 STUN 的帮助下（当他们在 NAT 之后获取客户端公共 IP 地址）甚至 TURN。会话描述使用信令通道发送到对等体。如果不使用 STUN，您可能会发现 ICE 尝试生成的 ICE 候选者都失败，并且连接（信令通道除外）没有成功创建。
【讨论】：