为什么 WebRTC 需要远程端的本地 IP？
Why WebRTC needs the local IP of the remote peer?
当我们向某个 STUN 服务器发送请求时，我们会收到外部服务器看到的 IP:port 对。然后，我们在这个 "probability list of possible connection targets" 中包含浏览器绑定的本地 IP:port 对，并通过 WebRTC 网络将其发送到远程客户端（实际上，我从来没有完全理解 - 在哪一步或哪里用户 ID 被解析为它的 IP，并且远程客户端 IP 是从哪里知道的...？）。
但是为什么我们需要本地IP地址和端口呢？好吧，对于端口，我的解释是一些NAT防火墙可以配置为将相同的本地端口用于外部请求（仅重写IP），然后信息之类的信息可能会有用，但是这里需要IP吗？
浏览器看到的本地 IP 很可能是一个可行的连接选项。这就是包含它的原因。
评论中提到的link实际上显示了为连接生成的所有ICE候选。您的本地 IP 地址是最基本的 IP 地址，由浏览器自行添加。当你 运行 没有 STUN 的 webRTC 时，这就是你得到的一个候选者。但该地址很可能是真实 IP 或私有地址，并且在本地网络上可行。现在，如果它在 NAT 后面，浏览器就无法知道路由器的外部 IP - 这是 STUN 检测到的连接选项，同时在 NAT 中戳一个洞以进行连接。 （如果这不起作用，还有 TURN 服务器，它们也将显示为具有自己 IP 的 ICE 候选者。）
ICE 候选者本质上是另一端可能连接到的潜在地址列表。任何可检测到或可能有效的东西都包括在内，不仅是 STUN 响应或本地 IP。然后另一端使用这些来尝试建立实际的 media/data (RTP) 连接。
我不确定您所说的 "user ID" 是什么意思，但是必须通过单独的方法或信令层将这些 ICE 候选者提供给其他客户端。这就是实际连接的建立方式 - 确切的连接方式并未定义为 webRTC 的一部分，实际上可以是任何东西。流行的传输层是 websockets。本质上，在 webRTC 发挥作用之前，两个客户端必须已经以某种形式进行通信。
当我们向某个 STUN 服务器发送请求时，我们会收到外部服务器看到的 IP:port 对。然后，我们在这个 "probability list of possible connection targets" 中包含浏览器绑定的本地 IP:port 对，并通过 WebRTC 网络将其发送到远程客户端（实际上，我从来没有完全理解 - 在哪一步或哪里用户 ID 被解析为它的 IP，并且远程客户端 IP 是从哪里知道的...？）。
但是为什么我们需要本地IP地址和端口呢？好吧，对于端口，我的解释是一些NAT防火墙可以配置为将相同的本地端口用于外部请求（仅重写IP），然后信息之类的信息可能会有用，但是这里需要IP吗？
浏览器看到的本地 IP 很可能是一个可行的连接选项。这就是包含它的原因。
评论中提到的link实际上显示了为连接生成的所有ICE候选。您的本地 IP 地址是最基本的 IP 地址，由浏览器自行添加。当你 运行 没有 STUN 的 webRTC 时，这就是你得到的一个候选者。但该地址很可能是真实 IP 或私有地址，并且在本地网络上可行。现在，如果它在 NAT 后面，浏览器就无法知道路由器的外部 IP - 这是 STUN 检测到的连接选项，同时在 NAT 中戳一个洞以进行连接。 （如果这不起作用，还有 TURN 服务器，它们也将显示为具有自己 IP 的 ICE 候选者。）
ICE 候选者本质上是另一端可能连接到的潜在地址列表。任何可检测到或可能有效的东西都包括在内，不仅是 STUN 响应或本地 IP。然后另一端使用这些来尝试建立实际的 media/data (RTP) 连接。
我不确定您所说的 "user ID" 是什么意思，但是必须通过单独的方法或信令层将这些 ICE 候选者提供给其他客户端。这就是实际连接的建立方式 - 确切的连接方式并未定义为 webRTC 的一部分，实际上可以是任何东西。流行的传输层是 websockets。本质上，在 webRTC 发挥作用之前，两个客户端必须已经以某种形式进行通信。