• 首页
  • vue
  • TypeScript
  • JavaScript
  • scss
  • css3
  • html5
  • php
  • MySQL
  • redis
  • jQuery
  • 缓存指南

    本文档补充了mod_cache,mod_cache_disk,mod_file_cache和htcacheclean reference 文档。它描述了如何使用 Apache HTTP Server 的缓存 features 来加速 web 和代理服务,同时避免 common 问题和错误配置。

    简介

    Apache HTTP 服务器提供了一系列缓存 features,旨在以各种方式改善服务器的 performance。

    • Three-state RFC2616 HTTP 缓存
      mod_cache 及其提供者模块 mod_cache_disk 提供智能,HTTP-aware 缓存。内容本身存储在缓存中,mod_cache 旨在遵守控制内容可缓存性的所有各种 HTTP headers 和选项,如 RFC2616 第 13 节中所述。 mod_cache 针对简单和复杂的缓存配置,您要处理代理内容,动态本地内容或需要加速对可能较慢的磁盘上的本地 files 的访问。
    • Two-state key/value 共享 object 缓存
      共享 object 缓存 API(socache)及其提供程序模块提供基于服务器范围的 key/value 共享 object 缓存。这些模块旨在缓存低级数据,例如 SSL 会话和身份验证凭据。后端允许数据在服务器范围内存储在共享 memory 或数据中心范围内的缓存中,例如 memcache 或 distcache。
    • 专门的文件缓存
      mod_file_cache 提供了在服务器启动时 pre-load files 进入 memory 的能力,并且可以改善访问时间并在经常访问的 files 上保存文件句柄,因为不需要在每个请求上转到磁盘。

    要从本文档中获得最大收益,您应该熟悉 HTTP 的基础知识,并已阅读用户的 Guides 到将 URL 映射到文件系统和内容谈判。

    Three-state RFC2616 HTTP 缓存

    相关模块相关指令
    mod_cache
    mod_cache_disk
    CacheEnable
    CacheDisable
    UseCanonicalName
    CacheNegotiatedDocs

    HTTP 协议包含对 in-line 缓存机制由 RFC2616 的第 13 节描述的内置支持,mod_cache模块可用于利用此功能。

    与简单的两个 state key/value 缓存不同,其中内容在不再新鲜时完全消失,HTTP 缓存包括保留陈旧内容的机制,并询问原始服务器此陈旧内容是否已更改,如果不是,请再次刷新。

    HTTP 缓存中的条目存在以下三种状态之一:

    • 新鲜
      如果内容足够新(比其新鲜寿命更年轻),则认为是新鲜的。 HTTP 缓存可以自由地提供新鲜内容,而根本不对原始服务器进行任何 calls。
    • 陈旧
      如果内容太旧(早于其新鲜度生命周期),则认为是陈旧的。 HTTP 缓存应该联系原始服务器,并在向陈述者提供陈旧内容之前检查内容是否仍然是新鲜的。如果仍然无效,原始服务器将使用替换内容进行响应,或者理想情况下,源服务器将使用 code 响应以告知缓存内容仍然是新鲜的,而无需再次生成或发送内容。内容再次变得新鲜,循环继续。 HTTP 协议确实允许缓存在某些情况下提供过时数据,例如当尝试使用源服务器刷新数据时出现 5xx 错误,或者当另一个请求已经在刷新给定条目的过程中时。在这些情况下,会在响应中添加警告标头。
    • 不存在
      如果缓存已满,则保留从缓存中删除内容以腾出空间的选项。内容可以在任何时间删除,并且可以陈旧或新鲜。 htcacheclean 工具可以一次性运行 run,或者作为守护程序部署,以使缓存的大小保持在给定大小或给定数量的 inode 内。在尝试删除新内容之前,该工具会尝试删除陈旧内容。

    有关 HTTP 缓存如何工作的完整详细信息,请参见RFC2616 的第 13 节。

    与服务器的交互

    mod_cache模块在两个可能的位置挂钩到服务器,具体取决于CacheQuickHandler指令的 value:

    • 快速处理阶段这个阶段在请求处理期间很早就发生,就在解析请求之后。如果在缓存中找到内容,则立即提供该内容,并且几乎所有请求处理都被绕过。在这种情况下,缓存的行为就像它已经“闩上”到服务器的前面一样。此模式提供最佳性能,因为绕过了大多数服务器处理。但是,此模式也会绕过服务器处理的身份验证和授权阶段,因此在重要时应谨慎选择此模式。带有“授权”标头的请求(对于 example,HTTP 基本身份验证)既不可缓存也不能在此阶段运行时从缓存中提供。
    • 正常处理阶段
      在所有请求阶段完成之后,此阶段在请求处理的后期发生。在这种情况下,缓存的行为就像它已经“闩上”到服务器的后面一样。此模式提供了最大的灵活性,因为缓存可能存在于过滤器链中精确控制的点上,并且缓存的内容可以在发送到 client 之前进行过滤或个性化。

    如果在缓存中找不到 URL,mod_cache将在 order 中添加过滤到 record 对缓存的响应,然后停止,允许正常请求处理_继续。如果确定内容是可缓存的,则将内容保存到缓存中以供将来服务,否则将忽略该内容。

    如果在缓存中找到的内容是陈旧的,则mod_cache模块将请求转换为条件请求。如果源服务器以正常响应响应,则缓存正常响应,替换已缓存的内容。如果源服务器响应 304 Not Modified 响应,则内容将再次标记为新鲜,缓存的内容由过滤器提供,而不是保存。

    提高缓存命中率

    当许多不同服务器别名中的一个知道虚拟 host 时,确保将UseCanonicalName设置为On可以显着提高缓存命中率。这是因为服务内容的 virtual-host 的主机名在缓存 key 中使用。将设置设置为On virtual-hosts 且具有多个服务器名称或别名将不会生成不同的缓存实体,而是根据规范主机名缓存内容。

    新鲜寿命

    要用于缓存的格式良好的内容应使用Cache-Control标头的max-ages-maxage字段声明显式新鲜度生命周期,或者包含Expires标头。

    在同一 time 时,client 在请求中显示自己的Cache-Control标头时,client 可以覆盖原始服务器定义的新鲜度生命周期。在这种情况下,请求和响应之间的最低新鲜度生命周期获胜。

    当请求或响应中缺少此新鲜度生命周期时,将应用默认新鲜度生命周期。缓存实体的默认新鲜度生命周期为一小时,但使用CacheDefaultExpire指令可以轻松实现 over-ridden。

    如果响应不包含Expires标头但包含Last-Modified标头,mod_cache可以基于启发式推断新鲜度生命周期,可以通过使用CacheLastModifiedFactor指令来控制。

    对于本地内容,或者对于没有定义自己的Expires标头的 remote 内容,可以通过添加max-ageExpires来使用mod_expires来实现新鲜度。

    也可以通过使用CacheMaxExpire来控制最大新鲜度寿命。

    有条件请求简要指南

    当内容从缓存过期并变得陈旧时,httpd 将修改请求以使其成为条件。

    当原始缓存响应中存在ETag标头时,mod_cache将向请求发送原始服务器的If-None-Match标头。当原始缓存响应中存在Last-Modified标头时,mod_cache将向请求发送原始服务器的If-Modified-Since标头。执行这些操作之一会使请求有条件。

    当源服务器接收到条件请求时,源服务器应根据请求检查 ETag 或 Last-Modified 参数是否已更改。如果不是,原点应该以简洁的“304 Not Modified”响应进行响应。这向缓存发出信号,表明陈旧内容仍然是新鲜的,应该用于后续请求,直到再次达到内容的新的新鲜度生命周期。

    如果内容已更改,则提供内容,就好像请求不是以条件开头一样。

    有条件请求提供两个好处。首先,当向源服务器发出这样的请求时,如果来自源的内容与高速缓存中的内容匹配,则可以容易地确定,并且没有转移整个资源的开销。

    其次,设计良好的源服务器将以这样的方式设计:条件请求的生成要比完整响应便宜得多。对于静态 files,通常所涉及的是对stat()或类似系统调用的调用,以查看文件的大小是否已更改或修改 time。因此,如果本地内容没有改变,甚至可以从高速缓存中更快地提供本地内容。

    原始服务器应尽可能地支持条件请求,但是如果不支持条件请求,则源将响应,就好像请求不是有条件的,并且缓存将响应,就好像内容已更改并保存新内容到缓存。在这种情况下,缓存的行为类似于简单的两个 state 缓存,其中内容实际上是新鲜的或已删除。

    什么可以缓存?

    HTTP 缓存可以缓存哪些响应的完整定义在RFC2616 Section 13.4 Response Cacheability中定义,可以总结如下:

    • 必须为此 URL 启用缓存。请参阅CacheEnable和CacheDisable指令。
    • 如果响应的 HTTP 状态 code 不是 200,203,300,301 或 410,则它还必须指定“Expires”或“Cache-Control”标头。
    • 请求必须是 HTTP GET 请求。
    • 如果响应包含“Authorization:”标头,则它还必须在“Cache-Control:”标头中包含“s-maxage”,“must-revalidate”或“public”选项,否则它将不会被缓存。
    • 如果 URL 包含查询 string(来自 HTML 表单 GET 方法的 e.g.),则除非响应通过包含“Expires:”标头或“Cache-Control:”标头的 max-age 或 s-maxage 指令指定显式过期,否则不会缓存该 URL ,根据 RFC2616 部分 13.9 和 13.2.1.
    • 如果响应的状态为 200(OK),则响应还必须包括“Etag”,“Last-Modified”或“Expires”headers 中的至少一个,或者“Cache-Control:”标题的 max-age 或 s-maxage 指令,除非CacheIgnoreNoLastMod指令已被用于另外要求。
    • 如果响应在“Cache-Control:”标题中包含“private”选项,则除非CacheStorePrivate已被用于另外要求,否则不会存储该选项。
    • 同样,如果响应在“Cache-Control:”标题中包含“no-store”选项,则除非已使用CacheStoreNoStore,否则不会存储该选项。
    • 如果响应包含包含 match-all“*”的“Vary:”标题,则不会存储响应。

    什么不应该缓存?

    它应该由 client 创建请求,或构建响应的原始服务器通过正确设置Cache-Control标头来决定内容是否应该是可缓存的,并且mod_cache应该单独保留以满足 client 的意愿或适当的服务器。

    不应缓存 time 敏感的内容,或根据 HTTP negotiation 未涵盖的请求的详细信息而变化的内容。此内容应使用Cache-Control标头声明自己不可缓存。

    如果内容经常更改,以分钟或秒的新鲜度生命周期表示,内容仍然可以缓存,但是非常希望源服务器正确支持条件请求以确保不必生成完整响应定期。

    根据 client 提供的请求 headers 而变化的内容可以通过智能使用Vary响应头来缓存。

    Variable/Negotiated 内容

    当原始服务器设计为基于请求中 headers 的 value 响应不同的内容时,为了 example 在同一 URL 上提供多种语言,HTTP 的缓存机制可以在同一 URL 上缓存同一页面的多个变体。

    这是由原始服务器添加Vary标头来完成的,以指示在确定两个变体是否彼此不同时,高速缓存必须考虑哪些_header。

    如果是 example,则收到带有变量标题的响应,例如;

    Vary: negotiate,accept-language,accept-charset

    mod_cache仅将缓存的内容提供给请求者,其中 accept-language 和 accept-charset headers 与原始请求的匹配。

    内容的多个变体可以并排缓存,mod_cache使用Vary标头和Vary列出的请求 headers 的相应值来决定 return 到 client 的多个变体中的哪一个。

    缓存设置示例

    相关模块相关指令
    mod_cache
    mod_cache_disk
    mod_cache_socache
    mod_socache_memcache
    CacheEnable
    CacheRoot
    CacheDirLevels
    CacheDirLength
    CacheSocache

    缓存到磁盘

    mod_cache模块依赖 order 中的特定后端 store implementations 来管理缓存,并且提供缓存到磁盘mod_cache_disk以支持这一点。

    通常,模块将如此配置;

    CacheRoot   "/var/cache/apache/"
    CacheEnable disk /
    CacheDirLevels 2
    CacheDirLength 1
    

    重要的是,由于缓存的 files 是本地存储的,操作系统 in-memory 缓存通常也会应用于它们的访问。因此,虽然 files 存储在磁盘上,但如果经常访问它们,操作系统很可能会确保它们实际上是从 memory 提供的。

    了解 Cache-Store

    要在缓存中存储项目,mod_cache_disk会创建所请求 URL 的 22 个字符的哈希值。此哈希将主机名,协议,port,路径和任何 CGI arguments 合并到 URL,以及由 Vary 头定义的元素,以确保多个 URL 不会相互冲突。

    每个字符可以是 64-different 个字符中的任何一个,这意味着整体上有 64 ^ 22 个可能的哈希值。对于 example,可能会将 URL 哈希到xyTGxSMO2b68mBCykqkp1w。此哈希用作在缓存中命名特定于该 URL 的 files 的前缀,但首先根据CacheDirLevels和CacheDirLength指令将其拆分为目录。

    CacheDirLevels指定应该有多少级别的子目录,CacheDirLength指定每个目录中应该有多少个字符。使用上面给出的 example 设置,哈希将被转换为文件名前缀为/var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w

    此技术的总体目标是减少可能在特定目录中的子目录或 files 的数量,因为大多数 file-systems 随着此数量的增加而减慢。对于CacheDirLength设置为“1”,在任何特定的 level 最多可以有 64 个子目录。设置为 2 时,可以有 64 * 64 个子目录,依此类推。除非你有充分的理由不这样做,否则建议使用“1”设置为CacheDirLength。

    设置CacheDirLevels取决于您预期在缓存中存储的 files 数量。通过上述 example 中使用的“2”设置,最终可以创建总共 4096 个子目录。有 100 万个 files 缓存,每个目录大约有 245 个缓存的 URL。

    每个 URL 在 cache-store 中至少使用两个 files。通常有一个“.header”文件,其中包含有关 URL 的 meta-information,例如它何时到期以及“.data”文件,该文件是要提供的内容的逐字副本。

    在通过“Vary”标头协商的内容的情况下,将为所讨论的 URL 创建“.vary”目录。该目录将具有与不同协商内容相对应的多个“.data”文件。

    维护磁盘缓存

    mod_cache_disk模块不会尝试调节缓存使用的磁盘空间量,尽管它会优雅地停止任何磁盘错误,并且表现得好像缓存从未出现过一样。

    相反,提供 httpd 的是htcacheclean工具,它允许您定期清理缓存。确定 run htcacheclean的频率以及用于缓存的目标大小有些复杂,可能需要尝试反复来选择最佳值。

    htcacheclean有两种操作模式。它可以作为持久守护进程 run,或者定期从 cron 运行。 htcacheclean可能需要长达一个小时或更长时间来处理非常大(几十千兆字节)的缓存,如果你从 cron 中运行它,建议你确定一个典型的 run 如何 long,以避免在 time 运行多个实例。

    还建议为 htcacheclean 选择适当的“nice”level,以便在服务器运行时该工具不会导致过多的磁盘 io。

    图 1:典型的缓存增长/清理顺序。

    因为mod_cache_disk本身并不注意使用了多少空间,所以应该确保htcacheclean配置为在干净后留下足够的“成长空间”。

    缓存到 memcached

    使用mod_cache_socache模块,mod_cache可以缓存来自各种 implementations(又名:“provider”)的数据。使用mod_socache_memcache模块,对于 example,可以指定memcached将用作后端存储机制。

    通常,模块将配置为:

    CacheEnable socache /
    CacheSocache memcache:memcd.example.com:11211
    

    可以通过将它们附加到以逗号分隔的CacheSocache memcache: line 的末尾来指定其他memcached服务器:

    CacheEnable socache /
    CacheSocache memcache:mem1.example.com:11211,mem2.example.com:11212
    

    此格式也与其他各种mod_cache_socache提供程序一起使用。例如:

    CacheEnable socache /
    CacheSocache shmcb:/path/to/datafile(512000)
    
    CacheEnable socache /
    CacheSocache dbm:/path/to/datafile
    

    常规 Two-state Key/Value 共享 Object 缓存

    相关模块相关指令
    mod_authn_socache
    mod_socache_dbm
    mod_socache_dc
    mod_socache_memcache
    mod_socache_shmcb
    mod_ssl
    AuthnCacheSOCache
    SSLSessionCache
    SSLStaplingCache

    Apache HTTP 服务器提供低 level 共享 object 缓存,用于在socache接口内缓存 SSL 会话或身份验证凭据等信息。

    为每个 implementation 提供了附加模块,提供以下后端:

    • mod_socache_dbm
      基于 DBM 的共享 object 缓存。
    • mod_socache_dc
      基于 Distcache 的共享 object 缓存。
    • mod_socache_memcache
      基于 Memcache 的共享 object 缓存。
    • mod_socache_shmcb
      共享基于 memory 的共享 object 缓存。

    缓存身份验证凭据

    相关模块相关指令
    mod_authn_socacheAuthnCacheSOCache

    mod_authn_socache模块允许缓存身份验证的结果,从而减轻身份验证后端的负载。

    缓存 SSL 会话

    相关模块相关指令
    mod_sslSSLSessionCache
    SSLStaplingCache

    mod_ssl模块使用socache接口提供 session 缓存和装订缓存。

    专用文件缓存

    相关模块相关指令
    mod_file_cache求 CacheFile
    MMapFile

    在文件系统可能很慢或文件句柄很昂贵的平台上,启动时 pre-load files 会进入 memory。

    在打开 files 很慢的系统上,存在在启动时打开文件并缓存文件句柄的选项。这些选项可以帮助对静态 files 访问速度较慢的系统。

    File-Handle 缓存

    打开文件的行为本身可能是延迟的来源,特别是在网络文件系统上。通过维护常用服务 files 的打开文件描述符的缓存,httpd 可以避免这种延迟。目前 httpd 提供了 File-Handle 缓存的一个 implementation。

    求 CacheFile

    httpd 中最基本的缓存形式是mod_file_cache提供的 file-handle 缓存。此缓存不是缓存 file-contents,而是维护一组 table 的打开文件描述符。使用求 CacheFile指令在 configuration 文件中指定以这种方式缓存的文件。

    求 CacheFile指令指示 httpd 在启动时打开文件,并指示 re-use 这 file-handle 以便随后访问此文件。

    CacheFile /usr/local/apache2/htdocs/index.html
    

    如果您打算以这种方式缓存大量 files,则必须确保正确设置操作系统对 open files 数量的限制。

    虽然使用求 CacheFile不会导致 file-contents 被缓存 per-se,但它确实意味着如果文件在 httpd 运行时发生变化,则这些更改将不会被选中。该文件将始终像 httpd 启动时那样提供服务。

    如果在 httpd 为 running 时删除了该文件,它将继续维护一个打开的文件描述符并按照启动 httpd 时的文件提供服务。这通常也意味着虽然该文件已被删除,并且未显示在文件系统上,但在 httpd 停止并且文件描述符关闭之前,将无法恢复额外的可用空间。

    In-Memory 缓存

    直接从 system memory 服务是普遍提供内容的最快方法。从磁盘控制器读取 files,或者更糟糕的是,从 remote 网络读取 files 的速度要低几个数量级。磁盘控制器通常涉及物理过程,网络访问受可用带宽的限制。另一方面,Memory 访问只需 nano-seconds。

    系统 memory 虽然不便宜,但是字节数字是迄今为止最昂贵的存储类型,确保它有效使用非常重要。通过在 memory 中缓存 files,可以减少系统上可用的 memory 数量。正如我们所看到的,在操作系统缓存的情况下,这不是一个问题,但是当使用 httpd 自己的 in-memory 缓存时,确保不要为缓存分配太多的 memory 是很重要的。否则系统将被迫换出 memory,这可能会降低 performance。

    操作系统缓存

    几乎所有现代操作系统都在 memory 中直接由内核管理 file-data。这是一个强大的 feature,并且在大多数情况下操作系统都是正确的。例如,在 Linux 上,让我们看看在第一个 time 和第二个 time 读取文件所需的 time 的差异;

    colm@coroebus:~$ time cat testfile > /dev/null
    real    0m0.065s
    user    0m0.000s
    sys     0m0.001s
    colm@coroebus:~$ time cat testfile > /dev/null
    real    0m0.003s
    user    0m0.003s
    sys     0m0.000s
    

    即使对于这个小文件,读取文件所需的 time 量也存在巨大差异。这是因为内核已经缓存了 memory 中的文件内容。

    通过确保系统上有“备用”memory,您可以确保将越来越多的 file-contents 存储在此缓存中。这可能是一种非常有效的 in-memory 缓存方式,并且根本不涉及 httpd 的额外配置。

    此外,由于操作系统知道删除或修改 files 的时间,因此可以在必要时自动从缓存中删除文件内容。与 httpd 的 in-memory 缓存相比,这是一个很大的优势,它无法知道文件何时发生了变化。

    尽管自动操作系统缓存具有性能和优点,但在某些情况下,httpd 可以更好地执行 in-memory 缓存。

    MMapFile 缓存

    mod_file_cache提供了MMapFile指令,它允许您在启动 time 时将 httpd map 静态文件的内容放入 memory(使用 mmap 系统调用)。 httpd 将使用 in-memory 内容进行对该文件的所有后续访问。

    MMapFile /usr/local/apache2/htdocs/index.html
    

    与求 CacheFile指令一样,httpd 启动后,这些 files 中的任何更改都不会被 httpd 拾取。

    MMapFile指令不跟踪它分配了多少 memory,因此您必须确保不要 over-use 指令。每个 httpd 子进程都将复制此 memory,因此确保映射的 files 不会导致系统交换 memory 非常重要。

    安全注意事项

    授权和访问控制

    在CacheQuickHandler的默认 state 中使用mod_cache,其中CacheQuickHandler设置为On非常类似于将高速缓存 reverse-proxy 用螺栓连接到服务器的前端。请求将由缓存模块提供,除非它确定应该像外部缓存一样查询源服务器,这会彻底改变 httpd 的安全性 model。

    遍历文件系统层次结构以检查潜在的.htaccess files 将是一个非常昂贵的操作,部分地破坏缓存点(加速请求),mod_cache不做出关于缓存实体是否被授权服务的决定。换一种说法;如果mod_cache缓存了某些内容,它将从缓存中提供为 long,因为该内容尚未过期。

    例如,如果您的 configuration 允许通过 IP 地址访问资源,则应确保不缓存此内容。您可以使用CacheDisable指令或mod_expires来执行此操作。如果不加以控制,mod_cache -非常像反向代理- 将在提供时缓存内容,然后将其提供给任何 IP 地址上的任何客户端。

    当CacheQuickHandler指令设置为Off时,将执行完整的请求处理阶段集,并且 security model 保持不变。

    本地漏洞

    由于可以从缓存提供对 end-users 的请求,缓存本身可以成为那些希望破坏或干扰内容的人的目标。重要的是要记住,缓存必须始终由 httpd 正在运行的用户写入。这与通常建议的维护 Apache 用户无法写入的所有内容的情况形成鲜明对比。

    如果 Apache 用户受到攻击,对于 example,通过 CGI process 中的缺陷,可能会定位缓存。使用mod_cache_disk时,插入或修改缓存实体相对容易。

    与作为 Apache 用户可能产生的其他类型的攻击相比,这会带来一定程度的风险。如果你使用的是mod_cache_disk,你应该记住这一点- 确保在宣布安全升级时升级 httpd,并且 run CGI 如果可能的话使用suEXEC作为 non-Apache 用户进行处理。

    缓存中毒

    当 running httpd 作为缓存代理服务器时,也存在 so-called 缓存中毒的可能性。缓存中毒是攻击的广义术语,攻击者使代理服务器从源服务器检索不正确(通常是不合需要的)内容。

    例如,如果您的系统 running httpd 使用的 DNS 服务器容易受到 DNS 缓存中毒的攻击,则攻击者可能能够控制 httpd 在从源服务器请求内容时连接到的位置。另一个例子是 so-called HTTP request-smuggling 攻击。

    这个文件不适合 in-depth 讨论 HTTP 请求走私(相反,请尝试您最喜欢的搜索引擎),但重要的是要知道可以发出一系列请求,并利用源上的漏洞网络服务器,以便攻击者可以完全控制代理检索的内容。

    拒绝服务/ Cachebusting

    Vary 机制允许并行缓存同一 URL 的多个变体。根据 client 提供的标头值,缓存将选择正确的变量以 return 到 client。当尝试在正常使用时已知包含大量可能值的标题上进行变化时,例如User-Agent标题,此机制可能会成为问题。根据特定 web 站点的受欢迎程度,可以为同一 URL 创建数千或数百万个重复缓存条目,从而挤出缓存中的其他条目。

    在其他情况下,可能需要在每个请求上更改特定资源的 URL,通常是通过向 URL 添加“cachebuster”string。如果服务器将此内容声明为可缓存的生命周期,则这些条目可以挤出缓存中的合法条目。虽然mod_cache提供了CacheIgnoreURLSessionIdentifiers指令,但应谨慎使用此指令,以确保下游代理或浏览器缓存不会受到相同的拒绝服务问题。

    上篇:配置部分

    下篇:内容协商