生成 CRC 的速度有多快？答案

【问题标题】：How fast are CRCs to generate?生成 CRC 的速度有多快？
【发布时间】：2011-12-15 15:44:54
【问题描述】：

我需要为网络上的图像文件生成 etag。我想到的一种可能的解决方案是计算图像文件的 CRC，然后将其用作 etag。

这将需要每次有人在服务器上请求图像时计算 CRC，因此能够快速完成非常重要。

那么，生成 CRC 的算法有多快？或者这是一个愚蠢的想法？

【问题讨论】：

我认为，如果您的图像每次都没有变化，您就不需要在每次请求此类静态内容时计算 CRC。
正如@Davide 建议的那样，为什么不只生成 CRC（或更好，以及 SHA1/MD5 哈希）并将其保存在某个地方（文件、数据库等），这样您就不需要计算每次请求图像时。
非常类似于stackoverflow.com/questions/2285482/getting-etags-right
我正在根据用户查询动态生成图像（以不同的宽度、边框等），所以这样做有点困难。

标签： c# crc

【解决方案1】：

我建议在将图像添加到数据库一次时计算哈希值，然后通过 SELECT 将其与图像本身一起返回。

如果您使用 Sql Server 并且图像不是很大（最大 8000 字节），您可以利用 HASHBYTES() 函数生成 SHA-1、MD5、...

【讨论】：

【解决方案2】：

取决于使用的方法和长度。通常很快，但为什么不缓存它们呢？

如果对文件的更改不会比用于存储它的系统的分辨率更频繁（即文件系统的文件修改时间或存储在数据库中的 SQLServer 日期时间），那么为什么不只使用相关决议的修改日期？

我知道 RFC 2616 建议不要使用时间戳，但这只是因为 HTTP 时间戳的分辨率为 1 秒，并且更改的频率可能比这更频繁。然而：

通过这种方法，您可以确保获得唯一的电子标签（大 CRC 不太可能发生冲突，但肯定有可能），这正是您想要的。

当然，如果您从不更改给定 URI 处的图像，则更容易，因为您可以使用固定字符串（我更喜欢字符串“不可变”）。

【讨论】：

【解决方案3】：

大多数实现使用最后修改日期或其他文件头作为 ETag，包括Microsoft's own，我建议你使用该方法。

【讨论】：

【解决方案4】：

改用更强大的哈希算法，例如SHA1。

速度取决于图像的大小。大部分时间将花在从磁盘加载数据上，而不是 CPU 处理上。您可以缓存生成的哈希值。

但我也建议根据文件的最后更新日期创建 etag，这样更快且不需要加载整个文件。

请记住，etag 必须仅对特定资源是唯一的，因此如果两个不同的图像具有相同的上次更新时间，那很好。

【讨论】：

+1 提到 sha1 更加健壮并且反对未注释的downvote
我不是反对者，但我猜这是因为如果有人担心 CRC 计算的速度，那么建议 SHA-1 会适得其反，因为它会比最简单的 CRC 实现要慢。
如果基于时间戳，相同的图像对于其他版本可能具有相同的 etag，如果它们可以在使用的分辨率内更改。因此，如果例如它们可能改变的最快时间是在五分之一秒内，您应该将时间戳至少设为最接近的 10 分之一，这样它们就不可能重合。
是的，这是真的。我认为实际上 IIS 完全基于文件名生成 etag，因此它永远不会更改，但它会发送最后更新时间。
不，IIS 默认根据文件的机器密钥和更改计数生成电子标签。当您使用网络农场时，这是一个错误，因为机器密钥会有所不同，但可以更改以使其在机器之间保持一致。