2

我正在研究一个涉及文件哈希计算的项目。该项目就像一个文件备份服务，所以当一个文件从客户端上传到服务器时，我需要检查该文件是否已经在服务器中可用。我为文件生成一个 CRC-32 哈希，然后将哈希发送到服务器以检查它是否已经可用。

如果文件不在服务器中，我曾经将文件作为 512 KB 块 [for Dedupe] 发送，我必须为每个 512 KB 块计算哈希。文件大小有时可能只有几 GB，并且多个客户端将连接到服务器。所以我真的需要一个快速和轻量级的文件散列算法。有任何想法吗 ..？

PS：我已经注意到 StackOverflow 中的一些 Hashing Algorithm 问题，但答案并不能完全比较此类任务所需的 Hashing Algorithms。我敢打赌这对一群人来说真的很有用。

4

3 回答 3

2

实际上，CRC32 既没有最好的速度，也没有最好的分布。

这是意料之中的：按照今天的标准，CRC32 已经很老了，并且是在 CPU 不是 32/64 位宽也不是 OoO-Ex 的时代创建的，分布属性也没有错误检测那么重要。从那以后，所有这些要求都发生了变化。

为了评估哈希算法的速度和分布特性，Austin Appleby 创建了出色的SMHasher包。此处提供了结果的简短摘要。我建议选择 Q.Score 为 10（完美分布）的算法。

于 2012-12-12T17:08:28.057 回答
0

您说您正在使用 CRC-32 但想要更快的哈希值。CRC-32 非常基础而且非常快。我认为 I/O 时间会比哈希时间长得多。您还需要一个不会发生冲突的哈希。也就是说，两个不同的文件或 512 KB 块获得相同的哈希值。您可以查看任何加密哈希，例如 MD5（不要用于安全应用程序）或 SHA1。

于 2012-11-30T14:33:37.690 回答
0

如果您只使用 CRC-32 来检查文件是否重复，您将得到错误的重复，因为不同的文件可以具有相同的 crc-32。你最好用sha-1，crc-32和md5都太弱了。

于 2015-01-04T07:17:00.867 回答