http 缓存

HTTP缓存是一种重要的性能优化技能，它通过存储和重用之前获取的资源来淘汰网络流量和加快页面加载速率。以下是HTTP缓存的详细解释：
1. 缓存的范例

• 浏览器缓存：存储在用户本地设备上。
  
• 代理缓存：位于客户端和服务器之间的中心服务器。
  
• CDN缓存：内容分发网络上的缓存。
  

2. 缓存控制头部

2.1 Cache-Control（HTTP/1.1）

• max-age=：指定资源被视为奇怪的最长时间。
  
• s-maxage=：类似max-age，但只用于共享缓存。
  
• no-cache：每次利用缓存前必须重新验证。
  
• no-store：完全禁止缓存。
  
• public：可以被任何缓存存储。
  
• private：只能被浏览器缓存。
  
• must-revalidate：逾期后必须向服务器验证。
  

2.2 Expires（HTTP/1.0）

指定资源逾期的确切时间。
Expires 是一个 HTTP 响应头部，用于指定一个资源的逾期时间。当浏览器或其他客户端接收到带有 Expires 头部的响应时，它会将该资源存储在缓存中，并在未来的请求中重用该资源，直到指定的逾期时间。一旦逾期，客户端会再次向服务器请求新的资源。
2.2.1 用法

Expires 头部的值是一个 HTTP 日期，表示资源的逾期时间。例如：

1. Expires: Wed, 21 Oct 2025 07:28:00 GMT

复制代码

这表示资源将在 2025 年 10 月 21 日 GMT 时间 07:28 逾期。
2.2.2 留意事项

• 假如 Expires 头部设置为过去的日期，资源会被以为已经逾期，客户端将不会利用缓存的版本，而是向服务器请求新的资源。
  
• Expires 头部仅适用于 HTTP/1.0 客户端。对于支持 HTTP/1.1 的客户端，建议利用 Cache-Control 头部，由于它提供了更多的控制选项和灵活性。
  
• 假如同时存在 Expires 和 Cache-Control: max-age 头部，后者会优先考虑，由于 Cache-Control 提供了更正确的缓存控制机制。
  

2.2.3 与 Cache-Control 的关系

Cache-Control 是 HTTP/1.1 引入的一个响应头部，提供了比 Expires 更丰富的缓存控制计谋。例如，Cache-Control 可以指定资源的最大奇怪时间（max-age），是否需要重新验证（must-revalidate），以及其他缓存相关的指令。
当处理 HTTP/1.1 缓存时，Cache-Control 通常是首选方法，由于它答应更细粒度的缓存控制，并且可以覆盖 Expires 头部的举动。
2.2.4 利用场景

只管 Cache-Control 更增强大和灵活，Expires 仍然在一些场景下有其用武之地，特殊是当需要与只支持 HTTP/1.0 的客户端或代理进行交互时。在这种环境下，Expires 提供了一种简单的方法来指示资源的逾期时间。
总的来说，Expires 头部是一种在资源响应中指定逾期时间的方法，它有助于控制客户端缓存的举动。然而，对于需要更复杂缓存计谋的应用，保举利用 Cache-Control 头部。
2.3 ETag

资源的唯一标识符，用于验证缓存是否仍然有用。
ETag（实体标签）是一个 HTTP 响应头部，用于Web缓存验证。它提供了一种资源的唯一标识符，这个标识符可以用来判定资源是否已经被修改，从而决定是否需要重新下载资源。ETag 可以帮助提高Web应用的性能，淘汰不必要的数据传输，同时确保用户可以或许获取最新的资源内容。
2.3.1 工作原理

当浏览器第一次请求一个资源时，服务器会在响应中包含一个 ETag 头部，其中包含了这个资源的一个唯一标识符。浏览器会将这个 ETag 值和资源一起缓存。

1. ETag: "686897696a7c876b7e"

复制代码

当浏览器再次请求雷同的资源时，它会在请求的头部中包含一个 If-None-Match 头部，其值为之前收到的 ETag 值。服务器会检查这个 ETag 值是否仍然匹配当前资源的标识符。

• 假如 ETag 值匹配，这意味着资源没有被修改，服务器会返回一个 304 Not Modified 响应，告诉浏览器可以安全地利用缓存的版本。
  
