IPFS网关问题 Web2和Web3之间的瓶颈

2019-04-19 15:28:10

1_D-bLbzR_C5Xt2oifuu8IIQ.png    


  什么是IPFS网关?

  IPFS网关是Web用户在不运行自己的IPFS节点的情况下检索IPFS网络上的内容的方式。网关允许Web客户端请求驻留在IPFS网络上的内容。

  通过访问通常格式如下的链接,可以从IPFS网关检索内容:https://gateway.pinata.cloud/ipfs/Qma6e8dovfLyiG2UUfdkSHNPAySzrWLX9qVXb44v1muqcp


  上面链接的“Qma6e8dovfLyiG2UUfdkSHNPAySzrWLX9qVXb44v1muqcp”部分是要求的内容标识符(CID)。重要的是要意识到用户可以通过访问任何公共网关来检索相同的图像,而不仅仅是Pinata运行的一个。例如,尝试在以下公共网关检索该CID:

  https://ipfs.io/ipfs/Qma6e8dovfLyiG2UUfdkSHNPAySzrWLX9qVXb44v1muqcp

  https://cloudflare-ipfs.com/ipfs/Qma6e8dovfLyiG2UUfdkSHNPAySzrWLX9qVXb44v1muqcp


  请注意如何从每个网关检索相同的图像?那是因为提供给每个网关的CID是相同的。当您访问每个网关时,它搜索IPFS网络,直到找到CID“Qma6e8dovfLyiG2UUfdkSHNPAySzrWLX9qVXb44v1muqcp”的内容。找到该内容后,网关会在您的Web浏览器中将其提供给您。


  网关在Web2和Web3之间提供了一个权宜之计。


  如果不使用IPFS网关,访问IPFS网络上内容的唯一方法是运行自己的IPFS节点。除非您有一个本地为每个用户运行IPFS节点的应用程序,否则使用IPFS的应用程序会在用户需要检索IPFS上的内容时将用户指向网关。

  IPFS的一个经常被认可的好处是它能够在从IPFS网络检索内容时提供类似CDN的功能。我在上一篇文章中谈到了这一点:IPFS云。

  您无需向IPFS网络提供正在检索的任何内容的位置(例如HTTP),而只需告诉IPFS节点“找到此CID的内容”。这意味着IPFS节点将从可以提供最快速度的任何节点检索内容。


  网关为什么会出现问题?

  当IPFS节点检索内容时,该内容临时缓存在接收节点上。随着越来越多的节点请求该内容,可以快速检索该内容的速度。不幸的是,IPFS网关否定了这一好处。使用网关检索内容时,会在IPFS检索过程中引入重大延迟。


