当我们向某个STUN服务器发送请求时，我们会收到我们的IP：端口对，因为外部服务器会看到它。然后，我们在这个＆＃34;可能的连接目标＆＃34;的概率列表中包含我们的本地IP：端口对，并通过WebRTC网络将其发送到远程客户端（实际上，我从未完全理解 - 在哪个步骤或用户ID被解析为它的IP以及远程客户端IP已知的地方......？）。
但为什么我们需要本地IP地址和端口？那么，对于端口，我的解释是，一些NAT防火墙可以配置为将相同的本地端口放入外部请求（仅重写IP），然后信息就像有用一样，但这里需要IP？
答案 0 :(得分：4)
浏览器看到的本地IP很可能是一个可行的连接选项。这就是它的原因。
评论中提到的链接实际上显示为连接生成的所有ICE候选项。您的本地IP地址是最基本的IP地址，浏览器自行添加。这是您在没有STUN的情况下运行webRTC时获得的候选人。但是，该地址很可能是真正的IP或私有的，并且在本地网络上是可行的。现在，如果它位于NAT之后，浏览器无法知道路由器外部IP - 这是STUN检测到的连接选项，同时在NAT中为连接戳一个洞。 （如果这不起作用，还有TURN服务器，它们也会显示为具有自己IP的ICE候选者。）
ICE候选人本质上是另一端可能连接到的潜在地址列表。包括任何可检测或可能工作的东西，不仅包括STUN响应或本地IP。然后另一端使用这些来尝试建立实际的媒体/数据（RTP）连接。
我不确定“用户ID”是什么意思，但是这些ICE候选者必须通过单独的方法或信令层提供给其他客户端。这就是实际连接的方式 - 如何完成这项工作并不是定义为webRTC的一部分，而且可以真正做到。流行的传输层是腹板。基本上，在webRTC发挥作用之前，两个客户必须已经以某种形式进行通信。