强大且快速的校验和算法？

Question

在以下的使用情境下，你可以推荐哪种校验和算法？

我希望能够生成小型JPEG文件（每个文件约8 kB）的校验和，以检查内容是否已更改。然而，使用文件系统中的“修改日期”并不是一个可行的选择。
该校验和不必具有密码学强度，但应能够稳健地指示任何大小的变化。

第二个标准是速度，因为应该能够每秒处理至少数百张图片（在现代CPU上）。

计算将在具有多个客户端的服务器上进行。客户机通过千兆字节TCP将图像发送到服务器。因此，没有磁盘I/O作为瓶颈。

- bene

---

1千兆位等于125兆字节（全双工）。在这125MB/s中，非常大的一部分将是网络开销（特别是当您想发送数百个小文件时）。由于MD5在小核心上可以运行近250MB/s，因此您应该将其从“没有磁盘I/O作为瓶颈”更改为“完全磁盘I/O作为瓶颈”。这个问题已经存在了7年，似乎没有人提到过，如果您在发布到StackOverflow之前尝试了某些东西，您自己就会看到这一点。 - J.J

据我理解，服务器可以预先计算出所有文件的校验和。这样它就不需要进行任何磁盘I/O操作了？它只需要读取客户端发送的文件并对其进行校验，然后与其预先计算的校验和进行比较即可。 - avl_sweden

Answer 1

如果你有许多小文件，瓶颈将是文件I/O，而不是校验和算法。

可以在这里找到哈希函数列表（可视为校验和）。

有没有什么理由不能使用文件系统的修改日期来确定文件是否已更改？那可能会更快。

- luke

---

同意。大多数非加密安全哈希算法都足够短，存在误判的可能性相当高，因此我建议直接使用MD5或SHA1即可。计算速度不太可能成为问题。 - Nick Johnson

@luke 我也想检查文件修改情况，上次我回顾我的存档时发现，在我两个不同磁盘的100GB小存档中，有少量文件损坏了！时间戳没有改变，但是文件内容被悄无声息地破坏了。其中一些文件已经超过10年了，所以我必须至少将它们从一台机器移动到另一台机器两次。因此，必须使用校验和。 - bartosz.r

Answer 2

有许多快速的CRC算法可以解决问题：http://www.google.com/search?hl=zh-cn&q=fast+crc&aq=f&oq=

编辑：为什么这么令人反感？ CRC是完全合适的，正如其他答案所证明的那样。 由于没有指定语言，因此进行Google搜索也是合适的。 这是一个古老的问题，已经解决了很多次，不太可能有一个明确的答案。

- Mark Ransom

---

有足够的文件，碰撞变得非常可能。查找“生日悖论”。对于CRC32，您只需要大约100,000张图像，就可以高度可能地发生碰撞。 - avl_sweden

不确定为什么你把那个评论发给我。根据问题作者的评论，他的意图是检测文件损坏而不是去重复，因此重复的 CRC 值并不重要。这正是 CRC 被发明出来解决的问题。 - Mark Ransom

好的，非常感谢您指出这一点！请接受我的道歉，我误解了！ - avl_sweden

Answer 3

• CRC-32想到的主要是因为计算费用便宜。

• 任何类型的I/O都会被考虑，因为这将成为这种工作的限制因素；）

• 问题不在于计算校验和，而在于将图像加载到内存中以计算校验和。

• 我建议采用“分阶段”监控：

  • 阶段1：检查文件时间戳的更改，如果检测到更改，则转到...
    (在您所描述的情况下，此步骤不需要)

  • 阶段2：将图像加载到内存中并计算校验和

• 同样重要的是：多线程：设置一个管道，如果有几个CPU核心可用，则可以处理几个图像。

- pointernil

Answer 4

如果您通过网络接收文件，可以在接收文件时计算校验和。这将确保在数据在内存中时计算校验和。因此，您不必从磁盘加载它们到内存中。

我相信如果您采用这种方法，您的系统几乎没有开销。

这是我在嵌入式系统上使用的例程，对固件和其他内容进行校验控制。

