http 缓存

最新推荐文章于 2025-05-09 09:50:15 发布

秋夫人

最新推荐文章于 2025-05-09 09:50:15 发布

阅读量1.2k

点赞数 20

CC 4.0 BY-SA版权

分类专栏：计算机网络文章标签： http 缓存网络协议

本文链接：https://blog.csdn.net/wangnanwlw/article/details/142688841

计算机网络专栏收录该内容

31 篇文章

订阅专栏

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 日期，表示资源的过期时间。例如：

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 值和资源一起缓存。

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 字段，其值为资源的最后修改时间。
```
Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT
```
客户端缓存：客户端（如浏览器）会将这个时间戳与资源一起缓存。
后续请求：当客户端再次请求相同资源时，会在请求头中包含 If-Modified-Since 字段，其值为之前收到的 Last-Modified 值。
```
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。