• 假如 ETag 值不匹配，这意味着资源已经被修改，服务器会返回 200 OK 响应和新的资源内容，同时更新 ETag 值。
  

2.3.2 天生 ETag

ETag 值通常是基于资源的内容天生的，例如通过对资源内容应用哈希函数。这确保了当资源内容发生变化时，ETag 值也会相应地变化。服务器也可以利用其他方法来天生 ETag 值，例如基于资源的末了修改时间大概版本号。
2.3.3 长处

• 淘汰带宽斲丧：通过避免不必要的资源下载，ETag 可以帮助节省带宽。
  
• 提高性能：ETag 答应浏览器更有用地利用缓存，淘汰加载时间。
  
• 保证数据划一性：ETag 确保用户总是从服务器获取最新的资源版本。
  

2.3.4 ETag 的正确性

• 基于内容的唯一标识
  
  
  
  • ETag 通常是基于资源内容天生的唯一标识符，而不光仅依靠于时间戳。
    
  • 这意味着即使资源内容发生了微小的变化，ETag 也会相应地改变。
    
  
  
• 捕捉所有变化
  
  
  
  • 与 Last-Modified 不同，ETag 可以捕捉到任何形式的变化，包罗那些不会改变文件修改时间的变化。
    
  
  
• 毫秒级精度
  
  
  
  • ETag 不受时间精度的限制，可以反映毫秒级甚至更细微的变化。
    
  
  
• 避免时钟同步问题
  
  
  
  • ETag 不依靠于服务器时钟，因此不会受到服务器时间设置或时钟同步问题的影响。
    
  
  

2.3.5 ETag 的资源斲丧

• 计算开销
  
  
  
  • 天生 ETag 通常涉及对资源内容进行哈希计算，这比简单地获取文件的末了修改时间更耗费 CPU 资源。
    
  • 对于大文件或高流量网站，这种计算可能会对服务器性能产生显著影响。
    
  
  
• 存储需求
  
  
  
  • ETag 值需要为每个资源单独存储，而 Last-Modified 可以直接利用文件系统提供的时间戳。
    
  • 在管理大量资源的系统中，存储所有资源的 ETag 可能需要额外的存储空间。
    
  
  
• 天生计谋的复杂性
  
  
  
  • 设计一个高效且正确的 ETag 天生计谋可能比利用 Last-Modified 更复杂。
    
  • 需要考虑如那边理动态内容、部分内容更新等环境。
    
  
  
• 缓存管理
  
  
  
  • 利用 ETag 可能需要更复杂的缓存管理机制，特殊是在分布式系统中确保 ETag 的划一性。
    
  
  

2.3.6 衡量考虑

• 正确性 vs. 性能：ETag 提供了更正确的版本控制，但可能以增长服务器负载为代价。
  
• 适用场景：对于频仍变化或需要正确版本控制的资源，ETag 的优势更为显着。
  
• 系统规模：在大规模系统中，ETag 的资源斲丧可能更为显著，需要仔细衡量。
  

2.3.7 留意事项

• 分布式系统：在分布式系统中，假如不同的服务器为雷同资源天生不同的 ETag 值，可能会导致缓存效率降低。在这种环境下，需要确保所有服务器以划一的方式天生 ETag 值。
  
• 性能开销：计算 ETag 值（尤其是基于内容的哈希）可能会增长服务器的处理开销。需要在缓存效益和服务器负载之间找到平衡。
  

2.3.8 结论

ETag 确实提供了更正确的资源版本控制，可以或许捕捉到 Last-Modified 可能忽略的细微变化。然而，这种正确性是以增长计算和存储开销为代价的。在选择利用 ETag 还是 Last-Modified 时，需要根据具体应用场景、性能需求和资源限制来做出决定。在许多环境下，同时利用两者可以结合各自的优势，提供更robust的缓存验证机制。总的来说，ETag 是一种强大的机制，用于控制Web资源的缓存和验证，可以在保证内容更新的同时，优化性能和淘汰不必要的数据传输。
2.4 Last-Modified

资源末了修改的时间，用于验证缓存。
Last-Modified 是一个 HTTP 响应头，用于指示资源的末了修改时间。它在 Web 缓存验证中起着重要作用，帮助客户端和服务器确定是否需要重新传输资源内容。
2.4.1 工作原理