static const uint32_t crctab[] = {
    0x0,
    0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc, 0x17c56b6b,
    0x1a864db2, 0x1e475005, 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6,
    0x2b4bcb61, 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd,
    0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9, 0x5f15adac,
    0x5bd4b01b, 0x569796c2, 0x52568b75, 0x6a1936c8, 0x6ed82b7f,
    0x639b0da6, 0x675a1011, 0x791d4014, 0x7ddc5da3, 0x709f7b7a,
    0x745e66cd, 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e, 0x95609039,
    0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5, 0xbe2b5b58,
    0xbaea46ef, 0xb7a96036, 0xb3687d81, 0xad2f2d84, 0xa9ee3033,
    0xa4ad16ea, 0xa06c0b5d, 0xd4326d90, 0xd0f37027, 0xddb056fe,
    0xd9714b49, 0xc7361b4c, 0xc3f706fb, 0xceb42022, 0xca753d95,
    0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1, 0xe13ef6f4,
    0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d, 0x34867077, 0x30476dc0,
    0x3d044b19, 0x39c556ae, 0x278206ab, 0x23431b1c, 0x2e003dc5,
    0x2ac12072, 0x128e9dcf, 0x164f8078, 0x1b0ca6a1, 0x1fcdbb16,
    0x018aeb13, 0x054bf6a4, 0x0808d07d, 0x0cc9cdca, 0x7897ab07,
    0x7c56b6b0, 0x71159069, 0x75d48dde, 0x6b93dddb, 0x6f52c06c,
    0x6211e6b5, 0x66d0fb02, 0x5e9f46bf, 0x5a5e5b08, 0x571d7dd1,
    0x53dc6066, 0x4d9b3063, 0x495a2dd4, 0x44190b0d, 0x40d816ba,
    0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e, 0xbfa1b04b,
    0xbb60adfc, 0xb6238b25, 0xb2e29692, 0x8aad2b2f, 0x8e6c3698,
    0x832f1041, 0x87ee0df6, 0x99a95df3, 0x9d684044, 0x902b669d,
    0x94ea7b2a, 0xe0b41de7, 0xe4750050, 0xe9362689, 0xedf73b3e,
    0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2, 0xc6bcf05f,
    0xc27dede8, 0xcf3ecb31, 0xcbffd686, 0xd5b88683, 0xd1799b34,
    0xdc3abded, 0xd8fba05a, 0x690ce0ee, 0x6dcdfd59, 0x608edb80,
    0x644fc637, 0x7a089632, 0x7ec98b85, 0x738aad5c, 0x774bb0eb,
    0x4f040d56, 0x4bc510e1, 0x46863638, 0x42472b8f, 0x5c007b8a,
    0x58c1663d, 0x558240e4, 0x51435d53, 0x251d3b9e, 0x21dc2629,
    0x2c9f00f0, 0x285e1d47, 0x36194d42, 0x32d850f5, 0x3f9b762c,
    0x3b5a6b9b, 0x0315d626, 0x07d4cb91, 0x0a97ed48, 0x0e56f0ff,
    0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623, 0xf12f560e,
    0xf5ee4bb9, 0xf8ad6d60, 0xfc6c70d7, 0xe22b20d2, 0xe6ea3d65,
    0xeba91bbc, 0xef68060b, 0xd727bbb6, 0xd3e6a601, 0xdea580d8,
    0xda649d6f, 0xc423cd6a, 0xc0e2d0dd, 0xcda1f604, 0xc960ebb3,
    0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7, 0xae3afba2,
    0xaafbe615, 0xa7b8c0cc, 0xa379dd7b, 0x9b3660c6, 0x9ff77d71,
    0x92b45ba8, 0x9675461f, 0x8832161a, 0x8cf30bad, 0x81b02d74,
    0x857130c3, 0x5d8a9099, 0x594b8d2e, 0x5408abf7, 0x50c9b640,
    0x4e8ee645, 0x4a4ffbf2, 0x470cdd2b, 0x43cdc09c, 0x7b827d21,
    0x7f436096, 0x7200464f, 0x76c15bf8, 0x68860bfd, 0x6c47164a,
    0x61043093, 0x65c52d24, 0x119b4be9, 0x155a565e, 0x18197087,
    0x1cd86d30, 0x029f3d35, 0x065e2082, 0x0b1d065b, 0x0fdc1bec,
    0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088, 0x2497d08d,
    0x2056cd3a, 0x2d15ebe3, 0x29d4f654, 0xc5a92679, 0xc1683bce,
    0xcc2b1d17, 0xc8ea00a0, 0xd6ad50a5, 0xd26c4d12, 0xdf2f6bcb,
    0xdbee767c, 0xe3a1cbc1, 0xe760d676, 0xea23f0af, 0xeee2ed18,
    0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4, 0x89b8fd09,
    0x8d79e0be, 0x803ac667, 0x84fbdbd0, 0x9abc8bd5, 0x9e7d9662,
    0x933eb0bb, 0x97ffad0c, 0xafb010b1, 0xab710d06, 0xa6322bdf,
    0xa2f33668, 0xbcb4666d, 0xb8757bda, 0xb5365d03, 0xb1f740b4
};

