如何利用IPFS的bitwap协议来加快文件传输速度

2020-11-09 16:03:27

作为ResNetLab研究工作的一部分,除了交换位之外,我们还致力于提高文件传输的速度,我们为IPFS Bitswap协议做出了新的贡献。

  作为ResNetLab研究工作的一部分,除了交换位之外,我们还致力于提高文件传输的速度,我们为IPFS Bitswap协议做出了新的贡献。我们认为,Bitswap当前正在丢弃大量可用于其利益的信息,从而提高了检索成功率并最小化了检索内容的等待时间。您也可以在此处阅读我们的上一篇文章,该文章针对libp2p流的压缩。

  每项研究工作都始于对现有技术的全面分析。最初的努力为以后的工作奠定了基础。为了在ResNetLab上提高P2P网络中文件传输的速度,我们正在做的不同工作是,除了为您提供结果以及如何从中受益之外,我们还希望从状态的角度指导您遵循为实现这些改进所遵循的过程最先进的方法,通过构想和原型制作进行评估。我们想通过记录我们如何原型化和评估第一次升级来说明此过程,该过程将获取流行内容的时间缩短了约25%,并将Bitswap中交换的控制消息的数量减少75%。换句话说,追求结果,坚持科学的方法论和评估的可重复性,这样您就可以学习如何实现自己的变化!


贡献

  IPFS的Bitswap协议当前会丢弃来自其连接对等方的许多有用信息,例如那些对等方正在寻找的块。我们的假设是,如果我们使用丢弃的信息来告知自己有关网络状态的信息,我们将能够执行更快的内容发现,从而减少传输时间。

  通过在新数据结构(我们在此引入,我们称为对等块注册表)中保留关于哪个对等方请求哪些块的信息,我们现在可以高精度地猜测哪些节点具有哪些内容。假设是,如果节点正在寻找某物,则它可能找到了。

  用从对等方接收到的WANT消息中提取的数据填充对等方块注册表。通过这种技术,我们可以看到更快的交付速度,尤其是在内容随着时间而越来越流行的情况下

  另外,我们能够最大程度地减少bitwap消息的开销。我们修改了Bitswap第一回合泛洪机制,以仅在碰巧有CID的对等方发送WANT消息。根据我们的假设,WANT消息的接收者将拥有内容并立即传输相应的块,从而节省了所有其他节点的宝贵带宽。另一方面,如果该节点不再具有该内容,则Bitswap将退回到其正常操作(广播WANT消息,直到找到包含该内容的提供者为止)。

  这一新方案显示出令人鼓舞的结果,将发现和传输流行内容(以前由网络中的其他节点请求)所需的时间减少了一个RTT,并将网络中交换的消息量减少了多达75%。


方法论

建立我们的理解并找出局限性

  我们首先对以前的学术工作中在P2P网络中围绕文件共享所做的工作进行了彻底的分析。然后,我们评估了现有P2P网络上现有内容交换协议的当前瓶颈和局限性:在我们的案例中分别是Bitswap和IPFS。

  我们发现,Bitswap执行的内容发现是次优,盲目的和确定性的。当请求文件时,Bitswap执行DHT内容路由查询,并向其所有连接的对等方发送乐观的WANT消息。没有使用网络中发生的先前事件的信息来智能地指导此发现。

  我们知道我们可以做得更好。我们假设可以使用网络中的某些信息来做出更明智的决策,并提高内容发现的效率。后来,我们遇到了这份与切线相关的论文,作者建议检查来自对等方的请求,以识别出未充分报告所存储内容的节点(即有意不宣布其存储的内容)。这个简单的概念启发了我们进行原型设计和评估的RFC,从而使我们对IPFS中的文件共享进行了首次改进。

  前述论文中的节点侦听请求以发现报告不足的对等节点;我们可以使用相同的原理来跟踪来自同行的Bitswap的WANT消息。这样,无论何时我们想要其他人之前已请求的内容,而不是从头开始轮询整个网络,我们首先会询问先前已请求该CID的节点,因为它们很可能拥有该内容。


编制RFC和原型

  我们已经起草了RFC BBL104,以便任何人都可以为改进建议的设计和评估计划做出贡献。为了构建原型,我们分叉了go-bitswap并应用了必要的更改。您可以在RFC中阅读其体系结构的详细信息。摘要是:

  •Bitswap跟踪收到的每条WANT消息并更新对等块注册表,该注册表是此RFC中引入的一种全新数据结构,并已原型进行评估。对等块注册表将节点看到的每个CID映射到最近已请求此特定CID的对等体。

  •然后,Bitswap会话将使用此信息来指导其内容搜索。每当对等方需要CID时,如果该CID的对等方块注册表中已填充了已请求该内容的对等方,则不会向其所有已连接的对等方广播WANT-HAVE消息,而只会向n个节点发送WANT-BLOCK对等体块注册表的最新对等体(默认实现中为n = 3)。

  •如果联系的对等方具有内容,则他们将立即以相应的块响应WANT-BLOCK,而如果不是这种情况,他们将回答DONT_HAVE,然后对等方将向其所有连接的WANT_HAVE广播。同行。

  该方案的预期影响如下:到第一个块的时间(即,到第一个字节的时间-TTFB)将从至少两个RTT减少为一个:如果WANT_BLOCK用内容击中了同位体,它将直接用内容,而没有用内容击中同伴的惩罚将只是一项RTT。

1109-2-1.png


