DHT的目标之一是对密钥空间进行分区，因此每个节点（或它们的一组）都有一部分。为此，它会散列要保存的文件的文件名，并将其存储在负责此部分网络的节点中。但是，为什么它必须散列文件名？它不能像字典一样工作，所以不是让节点在0000和0a2d之间保存哈希值，而是在C和E之间保存文件名值吗？
答案 0 :(得分：2)
但是，为什么要对文件名进行哈希？
它不一定是文件名。它也可以散列其他东西。例如。文件内容。或元数据。或者加密密钥用作网络中用户的身份。
它不能像字典那样工作，所以不是让节点在0000和0a2d之间保存哈希值，而是在C和E之间保存文件名值吗？
因为文件名在整个可能的键空间中不是均匀分布的（你经常看到以一些奇特的unicode字符开头的文件名？），并且它们的熵分布在可变长度上，导致顶层的聚集更多。
如果您要为世界上所有现有的unix文件系统建立索引，那么您可以围绕/etc/...前缀进行大规模聚类。
还有其他p2p网络覆盖可以处理密钥空间中的大量聚类，通常是通过重新安排热点周围的节点来增加受影响密钥空间区域的网络容量，例如：基于levenshtein距离，但它们通常不是分布式哈希表，因为它们不使用散列。
答案 1 :(得分：0)
因为搜索是在数字上完成的。
当您对文件进行哈希处理时，您最终得到一个数字，该数字将分配在最近的K-peers中最近的K-bucket中。
名称无关紧要，您在数字空间上执行XOR搜索，这样您就可以在每一跳上搜索一半的空间。
一旦找到具有哈希指向的桶的对等体，则可以与该对等体通信并交换相关信息。
像libtorrent的kademlia实现一样，DHT必须更多地看待分布式路由数据结构。您要解决的问题是如何在数十亿个数字中找到一个数字，如何在可能的最少跳数中找到数百万的对等体，答案是网络上的每个节点都必须遵循关于如何组织他们存储的数字以及他们所知道的同伴的一套简单规则。
我建议你阅读这些关于真正的DHT实际工作原理的说明。 https://gist.github.com/gubatron/cd9cfa66839e18e49846
此外，存储数字所需的空间比存储单词少得多。
如果你知道这个词，你可以散列这个词并搜索哈希值。
答案 2 :(得分：0)
是的，它可以像字典一样工作。但是，它会缺少一些可取的（对于典型的DHT用例）来自使用哈希的紧急属性。
散列的一个属性（以及XOR距离度量）为您提供了参与DHT的所有节点之间内容的均匀分布。 ＆＃34;即使＆＃34;这里有一个k-bucket数据结构如何工作（这里是一个概述k-bucket slides），但总的来说，你得到的节点在DHT对等体之间均匀分布数据。理论上。在实践中，你可以获得热点。
使用哈希的另一个属性是，如果您正在寻找具有特定内容的文件。因此，如果您使用文件内容的哈希值作为标识符，那么您可以...统计上确定（保证来自您的哈希函数冲突属性），您将获得您正在寻找的内容。依赖文件名引入了一个间接级别，可以为同一个文件提供不同的内容。根据您的使用情况，这是否可以接受。
我已经考虑过你之前提出的作为SHA-1哈希前缀的内容。所以，像node1-cd9cf ......（前缀可能是真的，不需要人类可读）。这将确保具有该前缀的所有内容最终在一个节点上结束，该节点使用以＆＃34; node1 - ＆＃34;开头的id来标识自身。但是，您必须拥有支持可变长度ID的DHT实现（包括k-bucket实现）。在这种情况下，您可以保证热点。它相当于人为地确保事物紧密结合在一起＃34;因为在XOR度量中它们之间的差异非常小。为什么有人想要这样做？例如：com.example.www-cd9cf ...结合一些加密可以确保在您参与DHT时，数据存储在您的服务器上。我之前没有看到这个实现过。