我对 webrtc 的 STUN 服务器的理解是，当客户端位于 NAT 之后（在大多数情况下，如果不是全部），STUN 服务器将帮助 webrtc 客户端识别它们的地址和端口。我还阅读了一些文章，说 webrtc 客户端需要一个信令服务器。信令服务器可以是 Web 服务器、socket.io，甚至可以通过电子邮件发送 url。我的第一个问题是：STUN 服务器是信令服务器吗？
实际上，现在我构建了一个非常简单的基于 socket.io 的服务，它将客户端的会话描述广播给所有其他客户端。所以我相信基于socket.io的服务器应该对客户端的地址和端口信息有足够的了解。如果是这样的话，我们为什么还要费心拥有另一个 STUN 服务器呢？
STUN 服务器不是信令服务器。
信令服务器的目的是在会话开始时在对等方之间传递信息（他们如何在不知道发送给谁的情况下发送报价？）。此信息包括在报价和答案上创建的 SDP，以及任何一方创建的任何 Ice Candidates。
拥有 STUN 服务器的原因是两个对等方可以相互发送媒体。媒体流不会到达您的信令服务器，而是直接到达另一方（点对点连接的定义），使用 TURN 服务器的情况除外。
媒体不能神奇地通过 NAT 或防火墙，因为双方不能直接访问对方（就像他们在同一个 LAN 上一样）。
简而言之，当两方不在同一个网络上（以获得对等媒体流的有效连接候选者）时，大部分时间都需要 STUN 服务器，并且总是需要一个信令服务器（无论它们是否在不同的网络与否），以便可以进行协商和连接建立。连接和流式处理过程的良好解释
STUN 用于实现 ICE 协议，该协议试图找到两个客户端之间的工作网络路径。ICE 还将使用 TURN 中继服务器（如果在 RTCPeerConnection 中配置）用于两个客户端（由于 NAT/防火墙限制）无法建立直接对等连接的情况。
STUN 服务器用于识别互联网上计算机使用的外部地址（NAT 外部地址）并尝试设置对等方可用的端口映射（如果 NAT 不是“对称”的） - - 联系 STUN 服务器将告诉您尝试在 ICE 中使用的外部 IP 和端口。这些是包含在 SDP 或涓流 ICE 消息中的 ICE 候选者。
对于几乎保证的连接性，服务器应该有 TURN 服务器（最好支持 UDP 和 TCP TURN，尽管 UDP 是首选）。请注意，与 STUN 不同，TURN 可以使用可观的带宽，因此托管可能需要花钱。幸运的是，大多数连接都无需使用 TURN 服务器即可成功（即它们运行点对点）
NAT(Network Address Transformation) 用于将只在局域网中有效的“Private IP”转换为在WAN中有效的“Public IP”。问题是“Public 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 的示例代码，这是一个 python WebRTC/ORTC 库，两个客户端都在我的笔记本电脑上本地运行。信令通道使用了我的手动复制粘贴。我从字面上将 SD（会话描述）从一个对等方复制到另一个对等方。然后，再次将 SD 从第二个对等体复制到第一个对等体。
来自 WebRTC 使用的 ICE RFC (RFC8445)
ICE 代理应该收集服务器反射和中继的候选人。但是，在某些网络中可能不需要使用 STUN 和 TURN 服务器，并且使用 TURN 服务器可能很昂贵，因此某些部署可能会选择不使用它们。
不清楚 STUN 是 ICE 的要求，但上面说它可能是不必要的。
然而，信号与它无关。这个问题实际上源于不了解STUN 做什么，以及STUN 如何与信号相互作用。我认为这里的其他 3 个答案实际上并没有回答这两个问题。
先决条件：了解 NAT 的基本概念。STUN 是一个绕过 NAT 的工具，所以你必须了解它。
信令：简而言之，在 WebRTC 中，您需要实现自己的信令策略。您可以在另一个对等点中手动键入一个对等点创建的本地会话描述，使用 WebSockets、socket.io 或任何其他方法（我看到一个可以使用烟雾信号的笑话，但是您将如何通过以下会话描述（又名。SDP 消息）通过烟雾信号...）。同样，我复制粘贴了与下面非常相似的内容：
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 服务器，因为位于每个对等点生成的会话描述（c=上面的字段，称为连接数据）中的 IP 地址足以让每个对等点发送数据报或数据包相互。在上面的示例中，他们提供了域名而不是 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 是处理这个问题的工具。具体来说，
它为端点提供了一种方法来确定由 NAT 分配的与其私有 IP 地址和端口相对应的 IP 地址和端口。
STUN基本上让客户端找出IP地址是什么。如果您从笔记本电脑托管使命召唤服务器，并在路由器设置中将端口转发到您的计算机，您仍然需要从https://whatismyipaddress.com/之类的网站查找您的公共 IP 地址。STUN 允许客户端为自己执行此操作，而无需您访问浏览器。
最后，STUN 如何与信令相互作用？ ICE 候选者是在本地生成的，并在 STUN 的帮助下（当它们位于 NAT 之后时获取客户端公共 IP 地址）甚至 TURN。会话描述使用信令通道发送到对等体。如果您不使用 STUN，您可能会发现 ICE 尝试生成的 ICE 候选都失败，并且连接（信令通道除外）没有成功创建。