评估计划和结果

  我们的目标用例是随着时间的流逝越来越流行的数据集的转移。我们设计了一个实验,随着时间的推移,有30个不同的leecher IPFS节点从网络中提供它的单个种子IPFS节点请求下面的XKCD映像(大小为49 KB)。


1109-2-2.png


  为了模拟流行内容的请求,水手们会定期以5秒钟的2次浪潮请求内容。这会导致下一组leecher已从先前的leechers收到WANT消息的情况,因此可以假定这些节点具有他们要查找的文件。


使用标准Bitswap的结果

  对于Bitswap的基准实施,第一次检索是最慢的,因为只有播种者才具有内容。对于接下来的浪潮,除了原始播种者之外,还已经有多个节点具有内容,因此,当水cher虫广播他们的WANT-HAVE时,它们具有较高的命中具有所请求内容的节点的可能性。

  尽管碰到了包含内容的节点,但Bitswap的原始实现所要求的获取内容的最小RTT数量是两个:一个用于WANT-HAVE广播,另一个用于使用WANT-BLOCK显式请求内容。

1109-2-3.png


在Bitswap上启用对等块注册表的结果

  对于使用WANT消息检查机制对Bitswap进行的改进实现,可以大幅度减少获取内容的时间,从而可以减少流行内容的首次发布时间。为什么是这样?

  就像基线实验一样,第一批水手不了解内容在哪里,因此他们唯一能做的就是广播WANT-HAVE,找到播种者,并请求内容。但是,对于随后的浪潮,对等方一直在听其他对等方在网络中交换的WANT消息,因此在向每个连接的对等方广播WANT-HAVE之前,他们将向先前请求该内容的对等方发送乐观的WANT-BLOCK。如果幸运的话,他们将在单个WANT-BLOCK中命中内容并以相同的交互方式接收该块,从而减少了将内容获取到单个RTT的时间。


减少消息交换数量,节省带宽

  消息检查的使用除了对流行内容的获取时间有所改善以外,还有另一个有趣的结果:Bitswap节点交换的控制消息的数量大大减少了。在对等方块注册表中保留最近请求特定CID的对等方列表,可以传输乐观的WANT-BLOCK,而无需向所有连接的对等方广播WANT-HAVE。

  因此,交换的WANT消息的平均数量减少了33%,而WANT-HAVE的数量减少了75%。我们以交换的WANT块数量略微增加7%的代价获得了所有这些。

1109-2-4.png


1109-2-5.png

  没有不小的折衷就不会带来这种改进。我们正在从对等体块注册表向n个对等体发送乐观的WANT-BLOCK的事实,这些对等体可能具有内容(在默认实现中,n = 3),这意味着网络中交换的重复块的数量略有增加。

  在原始Bitswap实现中,将单个WANT-BLOCK发送给已回答该块的对等方,而在我们的原型中,我们发送三种不同的WANT-BLOCK消息,并在从对等方块注册表中选择接收方对等方时,他们所有人都可能有障碍。可以配置要发送到对等方块注册表中的对等方的WANT-BLOCK消息的数量,因此,如果我们要针对带宽使用进行优化,它甚至可以动态调整以平衡WANT消息节省和重复项之间的折衷。

1109-2-6.png


播放较大的文件

  在前面提到的所有实验中,我们都使用了可放在单个块中的文件。我们开始怀疑如果交换更大的文件会对原型产生什么影响。我们使用相同的配置但使用不同的文件大小重复了该实验,并获得了如下所示的结果:

1109-2-7.png

  除了减少实验中交换的消息数量(尤其是小文件)之外,我们还得出了另一个有趣的结果。正如我们最初所认为的那样,使用对等块注册表执行更智能的内容查找实际上并没有增加网络中重复块的数量,而是减少了它。在我们的初始实验中,我们交换了一个块以评估TTFB的性能改进:在对等块注册表发送的WANT-BLOCK回合中交换的每个块都生成了两个额外的重复块。对于较大的文件,交换的块数要大得多,并且事先知道哪个对等方请求内容可以阻止对等方轮询整个网络,因此减少了文件交换中生成的重复块的数量。


结论与未来工作

  该RFC的实现强调了使用有关文件共享,网络事件或其他覆盖协议的信息来推动更快的内容交换的有效性。对于此RFC,仅通过侦听节点的连接对等方所请求的内容,我们就可以显着减少获取时间和网络中交换的控制消息的数量。

  我们已经在考虑当前实施的几个改进点,以充分利用WANT消息检查机制,包括:

  •使用IPFS节点的特征性缓存时间和其他启发式方法来避免将WANT-BLOCK消息发送给可能已经对我们正在寻找的内容进行垃圾收集的对等方(作为清理和“垃圾收集”存储在其中的信息的一种方式)对等块注册表)。

  •动态配置从其发送WANT_BLOCK消息的对等方块注册表的对等方数,以便根据对等方块注册表的状态,特定的应用程序,活动连接数或网络的状态,我们可以执行更智能的查找,以更有效地利用带宽,或最大程度地减少获取内容的时间。

  此外,我们正在探索将此RFC与正在进行中的其他原型相结合以潜在地实现进一步的改进,其中之一就是创建内容锚,该锚旨在跟踪各种网络信息,以改善对两个静态数据(即文件)的发现)和动态数据(例如PubSub流)。

  如果您想开始为这一激动人心的工作做出贡献,请随时关注我们,并毫不犹豫地与我们联系!


  原文链接:https://research.protocol.ai/blog/2020/two-ears-one-mouth-how-to-leverage-bitswap-chatter-for-faster-transfers/


最新推荐