1.png

 

  在上图中,假设用户和具有内容的节点位于同一城市,并且网关位于完全不同的城市。绿色箭头表示成功请求并返回一段内容。红色箭头表示请求已经发出但节点没有所需的内容,因此没有返回任何内容。箭头的长度粗略地表示每个请求所花费的时间量。


  使用本地IPFS节点

  在第一个场景中,用户在其计算机上本地运行自己的IPFS节点。当用户从IPFS网络请求一段内容时,他们的节点将能够快速检索该内容,因为他们的节点与托管内容的节点位于同一城市。大!


  有了网关

  在第二种情况下,用户没有自己的本地IPFS节点。相反,用户必须要求网关为他们找到一段内容。然后,该网关将从最接近它的任何节点检索该内容,然后该内容将被发送回用户。

  重要的是要注意,在网关方案中,请求需要更长的时间。用户不必能够从最快的节点快速检索内容,而是必须联系网关,然后等待网关查找内容并检索它。这两个步骤都需要更长的时间,因为网关与请求用户和托管节点处于完全不同的城市。不是很好!


  通过利用网关在IPFS上检索内容,我们正在重新创建IPFS旨在破坏的相同Web2架构。


  除了直接在我们正在谈论的服务器上的数据之外,网关必须首先从IPFS网络检索内容,然后再将其提供给用户。

  当然,如果一段内容足够流行,网关节点可能会缓存该内容,以便将来的请求不会花费太长时间。但是,每次垃圾收集后的第一个请求仍会在内容检索中引起明显的延迟。


   2.png


 

  与服务器如何成为现代客户端/服务器体系结构的瓶颈类似,我们在检索IPFS上的内容时将网关变成了一个巨大的瓶颈。我们不是依靠许多不同的机器来请求和传递内容,而是强迫所有内容都通过一台机器运行。越来越多依赖单个网关检索内容的用户,网关越难满足需求。这带来了另一个困扰IPFS网关的问题。


  共同网关的悲剧

  与IPFS生态系统中的许多项目一样,Pinata拥有一个公共IPFS网关。我们主要这样做有两个原因:

  托管我们自己的网关让我们配置一些东西,以便Pinata用户始终可以快速地访问他们的内容。

  托管我们自己的网关有助于IPFS生态系统的整体发展。

  但是,这样做会引入一个问题:

  随着网关增加功能,IPFS网络更有可能使用网关。

  这方面的一个典型的例子是CloudFlare的网关其最近禁止视频流。目前尚不清楚为什么Cloudflare会把内容放下来。但是,很明显Cloudflare的公共网关产生的流量足以成为一个问题。这样的问题提出了一个有趣的问题:

  如何确保公共IPFS网关继续运行而不会出现问题?

  为了保持对用户的可靠服务,您必须增加网关以满足需求。但是,对于提供补贴整个网络的服务的公司而言,长期变得不可持续。如果您运行“最佳”公共网关,则会吸引公共用户选择您的网关而非其他人。更多不支付网关费用的用户意味着更多的开销。更多开销需要更多资源。很快你就会遇到“ 公地悲剧 ”的经典案例。

  解决此问题的一种方法是从网关中删除功能。这是Cloudflare选择采用的方法。在Cloudflare的案例中,它是有道理的,因为它们仅供用户在IPFS上托管自己的网站。它不打算用于视频流。

  接近它的另一种方法是限制对网关的访问。这是我们没见过的。但是,公司有可能将其网关限制在用户身份验证之后。通过这种设置,公司可以确保只有他们的用户会产生网关成本,并且可以调整他们的业务模型以准确地计算这些成本。


  没有IPFS网关的理想Web

  网关问题的理想解决方案非常简单。用户需要运行自己的节点而不是依赖公共网关。然而,使解决方案成为现实非常困难。

  尽管每个Web用户都可以从命令行下载IPFS并在其计算机上运行节点,但这可能不会发生。对于技术用户来说,这样的问题只是糟糕的用户体验。对于非技术用户,这种问题通常是不可能的。

  幸运的是,像Siderus Orion这样的项目与IPFS-Companion结合使得这个过程更加用户友好。但是,对于大多数公众来说,下载两个程序以消耗IPFS内容的麻烦是不值得的。还记得Flash内容消耗这么麻烦吗?世界转向HTML5内容是有原因的。

  这种麻烦的一个解决方案是使用IPFS直接在其Web应用程序中启动JS-IPFS节点的应用程序。这种方法允许开发人员隐藏幕后的所有IPFS技术内容,同时允许用户与IPFS网络进行交互,而不依赖于公共网关。卡森农民的纺织,写了一个关于如何包括JS-IPFS节点转变为网络应用伟大的教程。这种方法的主要缺点是您需要启动为每个使用IPFS的网站运行的新节点,这可能会导致性能问题。

  正如我在之前的文章中提到的,IPFS必须提供主要的浏览器支持才能真正成为Web协议。

  主要的Web浏览器支持将隐藏最终用户的IPFS,同时仍以优化的方式提供p2p Web体验的优势。由于IPFS仍然是一个年轻的协议,主要的浏览器支持需要时间。但是,如果我们想充分利用IPFS,那么它仍然需要努力。


  结论

  IPFS网关是IPFS的采用和可用性的桥梁。不幸的是,IPFS网关也否定了IPFS解决的一些主要好处。主要是,网关阻止用户从IPFS的对等性质中受益。

  解决方案是让更多用户运行自己的IPFS节点。但是,在考虑用户体验时,这变得非常具有挑战性。但是,仅仅因为某些事情具有挑战性并不会使其变得不可能 随着IPFS生态系统的不断发展,节点越来越接近用户,利用IPFS的知识差距继续缩小。


最新推荐