【问题标题】:How would one connect two clients (one of them is browser) behind firewalls如何在防火墙后面连接两个客户端(其中一个是浏览器)
【发布时间】:2012-11-29 06:06:35
【问题描述】:

我知道像 Skype 这样的 p2p 软件正在为此使用 UDP 打孔。但是,如果其中一个客户端是需要从另一个客户端下载文件的 Web 浏览器(TCP 连接而不是 UDP)怎么办?这种情况有什么技术吗?

我可以有一个中间公共服务器,它可以与客户端结婚,但我无法承受这些客户端之间的所有流量都通过这个服务器。公共服务器只能在客户端之间建立连接,就像 Skype 一样,仅此而已。这必须通过 TCP(更准确地说,HTTP)才能让下载客户端成为 Web 浏览器。

不得要求两个客户端在他们的路由器中设置任何东西或类似的东西。

我打算用 C/C++ 编写这个代码,但我想知道这个想法是否可行。

【问题讨论】:

  • 库 stunovertcp 看起来很有希望,我去看看。
  • 无耻插件 - 使用特技演员。它积极支持并支持 STUN 的多种配置,包括 TCP。 www.stunprotocol.org
  • 谢谢。还有一个问题——如果只有一方知道所有这些 STUN 的东西,是否有可能(至少在理论上)使用它?在我的情况下,我有一个具有专用 IP 地址的服务器对等服务器和公共服务器,它知道通信的细节,而第 3 方(客户端下载文件)是通过 HTTP 工作的常规浏览器。在这种情况下可以使用 STUN 吗?或者,它假设所有各方都必须通过此协议进行通信?

标签: p2p nat upnp portforwarding


【解决方案1】:

我之前写了一个关于 P2P 大致如何工作的非常综合的粗略答案,并讨论了各种协议和相应的开源库。您可以阅读它here

P2P 的可靠性最终取决于您从客户端编码角度和服务配置(即信令服务器和中继)的角度对它进行了多少投资。您可以在没有防火墙支持的情况下满足 UDP 的简单 NAT 穿越。也许再努力一点,您就会获得 TCP 连接。而且你可以“一路”,让中继具有 HTTPS 侦听器,供最难穿越的防火墙后面的客户端使用。

关于您关于防火墙的问题的答案。取决于防火墙的配置方式。许多防火墙只是具有安全性的美化 NAT,可将流量限制到某些端口并阻止未经请求的传入连接。其他的则非常严格,只允许通过代理进行 HTTP/HTTPS 流量。

如果无法直接连接,视频会议应用最终将回退到通过 PC 配置的代理服务器模拟 HTTPS 连接到远程中继服务器的端口 443(或 80)。 (并且在某些情况下,远程客户端会尝试侦听端口 80 或端口 443,以便直接连接)。

您完全正确地认为,让所有客户端都通过中继的维护成本很高。如果您的目标是 100% 连接,无论客户端使用哪种类型的防火墙,都必须存在一些中继解决方案。如果您不支持中继解决方案,您可以投入大量资金让直接连接可靠地工作,并且只阻止一小部分客户端。

希望这会有所帮助。

【讨论】:

  • 谢谢,只有一个问题(与其他评论者相同)。当其中一个对等点只是一个不了解 STUN、TURN 等知识的 HTTP 浏览器时,这(至少在理论上)可以工作吗?因为在这种情况下,让客户端成为常规浏览器是必须的(另一个必须是实际的文件流量不能通过公共服务器中继,至少在大多数情况下)。如果不可能,那么深入研究如何遍历 NAT 的细节将是浪费时间,因为我不想再制作另一个 p2p 应用程序。如果接收方不能是网络浏览器,那就完蛋了。
  • 嗯......我正要输入“可能不是”,但后来我想到了这个。浏览器可能会访问一个 Web 服务,该服务使用 30x 消息重定向浏览器以连接到模拟 Web 服务器的远程对等点。但这将是穿越远程对等方的 NAT 的挑战。浏览器可能会为每个后续连接选择不同的本地 tcp 端口……这使得很难通过另一端的 NAT……所以“可能不会”。 :( 你试图实现的场景是什么?
  • 顺便说一句,我不介意有两台公共服务器的情况,其中第一台服务器是集合点,而第二台服务器(驻留在另一个网络中)用于测试是否可以建立与发送对等方的连接(打孔步骤)。当连接成功时,获得的设置(端口和 IP)可以传递给接收方(这是一个不能打孔的网络浏览器,因此需要一些帮助)。当然,这假设接收方可以使用与第二个公共服务器相同的端点来连接发送方。不确定它是否可以工作。
  • 谢谢,你的速度很快!我的目标是让一个只有网络浏览器的人从他们的本地计算机下载另一个人共享的文件,而不需要中继(最好是通过任何公共资源的文件流量)。
  • 我认为这不会起作用,除非提供文件的主机在公共互联网上而不是在 NAT 后面。第二个服务器可以检测是否可以连接,但不太可能执行打孔步骤,因为它的 IP 与尝试连接的浏览器客户端完全不同。
【解决方案2】:

PeerConnectionWebRTC 的一部分在现代浏览器中解决了这个问题。

在底层它使用ICE,这是一个用于 NAT 打孔的RFC

对于较旧的浏览器,可以在 Flash 中使用 P2P 支持。

【讨论】:

    猜你喜欢
    • 2010-11-21
    • 2011-01-02
    • 2022-06-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-11-27
    • 2021-12-18
    • 1970-01-01
    相关资源
    最近更新 更多