Hash 为什么DHT要散列文件名？

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

因为搜索是在数字上完成的

当你散列一个文件时，你会得到一个数字，这个数字将被分配到最近的K个对等点的最近的K个桶中

名称是不相关的，您在数字空间上执行XOR搜索，因此您总是在每个跃点上搜索一半的空间

一旦您找到一个具有哈希指向的桶的对等方，那么您就可以与该对等方通信并交换相关信息

DHT，如libtorrent的kademlia实现，必须更多地被视为分布式路由数据结构。你要解决的问题是如何在数十亿个数字中找到一个数字，如何在数百万个尽可能少的跳数中找到一个对等点，而答案是网络上的每个节点都必须遵循一套简单的规则，来组织它们存储的数字和它们知道的对等点

我建议您阅读这些关于真正的DHT实际工作原理的说明。

此外，存储一个数字比存储一个单词占用的空间要小得多

---

如果你知道这个词，你可以对这个词进行散列并搜索散列。

是的，它可以像字典一样工作。然而，它会丢失一些使用散列产生的理想（对于典型的DHT用例）紧急属性

散列（以及XOR距离度量）提供的一个特性是，内容在参与DHT的所有节点之间均匀分布。这里的“偶数”是由k-bucket数据结构的工作原理（这里是一个概述）引起的，但总体而言，节点在DHT对等点之间均匀分布数据。。理论上。实际上，你可以得到热点

使用散列的另一个特性是，如果要查找具有特定内容的文件。因此，如果您使用文件内容的哈希作为标识符，您可以。。。从统计上确定（保证来自您的哈希函数冲突属性）您得到了您要查找的内容。依赖文件名引入了一种间接寻址级别，可以为同一文件提供不同的内容。根据您的用例，这是可接受的还是不可接受的

我以前考虑过你的建议，把它作为SHA-1哈希的前缀。所以，像node1-cd9cf这样的东西。。。（前缀可以是任何东西，不需要是人类可读的）。这将确保所有带有该前缀的内容都在一个以“node1-”开头的id标识自身的节点上结束。但是，您必须有一个支持可变长度ID的DHT实现（包括k-bucket实现）。在这种情况下，您保证了一个热点。这相当于人为地确保事物“紧密相连”，因为它们之间在XOR度量中的差异非常小。为什么会有人想这样做？例如：com.example.www-cd9cf。。。结合一些加密技术可以确保在您参与DHT时，数据存储在您的服务器上。不过，我以前从未见过这种方法的实现

但是，为什么它必须散列文件名呢

它不必是文件名。它还可以把其他事情搞糟。例如，文件内容。或者元数据。或用作网络中用户身份的加密密钥

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

因为文件名不是均匀分布在整个可能的键空间中（您多久会看到文件名以某种奇异的unicode字符开头？），而且它们的熵分布在可变长度上，从而在顶层产生更多的集群。 例如，如果要为世界上所有现有的unix文件系统编制索引，您将在

/etc/…

前缀周围拥有大量集群

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