IPFS技术飞速发展，逐步探索通往新DHT的路径

4月底，我们发布了迄今为止最大的go-ipfs更新：IPFS 0.5.0。此升级为IPFS带来了主要的性能和可靠性改进，特别是在内容发现和路由方面。这些收益很大程度上是通过我们对分布式哈希表（DHT）的改造而实现的，该哈希表为IPFS公共网络中的大多数对等和内容发现提供了支持。

我们希望带您完成什么是DHT？

DHT或分布式哈希表，就像一个IPFS目录和导航系统，帮助网络跟踪和查找数据。常规哈希表是一个键值存储，其中的键被散列并存储在一个位置。对于IPFS，键是数据块的内容标识符（CID），值是具有每个块的对等体的集合。

DHT在整个网络中许多节点或对等点的小表中分发和存储这些键对和值对。同行则存储有关在何处物理定位特定内容的信息。我们的DHT实施Kademlia帮助跟踪哪些节点正在向网络中的其他节点提供哪些数据。

从理论上讲，DHT应该使在节点之间查找、提供和获取数据成为精心策划且非常有效的事情。但是，在现实情况下以及快速扩展的网络中，事情可能会出错。

让我们回顾

去年，IPFS公共网络实现了可观的增长，迅速扩展了30倍，现在有数十万个节点加入该网络！大型软件部署和新的分散式应用程序随即出现，并期望具有可匹配的可靠性和性能的生产就绪型网络。许多人将IPFS用作分散的CDN（内容交付网络），以在网络上共享和查找内容。不幸的是，由于无法将对等方路由到所需内容的新节点激增，网络使其中一些用户瘫痪。

在2019年初，我们开始听到有关内容路由问题的传言，随着越来越多的节点通过Q1和Q2加入网络而加剧了这种情况-其中许多节点位于家庭防火墙或NAT之后。我们不断地引导和修补网络，以补救性能和可靠性问题。但是，在这些补丁投入生产之前，我们无法真正测试它们的功效（或真正诊断出任何退化），因此很难进行迭代并尝试对网络配置进行更大的修复。

我们显然有一个问题，并且我们正在社区中听到它。我们的第一步是进行彻底调查，以确定首先应确定哪些解决方案的优先级，并确定成功进行变更所需的工具。

缩小

经过一番调查，很明显，我们的DHT实施，加上近期不可删除节点的增长，是导致内容路由缓慢，不可靠的罪魁祸首。当我们在一起在IPFS营地时，我们有机会对此进行了更深入的调查，并发现了一些问题区域：

- 对等可用性：当新的对等节点加入网络后，我们将它们同等对待，但是实际上无法到达大多数对等节点，因为它们位于防火墙或NAT之后。DHT查询时间浪费在尝试拨打从未收到请求的对等方上。 - 查询终止：即使在DHT查询达到其目标之后，它也没有停止，它继续查询其他对等点以确保它已达到目标。虽然对

热点：ipfs