为什么 WebRTC 需要两个浏览器来生成连接信息？

Question

所以我正在研究使用 WebRTC 构建游戏，主要是为了学习如何使用 WebRTC。我在脑海中设想的是一个浏览器（我们称之为 Alice）想要开始游戏。他们找出他们的连接信息，然后将该信息发送到他们想要加入他们的游戏的另一个浏览器 (Bob)。我喜欢类似于不和谐邀请的链接的想法。

我的想象是，这就是所需要的一切。 Bob 的浏览器知道 Alice 在哪里，并且 Alice 期待知道他们的连接信息（他们的 SDP）的人的连接。相反，Bob 需要生成他自己的连接信息（他的 SDP），然后以某种方式将其交还给 Alice。 （作为参考，这里是一个“无服务器”WebRTC 客户端的实现，它要求双方将他们的连接信息传递给另一个人https://github.com/lesmana/webrtc-without-signaling-server）

因为有两条必需的消息，告诉用户手动执行此操作非常痛苦，并且随着更多用户（例如 Alice、Bob 和 Charlie想要连接）变得越来越困难。出于这个原因，我们有处理这种握手的“信号服务器”。

我的问题是为什么所有这些都是必要的？是为了安全吗？如果他们的 SDP 信息包含只有他们期望的人（如 Bob）才能访问的生成的哈希，你难道不能认为浏览器足够安全吗？

Answer 1

不要将连接信息（ice 候选）与 SDP 混淆。 What are ICE Candidates and how do the peer connection choose between them?

如果您专门询问网络浏览器 - 那么是的，您必须从每个浏览器收集连接信息，与 SDP 无关。这是因为浏览器不会监听特定的、众所周知的端口，该端口也在防火墙中打开。所以它不像一个浏览器可以使用众所周知的端点（IP：端口）连接到另一个浏览器。 这个想法是 Stun 服务器将在两个防火墙上钻一个洞，从而使浏览器之间的直接连接成为可能。阅读 STUN 规范以了解这是如何完成的。

但是，如果一个对等点是浏览器，而另一个对等点是您自己的应用程序，它侦听特定端口（WebRTC 网关、媒体服务器），那么您不需要从浏览器收集连接信息（ice 候选对象）。没有人需要它。不涉及 Stun/Turn 服务器。浏览器始终连接到您的应用程序。您可以在您的网页中对 ice 候选者进行硬编码，该网页将包含您的应用程序公开的端点。

您总是必须在两个对等方之间交换 SDP，因为它们携带编解码器信息和其他有关媒体流的信息，而其他对等方需要知道这些信息。例如，浏览器需要同意它们可以解码传入的流。