【问题标题】:Implementing HTTP ETags in a web server在 Web 服务器中实现 HTTP ETag
【发布时间】:2016-07-29 04:51:10
【问题描述】:

我目前正在研究在 Web 服务器中实现 ETag 以仅支持条件 GET 的可能性。 Web 服务器是用 C++ 编写的,只能在 Windows 操作系统上运行。在做了一些研究之后,我有几个问题......实现此功能的服务器通常会缓存特定文件的 ETag GUID 吗?我对 Apache 代码库不太熟悉,但我能够找到 ap_condition_if_none_match 函数,但是我并不完全清楚他们如何检查 if-none-match 标头的 GUID 值。如果他们确实缓存了一些东西并且文件在服务器之外进行了任何更改(即用户更新了它),那么服务器如何知道它缓存中的文件不再有效?他们是否可能使用一些 API 来“监视”目录更改?

编辑:我正在查看我在这里找到的一些信息:https://httpd.apache.org/docs/2.4/caching.html

【问题讨论】:

    标签: apache http caching etag


    【解决方案1】:

    在 Apache 中,ETag 由文件的 inode、大小和最后修改时间组成:http://httpd.apache.org/docs/2.2/mod/core.html#FileETag

    有不同的选项,您可以使它们可配置。我会给你一个可能的选项列表,从最不可靠到最可靠:

    1. [FASTEST OPTION] 以高于 1 秒的频率检查上次文件修改时间。例如,在 Windows 中,文件时间以 100 纳秒为间隔进行测量。还要像 Apache 一样检查文件大小和 inode。在 Windows 下,可以通过 GetFileInformationByHandle 查询打开句柄的文件 ID,而不是 inode。参见 nFileIndexHigh、nFileIndexLow;这分别是 64 位文件 ID 的高位和低位部分。如果文件时间、大小和 inode 发生了变化,请重新计算哈希。
    2. [更安全的选项] 除了文件时间、大小和 inode 之外,还可以使用 Intel (SSE4.2) 实现的非常快速的 CRC32 函数检查文件的内容——它比 SSE4.2 之前存在的任何 CRC32 实现都要快得多。如果文件时间或 CRC32 已更改,请重新计算哈希。
    3. [快速且安全的选项,但消耗句柄] 仅在您的服务器运行时计算哈希值。当你的服务器第一次启动时,它应该没有计算哈希值。如果第一次请求文件,则计算哈希值并将其存储到服务器退出。在服务器运行时,使用操作系统的文件更改通知监视文件更改(您拥有哈希值的文件)。例如,在 Widnows 中,有 FindFirstChangeNotification。

    对于 ETag 本身的散列值,我会推荐一种加密散列函数,即使是对于数字签名而言不再强大的散列函数。我不建议使用未明确设计为具有加密强度的散列函数,因为它们不会产生像加密散列那样小的摘要,以达到相当的抗冲突水平。碰撞是指两个不同的文件产生相同的哈希。 MD5 仍然非常适合文件内容更改监控——考虑到它的高速度和小摘要大小。它是最初为密码学设计的最快的 128 位散列函数。您还可以在汇编中找到快速的 MD5 实现,例如来自 OpenSSL 或来自 https://www.nayuki.io/page/fast-md5-hash-implementation-in-x86-assemblyhttps://github.com/maximmasiutin/MD5_Transform-x64 - 最后一个的性能是在具有 Skylake 微架构的处理器上每字节 4.94 个 CPU 周期。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2016-08-03
      • 1970-01-01
      • 1970-01-01
      • 2011-01-16
      • 1970-01-01
      • 2017-03-21
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多