1.6 http缓存

HTTP 代理缓存

HTTP 代理缓存

HTTP 代理缓存使您能够存储经常访问的 Web 对象（例如文档、图像和文章）的副本，然后根据需要将这些信息提供给用户。它提高了性能并为其他任务释放了 Internet 带宽。

 

了解 HTTP Web 代理缓存

Internet 用户将他们的请求定向到整个 Internet 上的 Web 服务器。缓存服务器必须充当Web 代理服务器才能为这些请求提供服务。在 Web 代理服务器收到对 Web 对象的请求后，它要么为请求提供服务，要么将它们转发到源服务器（包含所请求信息的原始副本的 Web 服务器）。Traffic Server 代理支持显式代理缓存，其中用户的客户端软件必须配置为直接向 Traffic Server 代理发送请求。以下概述说明了 Traffic Server 如何处理请求。

1. Traffic Server 接收客户端对 Web 对象的请求。

2. 使用对象地址，Traffic Server 尝试在其对象数据库（缓存）中定位请求的对象。

3. 如果对象在缓存中，则 Traffic Server 会检查对象是否足够新鲜以供服务。如果它是新鲜的，则 Traffic Server 将其作为缓存命中（见下图）提供给客户端。

   

    

    

   1. 如果缓存中的数据陈旧，则 Traffic Server 连接到源服务器并检查对象是否仍然新鲜（ 重新验证）。如果是，则 Traffic Server 立即将缓存的副本发送到客户端。

   2. 如果对象不在缓存中（缓存未命中）或者服务器指示缓存副本不再有效，则 Traffic Server 从源服务器获取对象。然后对象同时传输到客户端和 Traffic Server 本地缓存（见下图）。可以更快地为对象的后续请求提供服务，因为该对象是直接从缓存中检索的。

      

       

       

      缓存通常比前面的概述所建议的更复杂。特别是，概述没有讨论 Traffic Server 如何确保新鲜度，提供正确的 HTTP 替代，以及处理对不能或不应该缓存的对象的请求。以下各节更详细地讨论了这些问题。

      确保缓存对象的新鲜度

      当 Traffic Server 收到一个 web 对象的请求时，它首先尝试在它的缓存中定位请求的对象。如果对象在缓存中，则 Traffic Server 会检查对象是否足够新鲜以供服务。对于 HTTP 对象，Traffic Server 支持可选的作者指定的到期日期。Traffic Server 遵守这些到期日期；否则，它会根据对象更改的频率和管理员选择的新鲜度准则来选择到期日期。还可以通过检查源服务器以查看对象是否仍然新鲜来重新验证对象。

      HTTP 对象新鲜度

      Traffic Server 通过依次检查以下条件来确定缓存中的 HTTP 对象是否是新鲜的：

      • 检查 Expires 或 max-age 标题

        一些 HTTP 对象包含明确定义对象可以缓存多长时间的Expires头或max-age头。Traffic Server 将当前时间与过期时间进行比较，以确定对象是否仍然新鲜。

      • 检查 Last-Modified / Date 标题

        如果 HTTP 对象没有Expires标头或max-age标头，则 Traffic Server 可以使用以下公式计算新鲜度限制：

        freshness_limit = ( date - last_modified ) * 0.10
        

        其中date是对象服务器响应标头中的日期，last_modified是标头中的日期Last-Modified。如果没有Last-Modified标头，则 Traffic Server 使用对象写入缓存的日期。0.10可以增加或减少该值(10%) 以更好地满足您的需求。

      • 检查绝对新鲜度限制

        对于没有Expires标头或没有标头Last-Modified和Date标头的HTTP 对象，Traffic Server 使用最大和最小新鲜度限制。

        • 检查重新验证规则 cache.config

          重新验证规则对特定 HTTP 对象应用新鲜度限制。您可以为源自特定域或 IP 地址的对象、具有包含指定正则表达式的 URL 的对象、特定客户端请求的对象等设置新鲜度限制。参考cache.config。

        修改新鲜度计算的老化因子

        如果对象不包含任何过期信息，则 Traffic Server 可以从Last-Modified和 Date标头估计其新鲜度。默认情况下，Traffic Server 将对象存储自上次更改以来经过的时间的 10%。您可以根据需要增加或减少百分比。

        要修改新鲜度计算的老化因子：

        1. 更改 的值proxy.config.http.cache.heuristic_lm_factor。

        2. 运行命令以应用配置更改。traffic_ctl config reload

        设置绝对新鲜度限制

        某些对象没有Expires标题或没有 Last-Modified和Date标题。要控制这些对象在缓存中被视为新鲜的时间，请指定绝对新鲜度限制。

        要指定绝对新鲜度限制：

        1. 编辑变量proxy.config.http.cache.heuristic_min_lifetime 并proxy.config.http.cache.heuristic_max_lifetime在 records.config.

        2. 运行命令以应用配置更改。traffic_ctl config reload

        指定标题要求

        为了进一步确保缓存中对象的新鲜度，将 Traffic Server 配置为仅缓存具有特定标头的对象。默认情况下，Traffic Server 缓存所有对象（包括没有头部的对象）；您应该仅针对特殊代理情况更改默认设置。如果您将 Traffic Server 配置为仅缓存带有Expires或max-age标头的HTTP 对象，那么缓存命中率将显着降低（因为很少有对象具有明确的过期信息）。

        配置 Traffic Server 缓存具有特定标头的对象：

        1. 更改proxy.config.http.cache.required_headers in的值records.config。

        2. 运行命令以应用配置更改。traffic_ctl config reload

        缓存控制头

        即使对象在缓存中可能是新鲜的，客户端或服务器通常也会强加自己的约束，从而阻止从缓存中检索对象。例如，客户端可能请求不从缓存中检索对象，或者如果它允许缓存检索，则它的缓存时间不能超过 10 分钟。

        Traffic Server 将缓存对象的可服务性基于Cache-Control 出现在客户端请求和服务器响应中的标头。以下 Cache-Control标头会影响是否从缓存中提供对象：

        • no-cache客户端发送的标头告诉 Traffic Server 它不应该直接从缓存中提供任何对象。当出现在客户端请求中时，Traffic Server 将始终从源服务器获取对象。您可以将 Traffic Server 配置为忽略客户端 no-cache标头。有关详细信息，请参阅配置 Traffic Server 以忽略客户端无缓存标头 。

        • max-age由服务器发送的标头与对象年龄进行比较。如果年龄小于max-age，则对象是新鲜的，可以从 Traffic Server 缓存中提供服务。

        • min-fresh客户端发送的标头是可接受的新鲜度容限。这意味着客户希望对象至少是新鲜的。除非缓存对象在未来至少这么长时间保持新鲜，否则它会被重新验证。

        • max-stale客户端发送的标头允许 Traffic Server 为陈旧的对象提供服务，只要它们不是太旧。某些浏览器可能愿意使用稍微陈旧的对象来换取性能的提高，尤其是在 Internet 可用性较差的时期。

        Traffic ServerCache-Control在 HTTP 新鲜度标准之后应用可服务性标准。例如，一个对象可能被认为是新鲜的，但如果其年龄大于其max-age.

        重新验证 HTTP 对象

        当客户端请求缓存中过时的 HTTP 对象时，Traffic Server 重新验证该对象。一个重新确认是一个查询到源服务器检查对象是不变的。重新验证的结果是以下之一：

        • 如果对象仍然是新鲜的，则 Traffic Server 重置其新鲜度限制并为该对象提供服务。

        • 如果对象的新副本可用，则 Traffic Server 缓存新对象（从而替换过时的副本）并同时将对象提供给客户端。

        • 如果源服务器上不再存在该对象，则 Traffic Server 不会为缓存副本提供服务。

        • 如果源服务器没有响应重新验证查询，则 Traffic Server 会提供过时的对象以及 警告。111 Revalidation Failed

        默认情况下，Traffic Server 会在缓存中重新验证请求的 HTTP 对象，如果它认为该对象已过期。Traffic Server 评估对象新鲜度，如HTTP 对象新鲜度中所述。您可以通过选择以下选项之一来重新配置 Traffic Server 评估新鲜度的方式：

        Traffic Server 认为缓存中的所有 HTTP 对象都是陈旧的：

        始终使用源服务器重新验证缓存中的 HTTP 对象。

        Traffic Server 认为缓存中的所有 HTTP 对象都是新鲜的：

        永远不要使用源服务器重新验证缓存中的 HTTP 对象。

        Traffic Server 认为所有没有Expires或头的HTTP 对象Cache-control都是陈旧的：

        重新验证所有没有Expires或Cache-Control标头的HTTP 对象。

        要配置 Traffic Server 如何重新验证缓存中的对象，您可以在cache.config.

        配置重新验证选项

        1. 编辑变量proxy.config.http.cache.when_to_revalidate 在records.config。

        2. 运行命令以应用配置更改。traffic_ctl config reload

        将内容推送到缓存中

        Traffic Server 支持PUSH内容传递的 HTTP方法。使用 HTTP PUSH，您可以将内容直接传送到缓存中，而无需客户端请求。

        为 PUSH 请求配置 Traffic Server

        在使用 HTTP 将内容传送到缓存之前PUSH，您必须配置 Traffic Server 以接受PUSH请求。

        1. 编辑ip_allow.yaml以允许PUSH来自适当的地址。

        2. 更新proxy.config.http.push_method_enabled于 records.config：

           CONFIG proxy.config.http.push_method_enabled INT 1
           

        3. 运行命令以应用配置更改。traffic_ctl config reload

        理解 HTTP PUSH

        PUSH使用 HTTP 1.1 消息格式。PUSH 请求的正文包含要放入缓存中的响应标头和响应正文。以下是一个PUSH请求示例：

        PUSH http://www.company.com HTTP/1.0
        Content-length: 84
        
        HTTP/1.0 200 OK
        Content-type: text/html
        Content-length: 17
        
        <HTML>
        a
        </HTML>
        

        重要的

        您的PUSH标头必须包含Content-length，其值必须同时包含标头和正文字节数。该值不是可选的，不正确（太大或太小）的值将导致不良行为。

        有助于管理推送的工具

        Traffic Server 自带了一个 Perl 的推送脚本tspush，它可以帮助理解如何自己编写推送内容的脚本。

        在缓存中固定内容

        该缓存钢钉选项配置Traffic Server的保持一定的HTTP对象在缓存中指定的时间。您可以使用此选项来确保最常用的对象在需要时在缓存中，并防止 Traffic Server 删除重要的对象。Cache-Control只有当它确实可缓存时，Traffic Server才会观察标头并将对象固定在缓存中。

        设置缓存固定规则：

        1. 启用proxy.config.cache.permit.pinning于records.config：

           CONFIG proxy.config.cache.permit.pinning INT 1
           

        2. cache.config为您希望 Traffic Server 固定在缓存中的每个 URL添加规则。例如：

           url_regex=^https?://(www.)?apache.org/dev/ pin-in-cache=12h
           

        3. 运行命令以应用配置更改。traffic_ctl config reload

        缓存 HTTP 对象

        当 Traffic Server 收到对不在缓存中的 Web 对象的请求时，它会从源服务器检索该对象并将其提供给客户端。同时，Traffic Server 检查对象是否可缓存，然后将其存储在其缓存中以服务未来的请求。

        Traffic Server 响应来自客户端和源服务器的缓存指令，以及您通过配置选项和文件指定的指令。

        客户指令

        默认情况下，Traffic Server 不会缓存具有以下请求标头的对象：

        • Authorization

        • Cache-Control: no-store

        • Cache-Control: no-cache

          配置 Traffic Server 忽略这个请求头，参考 配置 Traffic Server 忽略客户端 no-cache Headers。

        • Cookie （对于文本对象）

          默认情况下，Traffic Server 缓存对象以响应包含 cookie 的请求（即使对象是文本）。您可以将 Traffic Server 配置为不缓存任何类型的 cookie 内容、缓存所有 cookie 内容或仅缓存图像类型的 cookie 内容。有关更多信息，请参阅缓存 Cookied 对象。

        配置 Traffic Server 忽略客户端 no-cache headers

        默认情况下，Traffic Server 严格遵守客户端 指令。如果请求的对象包含一个 头部，那么即使它在缓存中有一个新的副本，Traffic Server 也会将请求转发到源服务器。您可以将 Traffic Server 配置为忽略客户端指令，以便它忽略来自客户端请求的标头并从其缓存中提供对象。Cache-Control: no-cacheno-cacheno-cacheno-cache

        1. 编辑proxy.config.http.cache.ignore_client_no_cache在 records.config。

           CONFIG proxy.config.http.cache.ignore_client_no_cache INT 1
           

        2. 运行命令以应用配置更改。traffic_ctl config reload

        源服务器指令

        默认情况下，Traffic Server 不会缓存具有以下响应头的对象：

        • Cache-Control: no-store

        • Cache-Control: private

        • WWW-Authenticate

          要将 Traffic Server 配置为忽略WWW-Authenticate标头，请参阅配置 Traffic Server 以忽略 WWW-Authenticate 标头。

        • Set-Cookie

        • Cache-Control: no-cache

          要将 Traffic Server 配置为忽略no-cache标头，请参阅 配置 Traffic Server 以忽略服务器 no-cache 标头。

        • Expires 值为 0（零）或过去日期的标头。

        配置 Traffic Server 忽略服务器 no-cache 标头

        默认情况下，Traffic Server 严格遵守 指令。来自带有标头的源服务器的响应不会存储在缓存中，并且缓存中对象的任何先前副本都将被删除。如果您将 Traffic Server 配置为忽略 标头，则 Traffic Server 也会忽略标头。在大多数情况下，观察指令的默认行为是合适的。Cache-Control: no-cacheno-cacheno-cacheno-storeno-cache

        配置 Traffic Server 忽略服务器no-cache头：

        1. 编辑proxy.config.http.cache.ignore_server_no_cache在 records.config。

           CONFIG proxy.config.http.cache.ignore_server_no_cache INT 1
           

        2. 运行命令以应用配置更改。traffic_ctl config reload

        配置 Traffic Server 忽略 WWW-Authenticate 标头

        默认情况下，Traffic Server 不缓存包含WWW-Authenticate响应头的对象 。该WWW-Authenticate头包含认证参数客户端使用准备认证质询响应到源服务器时。

        当您将 Traffic Server 配置为忽略源服务器 WWW-Authenticate标头时，所有带有WWW-Authenticate 标头的对象都存储在缓存中以供将来请求使用。但是，不缓存带有WWW-Authenticate 标头的对象的默认行为在大多数情况下是合适的。WWW-Authenticate如果您了解 HTTP 1.1，则仅将 Traffic Server 配置为忽略服务器标头。

        配置 Traffic Server 忽略服务器WWW-Authenticate 头：

        1. 编辑proxy.config.http.cache.ignore_authentication在 records.config。

           CONFIG proxy.config.http.cache.ignore_authentication INT 1
           

        2. 运行命令以应用配置更改。traffic_ctl config reload

        配置指令

        除了客户端和源服务器指令之外，Traffic Server 还响应您通过配置选项和文件指定的指令。

        您可以配置 Traffic Server 执行以下操作：

        • 不缓存任何 HTTP 对象。请参阅禁用 HTTP 对象缓存。

        • 缓存动态内容。也就是说，URL.asp以问号 ( ?)、分号 ( ;) 或cgi. 有关更多信息，请参阅缓存动态内容。

        • 响应Cookie:标头而提供的缓存对象。请参阅 缓存 Cookied 对象。

        • 遵守中的never-cache规则cache.config。

        禁用 HTTP 对象缓存

        默认情况下，Traffic Server的缓存，除了那些设置了所有HTTP对象never-cache的操作规则 在cache.config。您可以禁用 HTTP 对象缓存，以便直接从源服务器提供所有 HTTP 对象并且从不缓存，如下所述。

        手动禁用 HTTP 对象缓存：

        1. 设置proxy.config.http.cache.http要0在records.config。

           CONFIG proxy.config.http.cache.http INT 0
           

        2. 运行命令以应用配置更改。traffic_ctl config reload

        缓存动态内容

        如果 URL.asp以问号 ( ?)、分号 ( ;) 或cgi. 默认情况下，Traffic Server 缓存动态内容。您可以将系统配置为忽略动态外观的内容，尽管只有在内容真正是动态的情况下才建议这样做，但无法使用适当的Cache-Control标题进行广告。

        为动态内容配置 Traffic Server 的缓存行为：

        1. 编辑proxy.config.http.cache.cache_urls_that_look_dynamic在 records.config。要禁用缓存，请将变量设置为0，并明确允许缓存使用1。

           CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0
           

        2. 运行命令以应用配置更改。traffic_ctl config reload

        缓存 Cookied 对象

        默认情况下，Traffic Server 缓存对象以响应包含 cookie 的请求。这适用于所有类型的对象，包括文本。Traffic Server 不缓存 cookie 文本内容，因为对象头与对象一起存储，个性化的 cookie 头值可以与对象一起保存。对于非文本对象，不太可能传递或使用个性化标题。

        您可以将 Traffic Server 重新配置为：

        • 不缓存任何类型的 cookie 内容。

        • 缓存仅属于图像类型的 cookie 内容。

        • 无论类型如何，都缓存所有 cookie 内容。

        配置 Traffic Server 如何缓存 cookie 内容：

        1. 编辑proxy.config.http.cache.cache_responses_to_cookies在 records.config。

        2. 运行命令以应用配置更改。traffic_ctl config reload

        强制对象缓存

        您可以强制 Traffic Server 在指定的持续时间内缓存特定的 URL（包括动态 URL），而不管Cache-Control响应头如何。

        强制文档缓存：

        1. 为您希望 Traffic Server 固定到缓存的每个 URL 添加一个规则 cache.config：

           url_regex=^https?://(www.)?apache.org/dev/ ttl-in-cache=6h
           

        2. 运行命令以应用配置更改。traffic_ctl config reload

        缓存 HTTP 替代方案

        一些源服务器使用各种对象来响应对同一 URL 的请求。这些对象的内容可能会有很大差异，具体取决于服务器是否为不同语言提供内容、针对具有不同呈现风格的不同浏览器，或者提供不同的文档格式（HTML、XML）。同一对象的不同版本被称为备用对象，并由 Traffic Server 根据Vary响应头进行缓存。您还可以限制缓存中允许的对象替代版本的数量。

        限制对象的替代数量

        您可以限制 Traffic Server 可以缓存每个对象的备用数量（默认为 3）。

        重要的

        大量的替代项会影响 Traffic Server 缓存性能，因为所有替代项都具有相同的 URL。尽管 Traffic Server 可以非常快速地在索引中查找 URL，但它必须顺序扫描对象存储中的可用替代项。

        要更改候补人数的限制：

        1. 编辑proxy.config.cache.limits.http.max_alts在records.config。

           CONFIG proxy.config.cache.limits.http.max_alts INT 5
           

        2. 运行命令以应用配置更改。traffic_ctl config reload

        使用事务缓冲控制

        默认情况下，I/O 操作全速运行，与 Traffic Server、网络或缓存可以支持的速度一样快。如果客户端连接显着变慢，这对于大对象来说可能是有问题的。在这种情况下，内容将在 ram 中缓冲，同时等待发送到客户端。POST如果客户端连接速度快而原始服务器连接速度慢，这也可能发生在请求中。如果正在使用非常大的对象，这会导致 Traffic Server 的内存使用量变得 非常大。

        这个问题可以通过控制事务使用的缓冲区空间量来改善。根据事务使用的字节设置高水位和低水位标记。如果正在使用的缓冲区空间超过高水位线，则会限制连接以防止额外的外部数据到达。内部操作继续全速进行，直到正在使用的缓冲区空间降至低水位线以下，并且重新启用外部数据 I/O。

        尽管这主要是为了限制 Traffic Server 的内存使用，但它也可以通过设置缓冲区限制然后从外部或通过转换来限制客户端连接来充当粗略的速率限制器。这将导致与源服务器的连接被限制为大致客户端连接速度。

        Traffic Server 以大块（32K 左右）进行网络 I/O，因此事务缓冲控制的粒度被限制在类似的精度。

        缓冲区大小计算包括事务中的所有元素，包括与转换插件关联的任何缓冲区。

        事务缓冲控制可以通过使用配置变量或TSHttpTxnConfigIntSet()在插件中全局启用。

        价值	多变的	TSHttpTxnConfigIntSet() 钥匙
        启用缓冲	proxy.config.http.flow_control.enabled	TS_CONFIG_HTTP_FLOW_CONTROL_ENABLED
        设置高水位	proxy.config.http.flow_control.high_water	TS_CONFIG_HTTP_FLOW_CONTROL_HIGH_WATER_MARK
        设置低水位	proxy.config.http.flow_control.low_water	TS_CONFIG_HTTP_FLOW_CONTROL_LOW_WATER_MARK

        请注意始终使低水位线等于或小于高水位线。如果只设置一个，另一个将设置为相同的值。

        如果使用TSHttpTxnConfigIntSet()，则必须不迟于 TS_HTTP_READ_RESPONSE_HDR_HOOK.

        减少源服务器请求（避免雷霆万钧）

        当无法从缓存中提供对象时，请求将被代理到源服务器。对于一个流行的对象，这可能会导致对源服务器的许多几乎同时的请求，可能会压倒它或相关的资源。Traffic Server 中有几个功能可以用来避免这种情况。

        边读边写

        当 Traffic Server 从原点获取一些东西，并在收到响应时，一旦收到了对象的 background_fill_completed_threshold %，任何数量的客户端都可以被允许开始服务部分填充的缓存对象。

        虽然其他一些 HTTP 代理允许客户端在代理从源服务器接收数据后立即开始读取响应，但 ATS 直到读取和处理完整的 HTTP 响应标头后才开始允许客户端读取。这是 ATS 的副作用，它不区分缓存刷新和冷缓存，这会阻止了解响应是否可缓存。

        由于来自源服务器的不可缓存响应通常是由于该内容对于不同的客户端请求是唯一的，因此 ATS 将不会启用边读边写功能，直到它确定能够缓存对象。

        必须进行以下设置才能records.config在 ATS 中启用读写器功能：

        CONFIG proxy.config.cache.enable_read_while_writer INT 1
        CONFIG proxy.config.http.background_fill_active_timeout INT 0
        CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0.000000
        CONFIG proxy.config.cache.max_doc_size INT 0
        

        所有四种配置都是必需的，原因如下：

        • proxy.config.cache.enable_read_while_writer设置为1打开该功能，因为它0默认关闭 ( )。

        • 应允许为每个可能的请求启用背景填充功能（ proxy.config.http.background_fill_active_timeout和 和 proxy.config.http.background_fill_completed_threshold）。如果编写器（请求对象的第一个客户端会话，触发 ATS 联系源服务器）消失，则这是必要的。另一个客户端会话需要接管编写器。

          因此，您应该将后台填充超时和阈值设置为零；这确保他们永远不会超时，并且总是被允许开始。

        • 本proxy.config.cache.max_doc_size应该是无限的（设置为0），因为对象的大小可能是未知的，而超出此限制将导致被服务的对象断开。

        启用这些后，您将获得与 Squid 的折叠转发非常接近但又不完全相同的内容。

        除了上面的设置，设置proxy.config.cache.read_while_writer.max_retries 和proxy.config.cache.read_while_writer_retry.delay允许控制重试次数 TS 尝试触发 read-while-writer 直到对象的第一个片段下载完成：

        CONFIG proxy.config.cache.read_while_writer.max_retries INT 10
        
        CONFIG proxy.config.cache.read_while_writer_retry.delay INT 50
        

        打开读取重试超时

        开放读取重试配置尝试减少对给定对象的源的并发请求数。在从源服务器获取对象时，后续请求将等待 proxy.config.http.cache.open_read_retry_time几毫秒，然后检查是否可以从缓存中提供对象。如果仍在获取对象，则后续请求将重试 proxy.config.http.cache.max_open_read_retries次数。因此，后续请求可能在建立自己的源连接之前总共等待 ( max_open_read_retriesx open_read_retry_time) 毫秒。例如，如果它们分别设置为5和10，则连接将等待最多 50 毫秒从前一个请求返回的响应，直到该请求被允许通过。

        重要的

        当对象不可缓存时，这些设置是不合适的。在这些情况下，对对象的请求有效地被序列化。随后的请求将open_read_retry_time在被代理到源之前至少等待几毫秒。

        建议将此设置与Read While Writer结合 用于大（传输时间超过 ( max_open_read_retriesx open_read_retry_time) 毫秒的）可缓存对象。如果不启用 read-while-writer 设置，在初始提取正在进行时，不仅后续请求会延迟最长时间，而且这些请求会导致对源服务器的不必要请求。

        由于 ATS 现在支持按请求或重新映射规则设置这些设置，因此您可以更轻松地将其配置为适合您的设置。

        配置是（默认）：

        CONFIG proxy.config.http.cache.max_open_read_retries INT -1
        CONFIG proxy.config.http.cache.open_read_retry_time INT 10
        

        默认设置是禁用该功能，并且每个连接都可以在没有人为延迟的情况下到达原点。启用后，您将尝试 max_open_read_retries多次，每次都有open_read_retry_time超时。

        打开写入失败操作

        除了开放读取重试设置之外，TS 还支持一个新设置proxy.config.http.cache.open_write_fail_action，该设置 允许通过返回陈旧副本（在命中陈旧的情况下或在缓存未命中的情况下出错）来进一步减少多个并发请求访问同一对象的源除了其中一项请求之外的所有请求。