4 月底，我们发布了迄今为止最大的 go-ipfs 更新：IPFS 0.5.0。
4 月底，我们发布了迄今为止最大的 go-ipfs 更新：IPFS 0.5.0。此升级为 IPFS 带来了主要的性能和可靠性改进，尤其是在内容发现和路由方面。这些收益很大程度上是通过我们对分布式哈希表（DHT）的改造而实现的，该哈希表为 IPFS 公共网络中的大多数对等和内容发现提供了支持。
我们希望带您完成重新编写 DHT 的整个过程-从确定根本问题到如何设计解决方案，以确保它在实践中起作用。我们的工作带来了重大的性能提升，并带来了新的开发流程和 Testground，这是用于大规模网络测试的全新工具。
如果您想利用这些新改进，请立即升级 IPFS！
首先复习：什么是 DHT？
DHT或分布式哈希表，就像一个 IPFS 目录和导航系统，帮助网络跟踪和查找数据。常规哈希表是一个键值存储，其中的键被散列并存储在一个位置。对于 IPFS，键是数据块的内容标识符（CID），值是具有每个块的对等体的集合。
DHT 在整个网络中许多节点或对等点的小表中分发和存储这些键对和值对。同行则存储有关在何处物理定位特定内容的信息。我们的 DHT 实施 Kademlia 帮助跟踪哪些节点正在向网络中的其他节点提供哪些数据。
从理论上讲，DHT 应该使在节点之间查找，提供和获取数据成为精心策划且非常有效的事情。但是，在现实情况下以及快速扩展的网络中，事情可能会出错。
让我们回顾
去年，IPFS 公共网络实现了可观的增长，迅速扩展了 30 倍，现在有数十万个节点加入该网络！大型软件部署和新的分散式应用程序随即出现，并期望具有可匹配的可靠性和性能的生产就绪型网络。许多人将 IPFS 用作分散的 CDN（内容交付网络），以在网络上共享和查找内容。不幸的是，由于无法将对等方路由到所需内容的新节点激增，网络使其中一些用户瘫痪。
在 2019 年初，我们开始听到有关内容路由问题的传言，随着越来越多的节点通过 Q1 和 Q2 加入网络而加剧了这种情况-其中许多节点位于家庭防火墙或 NAT 之后。我们不断地引导和修补网络，以补救性能和可靠性问题。但是，在这些补丁投入生产之前，我们无法真正测试它们的功效（或真正诊断出任何退化），因此很难进行迭代并尝试对网络配置进行更大的修复。
我们显然有一个问题，并且我们正在社区中听到它。我们的第一步是进行彻底调查，以确定首先应确定哪些解决方案的优先级，并确定成功进行变更所需的工具。
缩小
经过一番调查，很明显，我们的 DHT 实施，加上近期不可删除节点的增长，是导致内容路由缓慢，不可靠的罪魁祸首。当我们在一起在 IPFS 营地时，我们有机会对此进行了更深入的调查，并发现了一些问题区域：
-
对等可用性：当新的对等节点加入网络后，我们将它们同等对待，但是实际上无法到达大多数对等节点，因为它们位于防火墙或 NAT 之后。DHT 查询时间浪费在尝试拨打从未收到请求的对等方上。
-
查询终止：即使在 DHT 查询达到其目标之后，它也没有停止，它继续查询其他对等点以确保它已达到目标。虽然对网络中的许多新的不可删除节点具有鲁棒性，但此过程非常耗时。
-
路由表维护：路由表被许多无法拨号的对等点所阻塞，导致搜索在查询的对等点数量上线性变化，而不是预期的对数规模效率。
集中精力
通过这一分析以及我们核心用户和社区的综合反馈，很明显，我们需要磨练内容路由性能，将其作为 IPFS 项目的核心重点。
这意味着要对优先级进行一些艰苦的呼吁：将我们的工作组集中在 DHT 和路由逻辑的目标改进集上，以确保我们解决了这些基本的性能和可靠性问题。反过来，我们调整了产品路线图并成立了新的核心工作组，其中一个小组严格关注内容路由，另一个小组致力于新的测试基础架构：Testground。
测试，测试，测试
我们从早期的补丁中得知，我们规模的网络需要能够在接近实际的环境中测试更改，以便能够快速可靠地进行改进。我们拥有进行单元测试和小型仿真的能力，可以证明基本的调整，但是没有办法复制成千上万个节点或典型的网络配置来对主要变更进行基准测试。这使我们在变更付诸实践之前没有关于变更真正影响的真实数据。
为了成功纠正 DHT，我们必须迅速改变这一点。我们成立了一个工作组来弥补这一差距。Testground 诞生了。Testground 是一个用于大规模测试，基准测试和模拟分布式和对等系统的平台，使我们能够验证所需的修复程序，并在 IPFS 0.5.0 启用之前对广泛的 DHT 更改进行压力测试。
Testground 在 DHT 重写中为我们提供了进行数据驱动的开发的工具。它还在 IPFS 0.5.0 版本的其他部分为我们提供了帮助：例如对新的潜在解决方案进行原型制作，相互比较潜在的修复程序以及对边缘情况和升级过程进行压力测试。Testground 的可重复性和自省性对于加快我们的开发速度以可靠地改善 IPFS 至关重要。
随着 Testground v0.5 的发布，我们很高兴与其他人共享此工具以及对他们的 p2p 网络进行基准测试和评估。立即开始使用 Testground！
现在为“修复”
使用 Testground，我们可以对 DHT 问题进行基准测试和量化，这些问题涉及对等方可用性，查询终止和路由表维护。我们从对现有网络的仿真开始-展示了我们先前的查询逻辑如何与不断发展的网络参数进行交互，就像许多节点不可撤销一样。
Testground 允许我们调整这些参数，以衡量哪些更改将对网络性能产生最大影响。当我们在 1 月份召开研究峰会以比较潜在缓解措施与持续存在的网络挑战时，我们现在获得了对网络结构和工具的定量了解，可以立即对我们的讨论进行原型化并检验所得出的假设。
随后是测试计划编写的旋风，以测量实际网络环境中 DHT 逻辑的每次更改。我们测试了新系统，以诊断无法删除的对等方并将其从路由表中删除，测量了成功率，以便更早地结束查询，甚至重新确定了对 Bitswap 的改进以寻找其他改进。在所有这些重构过程中，我们都能通过我们的 Testground 仿真以及一些放置良好的金丝雀节点不断验证这些更改的性能，以针对整个公共网络运行基准测试。
有了这些工具，我们将从峰顶冲刺到发布，以实现一切。从发现社区中的问题，到确定潜在的解决方案，构建测试工具，从过去的研究中学习以及执行所需的技术修复，这次发布的马拉松无疑使我们步入了新的步伐，从而产生了新的史诗清单。改进的功能。
接下来，在本 DHT 深入探究的第2部分中，我们将向您详细介绍 DHT 的新功能，并进一步介绍我们所看到的改进。同时，如果您尚未升级，请执行。随着越来越多的节点更新，我们都将获得性能更高的DHT的好处！
学到更多
非常感谢您对 IPFS&Filecoin 项目的持续支持。我们很高兴继续与您一起，为人类信息建立一个强大的，去中心化和高效的基础。
FilCloud 帮你迅速了解 IPFS 领域的热点技术和应用
首先复习：什么是 DHT？DHT或分布式哈希表，就像一个 IPFS 目录和导航系统，帮助网络跟踪和查找数据。常规哈希表是一个键值存储，其中的键被散列并存储在一个位置。对于 IPFS，键是数据块的内容标识符（CID），值是具有每个块的对等体的集合。DHT 在整个网络中许多节点或对等点的小表中分发和存储这些键对和值对。同行则存储有关在何处物理定位特定内容的信息。我们的 DHT 实施 Kademlia 帮助跟踪哪些节点正在向网络中的其他节点提供哪些数据。从理论上讲，DHT 应该使在节点之间查找，提供和获取数据成为精心策划且非常有效的事情。但是，在现实情况下以及快速扩展的网络中，事情可能会出错。让我们回顾去年，IPFS 公共网络实现了可观的增长，迅速扩展了 30 倍，现在有数十万个节点加入该网络！大型软件部署和新的分散式应用程序随即出现，并期望具有可匹配的可靠性和性能的生产就绪型网络。许多人将 IPFS 用作分散的 CDN（内容交付网络），以在网络上共享和查找内容。不幸的是，由于无法将对等方路由到所需内容的新节点激增，网络使其中一些用户瘫痪。在 2019 年初，我们开始听到有关内容路由问题的传言，随着越来越多的节点通过 Q1 和 Q2 加入网络而加剧了这种情况-其中许多节点位于家庭防火墙或 NAT 之后。我们不断地引导和修补网络，以补救性能和可靠性问题。但是，在这些补丁投入生产之前，我们无法真正测试它们的功效（或真正诊断出任何退化），因此很难进行迭代并尝试对网络配置进行更大的修复。我们显然有一个问题，并且我们正在社区中听到它。我们的第一步是进行彻底调查，以确定首先应确定哪些解决方案的优先级，并确定成功进行变更所需的工具。缩小经过一番调查，很明显，我们的 DHT 实施，加上近期不可删除节点的增长，是导致内容路由缓慢，不可靠的罪魁祸首。当我们在一起在 IPFS 营地时，我们有机会对此进行了更深入的调查，并发现了一些问题区域：
测试，测试，测试我们从早期的补丁中得知，我们规模的网络需要能够在接近实际的环境中测试更改，以便能够快速可靠地进行改进。我们拥有进行单元测试和小型仿真的能力，可以证明基本的调整，但是没有办法复制成千上万个节点或典型的网络配置来对主要变更进行基准测试。这使我们在变更付诸实践之前没有关于变更真正影响的真实数据。为了成功纠正 DHT，我们必须迅速改变这一点。我们成立了一个工作组来弥补这一差距。Testground 诞生了。Testground 是一个用于大规模测试，基准测试和模拟分布式和对等系统的平台，使我们能够验证所需的修复程序，并在 IPFS 0.5.0 启用之前对广泛的 DHT 更改进行压力测试。Testground 在 DHT 重写中为我们提供了进行数据驱动的开发的工具。它还在 IPFS 0.5.0 版本的其他部分为我们提供了帮助：例如对新的潜在解决方案进行原型制作，相互比较潜在的修复程序以及对边缘情况和升级过程进行压力测试。Testground 的可重复性和自省性对于加快我们的开发速度以可靠地改善 IPFS 至关重要。随着 Testground v0.5 的发布，我们很高兴与其他人共享此工具以及对他们的 p2p 网络进行基准测试和评估。立即开始使用 Testground！现在为“修复”使用 Testground，我们可以对 DHT 问题进行基准测试和量化，这些问题涉及对等方可用性，查询终止和路由表维护。我们从对现有网络的仿真开始-展示了我们先前的查询逻辑如何与不断发展的网络参数进行交互，就像许多节点不可撤销一样。Testground 允许我们调整这些参数，以衡量哪些更改将对网络性能产生最大影响。当我们在 1 月份召开研究峰会以比较潜在缓解措施与持续存在的网络挑战时，我们现在获得了对网络结构和工具的定量了解，可以立即对我们的讨论进行原型化并检验所得出的假设。随后是测试计划编写的旋风，以测量实际网络环境中 DHT 逻辑的每次更改。我们测试了新系统，以诊断无法删除的对等方并将其从路由表中删除，测量了成功率，以便更早地结束查询，甚至重新确定了对 Bitswap 的改进以寻找其他改进。在所有这些重构过程中，我们都能通过我们的 Testground 仿真以及一些放置良好的金丝雀节点不断验证这些更改的性能，以针对整个公共网络运行基准测试。有了这些工具，我们将从峰顶冲刺到发布，以实现一切。从发现社区中的问题，到确定潜在的解决方案，构建测试工具，从过去的研究中学习以及执行所需的技术修复，这次发布的马拉松无疑使我们步入了新的步伐，从而产生了新的史诗清单。改进的功能。接下来，在本 DHT 深入探究的第2部分中，我们将向您详细介绍 DHT 的新功能，并进一步介绍我们所看到的改进。同时，如果您尚未升级，请执行。随着越来越多的节点更新，我们都将获得性能更高的DHT的好处！学到更多
2397889 