• 服务器响应：当服务器发送资源时，会在响应头中包含 Last-Modified 字段，其值为资源的末了修改时间。
  
  1. Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT

  复制代码
• 客户端缓存：客户端（如浏览器）会将这个时间戳与资源一起缓存。
  
• 后续请求：当客户端再次请求雷同资源时，会在请求头中包含 If-Modified-Since 字段，其值为之前收到的 Last-Modified 值。
  
  1. If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT

  复制代码
• 服务器验证：服务器收到请求后，会比较 If-Modified-Since 的值与资源的实际末了修改时间。
  
• 响应：
  
  
  
  • 假如资源未被修改，服务器返回 304 Not Modified 响应，不包含资源内容。
    
  • 假如资源已被修改，服务器返回 200 OK 响应，包含新的资源内容和更新后的 Last-Modified 值。
    
  
  

2.4.2 长处

• 淘汰带宽利用：避免传输未更改的资源。
  
• 提高响应速率：对于未修改的资源，服务器可以快速响应。
  
• 简单实现：相比 ETag，Last-Modified 更容易实现和维护。
  

2.4.3 范围性

• 精度限制：Last-Modified 的时间精度通常为秒级，可能无法捕捉到毫秒级的更改。
  
• 无法反映所有变化：某些修改可能不会改变文件的末了修改时间（如重写雷同的内容）。
  
• 时钟同步问题：假如客户端和服务器的时钟不同步，可能导致缓存验证堕落。
  

2.4.4 与 ETag 的比较

• ETag 提供了更正确的资源版本控制，但计算和存储 ETag 可能需要更多资源。
  
• Last-Modified 更简单，实现资本更低，但在某些环境下可能不如 ETag 正确。
  
• 许多服务器同时利用 ETag 和 Last-Modified，以结合两者的长处。
  

2.4.5 最佳实践

• 对于频仍变化的资源，考虑利用 ETag 而不是 Last-Modified。
  
• 对于静态资源或变化不频仍的资源，Last-Modified 通常足够。
  
• 确保服务器时钟正确，以避免因时间不同步导致的问题。
  
• 考虑将 Last-Modified 与其他缓存控制头（如 Cache-Control）结合利用，以实现更精细的缓存计谋。
  

总之，Last-Modified 是一个简单而有用的 HTTP 缓存验证机制，适用于大多数 Web 应用场景。它可以或许有用淘汰不必要的数据传输，提高 Web 应用的性能和响应速率。
3. 缓存验证

• 强制验证缓存
  
  
  
  • 利用 no-cache 指令。
    
  • 每次利用缓存前都需要与服务器验证。
    
  
  
• 协商缓存
  
  
  
  • 利用 ETag 或 Last-Modified。
    
  • 客户端发送 If-None-Match 或 If-Modified-Since 头。
    
  • 假如资源未变，服务器返回 304 Not Modified。
    
  
  

4. 缓存计谋

• 频仍变化的内容
  
  
  
  • 利用短期的 max-age 或 no-cache。
    
  
  
• 静态资源（如图片、CSS、JS）
  
  
  
  • 长期缓存（长 max-age）。
    
  • 利用版本号或哈希在文件名中。
    
  
  
• API 响应
  
  
  
  • 根据数据更新频率设置适当的 max-age。
    
  • 考虑利用 ETag 进行验证。
    
  
  

5. 浏览器举动

• 刷新页面：通常会重新验证缓存。
  
• 强制刷新（Ctrl+F5）：绕过缓存，直接从服务器获取资源。
  

6. 缓存清除

• 更改资源URL（如添加版本号）。
  
• 利用适当的 Cache-Control 头。
  
• 在服务器端设置适当的缓存计谋。
  

7. 最佳实践

• 为静态资源设置长期缓存。
  
• 利用内容哈希作为文件名的一部分。
  
• 对动态内容利用 ETag 和 Last-Modified。
  
• 利用 CDN 分发静态资源。
  
• 定期审查和更新缓存计谋。
  

8. 留意事项

• 缓存可能导致用户看到过时的内容。
  
• 过度缓存可能导致难以更新内容。
  
• 不同的浏览器可能有不同的缓存举动。
  

正确利用HTTP缓存可以显著提高网站性能，淘汰服务器负载，并改善用户体验。然而，它需要仔细的规划和管理，以确保用户始终可以或许访问到最新的内容。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。