typedef struct crc32ctx
{
    uint32_t crc;
    uint32_t length;
} CRC32Ctx;


#define COMPUTE(var, ch)    (var) = (var) << 8 ^ crctab[(var) >> 24 ^ (ch)]

void crc32_stream_init( CRC32Ctx* ctx )
{
    ctx->crc = 0;
    ctx->length = 0;
}

void crc32_stream_compute_uint32( CRC32Ctx* ctx, uint32_t data )
{
    COMPUTE( ctx->crc, data & 0xFF );
    COMPUTE( ctx->crc, ( data >> 8 ) & 0xFF );
    COMPUTE( ctx->crc, ( data >> 16 ) & 0xFF );
    COMPUTE( ctx->crc, ( data >> 24 ) & 0xFF );
    ctx->length += 4;
}

void crc32_stream_compute_uint8( CRC32Ctx* ctx, uint8_t data )
{
    COMPUTE( ctx->crc, data );
    ctx->length++;
}

void crc32_stream_finilize( CRC32Ctx* ctx )
{
    uint32_t len = ctx->length;
    for( ; len != 0; len >>= 8 )
    {
        COMPUTE( ctx->crc, len & 0xFF );
    }
    ctx->crc = ~ctx->crc;
}

/*** pseudo code ***/
CRC32Ctx crc;
crc32_stream_init(&crc);

while((just_received_buffer_len = received_anything()))
{
    for(int i = 0; i < just_received_buffer_len; i++)
    {
        crc32_stream_compute_uint8(&crc, buf[i]); // assuming buf is uint8_t*
    }
}
crc32_stream_finilize(&crc);
printf("%x", crc.crc); // ta daaa

- Engin

Answer 5

CRC

- radu_c

---

CRC不具有密码学强度。 - sergtk

这使得它适用于这种应用。 - erickson

楼主并没有要求使用加密强度高的哈希算法 :) - radu_c

Answer 6

adler32是在zlib头文件中提供的，它被宣传为比crc32更快，但准确度仅略低。

- Josh Matthews

---

阿德勒校验和在数据量很小的情况下，即少于几百字节时非常脆弱。SCTP协议最初使用Adler-32作为其校验和，但由于此原因（在RFC 3309中），不得不转而使用CRC-32。尽管提问者平均文件大小为8K，但对于最小的文件来说可能会存在问题。 - DGentry

Answer 7

CRC32可能已经足够好了，尽管有一点小小的概率会发生碰撞，这意味着修改过的文件可能看起来没有被修改，因为两个版本生成了相同的校验和。为了避免这种可能性，建议使用MD5，它的速度足够快，发生碰撞的概率降低到几乎可以忽略不计的程度。

正如其他人所说，对于大量的小文件，您真正面临的性能瓶颈将是I/O，因此问题在于如何处理它。如果您发布更多细节，某人可能会建议解决此问题的方法。

- Bart Read

Answer 8

你最重要的要求是“检查内容是否更改”。

如果任何文件的更改都需要被检测到，那么MD-5、SHA-1甚至SHA-256应该是你的选择。

鉴于你表示校验和不需要具有加密强度，我建议使用CRC-32，原因有三。首先，CRC-32在8K文件上具有良好的海明距离。其次，CRC-32计算速度至少比MD-5快一个数量级（即你的第二个要求）。最后，同样重要的是，CRC-32仅需要32位存储值进行比较，而MD-5需要4倍的存储空间，SHA-1需要5倍的存储空间。

顺便说一句，通过在计算哈希时添加文件长度可以加强任何技术的效果。

- Epsilon

Answer 9

根据Luke指向的维基页面，MD5实际上比CRC32更快！我自己在Windows Vista上使用Python 2.6尝试过，并得到了相同的结果。以下是一些结果：crc32：162.481544276 MBps md5：224.489791549 MBps crc32：168.332996575 MBps md5：226.089336532 MBps crc32：155.851515828 MBps md5：194.943289532 MBps 我也在考虑同样的问题，并且很想使用Rsync的Adler-32变体来检测文件差异。

- chnrxn

---

这很不寻常。CRC32和MD5的实现质量是否相等，或者其中一个使用了所有编译器优化和查找表技巧，而另一个则没有？ - Ants

Answer 10

以上只是一个附言；JPEG使用有损压缩，压缩程度可能取决于用于创建JPEG的程序、颜色调色板和/或系统位深度、显示伽马值、图形卡和用户设置的压缩级别/颜色设置。因此，在字节级别比较在不同计算机/平台上构建或使用不同软件的JPEG将非常困难。

- Tim

---

感谢您的评论。我已经考虑到这个事实了。 - Benedikt Waldvogel