为什么DHT会对文件名进行哈希处理？

Question

DHT的目标之一是对密钥空间进行分区，因此每个节点（或它们的组）都有一个共享空间。 为此，它对要保存的文件的文件名进行哈希处理，然后将其存储在负责网络这一部分的节点中。 但是，为什么它必须对文件名进行哈希处理？ 它不能像字典一样工作，所以不是让节点保存0000和0a2d之间的哈希值，而是让它保存C和E之间的文件名值？

Answer 1

但是，为什么它必须对文件名进行哈希处理？

它不必是文件名。 它也可以哈希其他内容。 例如文件内容。 或元数据。 或用作网络中用户身份的加密密钥。

它不能像字典一样工作，所以不是让节点保存0000和0a2d之间的哈希值，而是让它保存C和E之间的文件名值？

由于文件名在可能的键空间中分布不均匀（您看到文件名以某些奇异的unicode字符开头的频率是多少？），并且它们的熵分布在可变的长度上，从而导致在顶层出现更多的聚类。 如果要索引世界上所有现有的unix文件系统，则将在/etc/...前缀周围拥有大量集群。

还有其他p2p网络覆盖可以处理密钥空间中的繁重集群，通常是通过重新布置热点周围的节点来增加受影响密钥空间区域中的网络容量（例如，基于levenshtein距离），但是它们通常不是分布式哈希表因为它们不使用哈希。

Answer 2

因为搜索是针对数字进行的。

当您对文件进行哈希处理时，您将得到一个数字，该数字将分配给最近的K对等体中最近的K个存储桶。

名称无关紧要，您正在对数字空间执行XOR搜索，因此您始终在每一跳上搜索一半的空间。

一旦找到具有散列所指向的存储桶的同位体，就可以与该同位体进行通信并交换相关信息。

像libtorrent的kademlia实现一样，DHT必须更多地看作是分布式路由数据结构。 您要解决的问题是如何在数十亿个数字中找到一个数字，如何以最少的跳数在数百万个数字中找到一个对等体，答案是网络上的每个节点都必须遵循一组有关如何组织存储的数字以及他们了解的同级物的简单规则。

我建议您阅读这些有关实际DHT实际工作方式的说明。 https://gist.github.com/gubatron/cd9cfa66839e18e49846

另外，存储数字所花费的空间比存储单词所占用的空间少得多。

如果您知道单词，则可以对该单词进行哈希处理并搜索哈希值。

Answer 3

是的，它可以像字典一样工作。 但是，它将缺少使用散列产生的一些理想的（对于典型的DHT用例而言）新兴属性。

哈希（以及XOR距离度量）为您提供的一个属性是内容在参与DHT的所有节点之间的平均分配。 k-bucket数据结构的工作方式（这里是k-bucket幻灯片的概述）在这里“偶”，但从总体上讲，您将获得节点在DHT对等点之间平均分配数据的信息。 在实践中，您可以获得热点。

使用哈希的另一个属性是，如果您要查找包含特定内容的文件。 因此，如果您将文件内容的哈希值用作标识符，则可以...从统计上确定（保证来自您的哈希函数碰撞属性），您正在获取所需的内容。 依赖文件名会引入一种间接级别，可以为同一文件提供不同的内容。 根据您的用例，是否可以接受。

我考虑过您之前提出的SHA-1哈希的前缀。 因此，类似node1-cd9cf ...（前缀可以是任何东西，不需要人类可读）。 这样可以确保所有带有该前缀的内容最终都出现在一个以“ node1-”开头的id进行标识的节点上。 但是，您必须具有支持可变长度id的DHT实现（包括k-bucket实现）。 在这种情况下，您可以保证热点。 这等同于人为地确保事物“靠近”，因为XOR度量之间的差异非常小。 为什么有人要这样做？ 例如：com.example.www-cd9cf ...与一些加密货币结合使用可以确保您在参与DHT时将数据存储在服务器上。 我之前从未见过实现。