如何解决为什么 WebRTC 要求两个浏览器都生成连接信息?
所以我正在考虑使用 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)可以访问的生成的哈希值,您是否认为浏览器足够安全?
解决方法
不要将连接信息(ice 候选)与 SDP 混淆。 What are ICE Candidates and how do the peer connection choose between them?
如果您专门询问网络浏览器 - 那么是的,您必须从每个浏览器收集连接信息,与 SDP 无关。这是因为浏览器不会侦听特定的、众所周知的端口,该端口也在防火墙中打开。所以它不像一个浏览器可以使用众所周知的端点(IP:端口)连接到另一个浏览器。 这个想法是 Stun 服务器将在两个防火墙中钻孔,从而使浏览器之间的直接连接成为可能。阅读 STUN 规范以了解这是如何完成的。
但是,如果一个对等点是浏览器,而另一个对等点是您自己的监听特定端口(WebRTC 网关、媒体服务器)的应用程序,那么您不需要从浏览器收集连接信息(ice 候选)。没有人需要它。不涉及眩晕/转弯服务器。浏览器始终连接到您的应用程序。您可以在您的网页中对 ice 候选进行硬编码,其中将包含您的应用程序公开的端点。
您总是必须在两个对等方之间交换 SDP,因为它们携带编解码器信息和其他有关媒体流的信息,而另一个对等方需要了解这些信息。例如,浏览器需要同意他们可以解码传入的流。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。