HTTP缓存

最新推荐文章于 2025-03-09 23:21:38 发布
最新推荐文章于 2025-03-09 23:21:38 发布
阅读量320 收藏
点赞数
CC 4.0 BY-SA版权
文章标签： http
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/omyrobin/article/details/117262357
本文详细解析了HTTP缓存控制的多种指令，包括Expires、Cache-Control和Pragma的区别，以及缓存校验的ETag和Last-Modified机制。重点介绍了强缓存和协商缓存的工作原理，以及如何通过Cache-Control设置缓存策略。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

Http缓存

  • 缓存控制：控制缓存的开关，用于标识请求或访问中是否开启了缓存，使用了哪种缓存方式。

  • 缓存校验：如果缓存控制开关打开，如何校验缓存，比如怎么定义缓存的有效期，怎么确保缓存是最新的。

缓存控制

1. Expires

2. Cache-Control

3. Pragma

Expires

Expires 响应头包含日期/时间， 即在此时候之后，响应过期。

Expires因为是对时间设定的，且时间是Greenwich Mean Time （GMT），而不是本地时间，所以对时间要求较高。

Response Header
Expires: Wed, 21 Oct 2020 17:28:00 GMT

Cache-control

Cache-Control 通用消息头字段，被用于在http请求和响应中，通过指定指令来实现缓存机制。缓存指令是单向的，这意味着在请求中设置的指令，不一定被包含在响应中。

指令不区分大小写，并且具有可选参数，可以用令牌或者带引号的字符串语法。多个指令以逗号分隔。

缓存请求指令

客户端可以在HTTP请求中使用的标准 Cache-Control 指令。

Request Header
Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached

缓存响应指令

服务器可以在响应中使用的标准 Cache-Control 指令。

Response Header
Cache-Control: must-revalidate
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: public
Cache-Control: private
Cache-Control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-Control: s-maxage=<seconds>

Cache-control的值可以按以下性质分类

1.可缓存性、控制开关

  • 否可以缓存，以及是私有还是共享缓存
public

表明响应可以被任何对象（包括：发送请求的客户端，代理服务器，等等）缓存，即使是通常不可缓存的内容。（例如：1.该响应没有max-age指令或Expires消息头；2. 该响应对应的请求方法是 POST 。）

private

表明响应只能被单个用户缓存，不能作为共享缓存（即代理服务器不能缓存它）。私有缓存可以缓存响应内容，比如：对应用户的本地浏览器。

no-cache

在发布缓存副本之前，强制要求缓存把请求提交给原始服务器进行验证(协商缓存验证)。

no-store

缓存不应存储有关客户端请求或服务器响应的任何内容，即不使用任何缓存。

2. 缓存到期

max-age=

设置缓存存储的最大周期，超过这个时间缓存被认为过期(单位秒)。与Expires相反，时间是相对于请求的时间。

s-maxage=

覆盖max-age或者Expires头，但是仅适用于共享缓存(比如各个代理)，私有缓存会忽略它。

max-stale[=]

表明客户端愿意接收一个已经过期的资源。可以设置一个可选的秒数，表示响应不能已经过时超过该给定的时间。

min-fresh=

表示客户端希望获取一个能在指定的秒数内保持其最新状态的响应。

3.重新验证和重新加载

must-revalidate

一旦资源过期（比如已经超过max-age），在成功向原始服务器验证之前，缓存不能用该资源响应后续请求。

proxy-revalidate

与must-revalidate作用相同，但它仅适用于共享缓存（例如代理），并被私有缓存忽略。

4.其他

no-transform

不得对资源进行转换或转变。Content-Encoding、Content-Range、Content-Type等HTTP头不能由代理修改。例如，非透明代理或者如Google’s Light Mode可能对图像格式进行转换，以便节省缓存空间或者减少缓慢链路上的流量。no-transform指令不允许这样做。

only-if-cached

表明客户端只接受已缓存的响应，并且不要向原始服务器检查是否有更新的拷贝。

Cache-Control缓存策略

HTTP/1.1定义的 Cache-Control 头用来区分对缓存机制的支持情况， 请求头和响应头都支持这个属性。通过它提供的不同的值来定义缓存策略。

1.没有缓存

缓存中不得存储任何关于客户端请求和服务端响应的内容。每次由客户端发起的请求都会下载完整的响应内容。

Request Header
Cache-Control: no-store

表示客户端不希望这个请求的响应进行任何缓存

Response Header
Cache-Control: no-store

表示服务端不希望对个资源进行任何缓存

2.缓存但重新验证

如下头部定义，此方式下，每次有请求发出时，缓存会将此请求发到服务器，服务器端会验证请求中所描述的缓存是否过期，若未过期（注：实际就是返回304），则缓存才使用本地缓存副本。

Request Header
Cache-Control: no-cache

表示客户端希望用协商缓存的方式进行缓存

Response Header
Cache-Control: no-cache

表示服务端希望用协商缓存的方式进行缓存

3.私有和公共缓存

“public” 指令表示该响应可以被任何中间人（比如中间代理、CDN等）缓存。若指定了"public"，则一些通常不被中间人缓存的页面（因为默认是private）（比如 带有HTTP验证信息（帐号密码）的页面 或 某些特定状态码的页面），将会被其缓存。

“private” 则表示该响应是专用于某单个用户的，中间人不能缓存此响应，该响应只能应用于浏览器私有缓存中。

Response Header
Cache-Control: private
or
Cache-Control: public

可以结合协商缓存

Cache-Control: public,no-cache

Cache-Control: private,no-cache

4.强缓存

过期机制中，最重要的指令是 “max-age=”，表示资源能够被缓存（保持新鲜）的最大时间。相对Expires而言，max-age是距离请求发起的时间的秒数。针对应用中那些不会改变的文件，通常可以手动设置一定的时长以保证缓存有效，例如图片、css、js等静态资源。

Request Header
Cache-Control: max-age=31536000

配合Age请求头 来表示客户端缓存资源是否到期

Cache-Control: max-age=31536000
Age: 10
Response Header
Cache-Control: max-age=31536000

可以结合私有和公共缓存

私有强缓存

Cache-Control: private,max-age=31536000

公共强缓存

Cache-Control: public,max-age=31536000

表示服务端当前资源如果做缓存后可用的时间
5.验证方式

当使用了 “must-revalidate” 指令，那就意味着缓存在考虑使用一个陈旧的资源时，必须先验证它的状态，已过期的缓存将不被使用。

Response Header
Cache-Control: must-revalidate

表示服务端希望客户端进行验证

Cache-control --VS-- Expires

Cache-control内容要远比Expires复杂的多，也是本文重点。

  1. Expires是HTTP1.0协议中用来控制缓存的http头，Cache-Control是HTTP1.1协议新版的API。现在首选 Cache-Control。如果在Cache-Control响应头设置了 “max-age” 或者 “s-max-age” 指令，那么 Expires 响应头会被忽略。

  2. HTTP1.1协议中的，因为有了Cache-control，所以可以忽略上面提到的Expires。因为Cache-Control相对于Expires更加具体，细致。
    且，就算同时设置了Cache-Control和Expires，Cache-Control的优先级也高于Expires。

Pragma

Pragma 是一个在 HTTP/1.0 中规定的通用首部，这个首部的效果依赖于不同的实现，所以在“请求-响应”链中可能会有不同的效果。它用来向后兼容只支持 HTTP/1.0 协议的缓存服务器，那时候 HTTP/1.1 协议中的 Cache-Control 还没有出来。

Cache-Control: no-cache
Pragma: no-cache

**注意：**由于 Pragma 在 HTTP 响应中的行为没有确切规范，所以不能可靠替代 HTTP/1.1 中通用首部 Cache-Control，尽管在请求中，假如 Cache-Control 不存在的话，它的行为与 Cache-Control: no-cache 一致。建议只在需要兼容 HTTP/1.0 客户端的场合下应用 Pragma 首部。

缓存的两种形式

  • 强缓存：浏览器在请求某一资源时，会先获取该资源缓存的header信息，判断是否命中强缓存（cache-control和expires信息），若命中直接从缓存中获取资源信息，包括缓存header信息；本次请求根本就不会与服务器进行通讯

  • 协商缓存：若是没有命中强缓存，浏览器会发送请求到服务器，请求会携带第一次请求返回的有关缓存的header字段信息（Last-Modified/If-Modified-Since和Etag/If-None-Match），由服务器根据请求中的相关header信息来比对结果是否协商缓存命中；若命中，则服务器返回新的响应header信息更新缓存中的对应header信息，可是并不返回资源内容，它会告知浏览器能够直接从缓存获取；不然返回最新的资源内容

缓存校验

当缓存控制采用

Cache-Control: no-cache
Cache-Control: max-age=0
Cache-Control: must-revalidate

以上等情况时表示，表示使用协商缓存的方式
响应头ETag —对应— 请求头If-None-Match

响应头Last-Modified —对应— 请求头If-Modified-Since

ETag

作为缓存的一种强校验器，ETag 响应头是一个对用户代理(User Agent, 下面简称UA)不透明的值。对于像浏览器这样的HTTP UA，不知道ETag代表什么，不能预测它的值是多少。如果资源请求的响应头里含有ETag, 客户端可以在后续的请求的头中带上 If-None-Match 头来验证缓存。

Reqsponse Header
ETag: "3e86-410-3596fbbc"

If-None-Match

If-None-Match 是一个条件式请求首部。对于 GET 和 HEAD 请求方法来说，当且仅当服务器上没有任何资源的ETag属性值与这个首部中列出的相匹配的时候，服务器端会才返回所请求的资源，响应码为200。对于其他方法来说，当且仅当最终确认没有已存在的资源的ETag属性值与这个首部中所列出的相匹配的时候，才会对请求进行相应的处理。

Request Header
If-None-Match: "3e86-410-3596fbbc"

一般ETag的值是资源的MD5值，由服务端开发人员在响应头中返回，当客户端再次发起相同的请求时，请求头中添加If-None-Match

If-None-Match: "3e86-410-3596fbbc"

服务端人员可以通过下面的伪代码来判断如何进行返回

if(request.header("If-None-Match") == "3e86-410-3596fbbc") 
{
    response.statuscode = 304;
}
else
{
    response.write(string);
}

If-None-Match：告诉服务器如果一致，返回状态码304，不一致则返回资源。

Last-Modified

Last-Modified响应头可以作为一种弱校验器。说它弱是因为它只能精确到一秒。如果响应头里含有这个信息，客户端可以在后续的请求中带上 If-Modified-Since 来验证缓存。

Reponse Header

Last-Modified 文件最后修改时间 秒级别

Last-Modified: Thu, 03 Jul 2018 00:00:00 GMT

If-Modified-Since

If-Modified-Since 是一个条件式请求首部，服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200 。如果请求的资源从那时起未经修改，那么返回一个不带有消息主体的 304 响应，而在 Last-Modified 首部中会带有上次修改时间。 不同于 If-Unmodified-Since, If-Modified-Since 只可以用在 GET 或 HEAD 请求中。

当与 If-None-Match 一同出现时，它（If-Modified-Since）会被忽略掉，除非服务器不支持 If-None-Match。

Request Header
If-Modified-Since: Thu, 03 Jul 2018 00:00:00 GMT

如果时间一致，那么返回HTTP状态码304（不返回文件内容），客户端接到之后，就直接把本地缓存文件显示到浏览器中。

如果时间不一致，就返回HTTP状态码200和新的文件内容，客户端接到之后，会丢弃旧文件，把新文件缓存起来，并显示到浏览器中。

从这个GMT指定时间开始 未修改过

请求网站的时间

Date: Tue, 11 Jul 2000 18:23:51GMT

参考文献

HTTP Headers

HTTP 缓存

http协商缓存VS强缓存

HTTP缓存讲义

omyrobin
关注
十、HTTP 缓存——HTTP 缓存与HttpClient客户端缓存
流楚丶格念的博客
08-25 858
在日常开发中，浏览器缓存是一个非常常见但又容易被忽视的优化手段。许多开发者在面对浏览器缓存相关问题时可能会感到困惑，因此本章内容专门用来解答这些常见问题，并帮助你更好地理解如何在 Java 应用中控制浏览器缓存。浏览器缓存是指在用户使用浏览器访问网站页面或 HTTP 服务时，根据服务器端返回的缓存控制响应头，将响应内容缓存到本地浏览器。这样，下次访问相同资源时，浏览器可以直接使用缓存内容，或者仅与服务器验证内容是否过期，从而减少网络传输的数据量，提升网站性能。public。
十、HTTP 缓存——Nginx HTTP 缓存
流楚丶格念的博客
08-25 853
时间为 2024年8月16日 11:00:00，Nginx 将返回 304 状态码，因为资源的最后修改时间早于客户端的请求时间。：对于不常变化的异步数据（如商品详情页的评论），可以考虑设置较长时间的缓存（如 1 个月）。：对于静态资源（如 JS、CSS、图片），可以设置较长时间的缓存（如 1 个月或 1 年），通过版本号控制缓存过期。：对于不需要强一致性的页面（如商品详情页的库存信息），可以设置较短的缓存时间。通过这种配置，你可以灵活地管理 Nginx 的缓存内容，确保缓存的有效性和更新的及时性。
http协议
12-06 401
HTTP协议 　　超文本传输协议，是一种建立在TCP上的无状态连接。整个基本流程是客户端发送一个http请求，说明客户端想要访问的资源和请求的动作，服务端收到请求后，开始处理请求，并根据请求做出相应的动作访问服务器资源。最后通过发送HTTP响应把结果返回给客户端。 　　一个请求的开始到响应的结束称为事务，当一个事务结束后，会在服务端添加一条日志条目。 　　1、http请求 　　　...
HTTP协议分析系列（八）------http协议缓存详解
wuming19900801的专栏
01-05 1304
我们观察图片的下载，往往第一次请求时200ok 第二次请求时 304 not modified 未修改状态 解释：在网络上有一些缓存服务器，浏览器自身也有缓存功能。当我们第一次访问某图片时，正常下载图片，返回值200，第二次访问时，基于一个前提--图片不会经常改动 服务器在返回200的同时，还返回该图片的签名--Etag(签名可以理解为图片的指纹). 当浏览器再次访问该图片时，去服务器校验
HTTP 协议缓存
爱前端的程序媛的博客
03-15 551
协商缓存
http协议缓存详解
laiyuan999的博客
04-19 731
在web应用中，缓存无处不在，浏览器有浏览器缓存，代理服务器有缓存，服务器有服务器缓存，php有缓存，数据库有缓存等等……本文主要讲解http协议中的缓存。 http缓存的是指:当Web请求抵达缓存时， 如果本地有“已缓存的”副本，就可以从本地存储设备而不是从原始服务器中提取这个文档。缓存的好处：缓存的好处是显而易见的，主要如下：减少冗余数据传输，节省带宽 减少服务器负担，提高服务器性能 加快...
HTTP的缓存机制是什么？
努力是为了站在万人之中，成为别人的光
06-29 7804
在Web开发中，优化网站性能是非常重要的一项任务。HTTP缓存是提升网站性能的重要策略之一，通过合理使用缓存机制可以减少服务器的负载，降低网络延迟，提升用户的访问速度和体验。本文将介绍HTTP缓存的基本原理和实现方法，并提供示例代码帮助读者更好地理解和应用HTTP缓存。HTTP缓存机制是指在HTTP协议中定义的一种数据缓存机制，它通过在客户端或代理服务器中存储响应数据，以便在后续请求中复用这些数据，从而减少对服务器的请求和响应次数。
Go-pike是HTTP缓存服务提供高效简单的HTTP缓存服务
08-13
Go-pike是一个基于Go语言开发的HTTP缓存服务，它为用户提供了一种高效且简洁的解决方案，以替代传统的HTTP缓存工具如Varnish。Varnish以其出色的性能和强大的VCL（Varnish Configuration Language）配置而闻名，但在...
前端性能优化必修课：HTTP缓存机制详解
莫循的AI编程博客
03-09 1163
设计HTTP缓存策略就像调配一道复杂的菜肴，需要平衡多种因素：性能与时效性、带宽节约与内容更新、用户体验与服务器负载。没有放之四海而皆准的配方，只有适合特定场景的最佳实践。作为架构师，我们的任务不是追求完美的缓存策略，而是在各种约束条件下找到最佳平衡点。就像一位优秀的指挥家，知道何时该让哪些乐器发声，何时该保持沉默，从而奏出最和谐的乐章。缓存设计不是一次性工作，而是需要随着应用的发展而不断调整和优化的持续过程。通过监控、分析和迭代，我们可以不断完善缓存策略，为用户提供更快、更流畅的网络体验。
浅谈浏览器http的缓存机制
dcof99817的博客
04-04 295
针对浏览器的http缓存的分析也算是老生常谈了，每隔一段时间就会冒出一篇不错的文章，其原理也是各大公司面试时几乎必考的问题。 之所以还写一篇这样的文章，是因为近期都在搞新技术，想“回归”下基础，也希望尽量总结的更详尽些。 那么你是否还需要阅读本篇文章呢？可以试着回答下面这个问题： 我们在访问百度首页的时候，会发现不管怎么刷新页面，静态资源基本都是返回 200（from cache）...
Cache-Control: only-if-cached 深度解析
weixin_46449236的博客
08-25 761
是一个 HTTP 头部指令，客户端可以在其请求中包括这个头部，用于指示服务器只有在缓存中存在相应资源的情况下才回应，否则客户端不希望获取该响应。
Http头：only-if-cached
yzpbright的博客
04-03 3127
only-if-cached表示不进行网络请求，完全只使用缓存，若缓存不命中，则返回503错误 http全部的标签：https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
npm install 报错解决记录总结
程序员大爷
08-23 402
请注意，具体的解决方法可能因个人环境和情况而异。如果问题仍然存在，建议参考相关社区或论坛中的讨论，或向相应的技术支持提问以获取更准确的解决方案。如果上述方法仍然无法解决问题，可以进一步检查报错信息，并搜索相关报错信息以获取更具体的解决方案。同时，确保您的项目配置和依赖项文件正确无误。
npm中的cache
听海边涛声
04-08 1674
npm中的cache
NPM 常用命令（二）
专注于大数据方向，区块链，前后端，数据可视化，人工智能等领域
09-04 1958
npm 不保证以前缓存的数据以后会可用，并且会自动删除损坏的内容。缓存所做的主要保证是，如果它确实返回数据，那么该数据将完全是插入的数据。命令设置时，可以将其设置为尚不存在的工作区的文件夹，以创建文件夹并将其设置为项目中的全新工作区。启用在当前项目的已配置工作区的上下文中运行命令，同时通过仅运行此配置选项定义的工作区进行过滤。运行此命令会打开当前包在npm注册中对应的页面，如果没有提供包名，它将在当前文件夹中搜索。标志指定所有工作区，将导致 npm 仅在指定的工作区上运行，而不是在根项目上运行。
关于Okhttp缓存的“万种死法”，我get到了一种，HTTP 504 Unsatisfiable Request (only-if-cached)
zk2000416的博客
07-16 3292
OkHttp的缓存问题1.使用背景2.错误代码示例3.正解4.总结 1.使用背景 最近在搞项目，我用的是Retrofit，但考虑到市面上大多用了缓存机制，于是我又封装了一个OkHttpClient，几经波折，程序能跑起来了。但我发现它从未访问过内存，一直是在进行网络请求。 2.错误代码示例 如果认为自己的缓存有问题，可以看一下这篇博客 链接: Android okhttp缓存正确的实现方式. 我先把我最初的代码贴出来，看大家能不能发现错误。 (1). (2). (3). 一开始遇到这个错误，我以为可
Android Nginx Retrofit+Okhttp.HTTP 504 Unsatisfiable Request (only-if-cached)
guozhaohui628
04-30 4791
504 Unsatisfiable Request (only-if-cached) 在使用 okhttp 过程中，有可能会报题错误。其实这个问题很复杂，涉及到很多情况，比如 缓存、Nginx 、okhttp配置。当初碰到此问题时，花费很多时间和精力，太奇怪了。后面直接采用粗暴的做法解决（后面会说）。 出现这种情况一般来说是我们前端配置了缓存，但是后台服务端却没有合理处理缓存请求头。 解法一...
HTTP 503 Service Temporarily Unavailable
yuerliang的专栏
03-14 3066
HTTP 503服务暂时不可用retrofit2.adapter.rxjava.HttpException: HTTP 503 Service Temporarily Unavailable03-14 09:36:37.977 4418-4418/com.moreunion.zhenghao W/System.err:     at retrofit2.adapter.rxjava.Operato...
http缓存
最新发布
05-01
<think>好的，用户现在想了解HTTP缓存的工作原理以及前端CDN的缓存解决方案。之前我提供了关于前端CDN缓存的详细内容，现在需要结合用户的新问题，整合HTTP缓存机制，并参考用户提供的引用内容。 首先，我需要回顾HTTP缓存的基本概念，包括强制缓存和协商缓存。用户提供的引用[1]中提到，使用Cache-Control头来控制缓存，比如no-store、no-cache等，还提到Nginx配置禁用HTML缓存的方法。这可能涉及到不同资源类型的缓存策略，比如HTML文件通常不缓存或使用协商缓存，而静态资源如图片、JS、CSS可以长期缓存。 接着，用户提到CDN缓存解决方案，之前回答中已经涉及了CDN的缓存流程、优化策略、多CDN加速等。需要将HTTP缓存与CDN缓存结合起来，解释它们如何协同工作。例如，CDN边缘节点会遵循源站的缓存头设置，如Cache-Control和Expires，同时CDN自身也有缓存策略，比如回源条件和缓存失效机制。 用户引用的内容还提到了缓存命中率的问题，引用[1]指出Private可能影响CDN缓存命中率，但量不大时可以禁用。这可能涉及到缓存头的正确配置，避免不必要的私有缓存导致CDN无法有效缓存资源。需要解释不同Cache-Control指令对CDN的影响，比如public、private、no-cache等。 另外，用户引用中的Nginx配置示例展示了如何为HTML文件设置不缓存，这需要在前端部署时注意，确保入口文件如HTML使用协商缓存或强制不缓存，而带版本号的静态资源使用长期缓存。结合之前回答中的版本控制技巧，比如Webpack生成带哈希的文件名，可以确保资源更新后URL变化，从而绕过缓存。 用户可能还想了解如何解决常见的HTTP缓存问题，比如缓存更新不及时，或者缓存策略配置错误导致的问题。例如，使用版本化文件名来避免缓存问题，或者在需要立即更新时通过CDN刷新或修改URL。引用[1]中提到的解决方案是通过修改URL触发缓存失效，这与之前回答中的建议一致。 还需要考虑CDN如何加速动态内容，引用[2]提到CDN的动态内容回源，可能需要结合边缘计算或动态压缩技术。之前的回答中提到了动态压缩的公式，可以再次强调这些优化手段。 最后，用户的问题可能涉及实际应用中的最佳实践，比如如何配置HTTP头和CDN策略，监控缓存命中率，处理安全性和性能的平衡。需要整合引用中的信息，如HTTPS强制、防盗链设置，以及监控指标如缓存命中率、TTFB等，确保回答全面且实用。 总结来说，需要将HTTP缓存机制与CDN缓存方案结合起来，详细解释两者的工作原理、配置策略、常见问题及解决方案，并参考用户提供的引用内容，确保回答准确且符合用户的实际需求。</think>### HTTP 缓存机制与前端 CDN 缓存解决方案 --- #### 一、HTTP 缓存核心原理 HTTP 缓存通过**客户端与服务器的协作**实现资源复用，主要分为两类： 1. **强制缓存** - 通过 `Cache-Control` 或 `Expires` 头直接判断缓存是否有效 - **典型配置**： ```http Cache-Control: public, max-age=86400 // 缓存1天 ``` - **触发条件**： - 时间未超过 `max-age` - 资源未发生版本变更（如文件名哈希未变化） 2. **协商缓存** - 通过校验文件指纹（`ETag`/`Last-Modified`）确认资源是否更新 - **典型流程**： ```mermaid graph LR A[客户端请求] --> B{本地缓存} B -->|过期| C[携带If-None-Match/If-Modified-Since请求头] C --> D{服务器校验} D -->|未修改| E[返回304状态码] D -->|已修改| F[返回新资源+新缓存头] ``` 3. **关键头字段对比** | **指令** | 作用场景 | 对 CDN 的影响 | |-------------------|----------------------------|----------------------------------------| | `public` | 允许所有节点缓存 | CDN 边缘节点可缓存资源 | | `private` | 仅允许浏览器缓存 | CDN 无法缓存，显著降低命中率[^1] | | `no-cache` | 需向服务器验证 | CDN 回源校验，增加延迟但保证内容新鲜度 | | `no-store` | 完全禁用缓存 | CDN 和浏览器均不缓存 | --- #### 二、CDN 缓存与 HTTP 缓存的协同 CDN 本质是**分布式 HTTP 缓存代理**，其行为依赖源站配置： 1. **缓存继承规则** - CDN 节点默认遵循源站的 `Cache-Control` 和 `Expires` 头 - **示例冲突处理**： - 若源站设置 `Cache-Control: private`，CDN 将拒绝缓存 - 若源站设置 `Cache-Control: public, max-age=3600`，CDN 缓存1小时 2. **缓存分层架构** ```mermaid graph TD A[用户] --> B[CDN边缘节点] B -->|缓存命中| C[直接返回] B -->|缓存未命中| D[CDN父节点] D -->|缓存未命中| E[源服务器] E --> D[回源并缓存] D --> B[逐层下发] ``` 3. **前端最佳实践** - **入口文件（HTML）** ```nginx # Nginx 配置示例：禁止缓存 HTML[^1] location ~* \.(html|htm)$ { add_header Cache-Control "no-cache, must-revalidate"; } ``` - **版本化静态资源（JS/CSS）** ```html <!-- Webpack 生成的带哈希文件名 --> <script src="https://cdn.com/app.3a7b2c8d.js"></script> ``` ```http Cache-Control: public, max-age=31536000 # 1年长期缓存 ``` --- #### 三、常见问题解决方案 1. **缓存更新失效** - **场景**：修改了 JS 文件但用户仍访问旧版本 - **根因**：未更新 URL 或缓存头配置错误 - **修复方案**： - 文件名添加内容哈希（如 `main.[contenthash:8].js`） - 主动刷新 CDN 缓存（需调用 CDN API） 2. **CDN 命中率低** - **排查步骤**： 1. 检查源站 `Cache-Control` 是否包含 `private` 或 `no-store`[^1] 2. 确认 CDN 配置未覆盖源站缓存头 3. 分析用户请求是否过于分散（如大量随机 URL 参数） 3. **动态 API 加速** - **CDN 边缘计算方案**： - 缓存高频查询结果（如商品详情页） - 使用 `Cache-Control: s-maxage=60` 控制 CDN 缓存时间 $$ T_{响应} = \frac{命中次数}{总请求次数} \times T_{CDN} + \frac{未命中次数}{总请求次数} \times (T_{CDN} + T_{回源}) $$ --- #### 四、进阶优化策略 1. **分级缓存策略** | **资源类型** | 浏览器缓存 | CDN 缓存 | 实现方式 | |-------------------|------------------|------------------|----------------------------------| | 入口 HTML | `no-cache` | 不缓存 | Nginx 规则匹配[^1] | | 版本化 JS/CSS | 1年 | 1年 | Webpack 哈希输出 + CDN 继承头 | | 用户个性化内容 | `private, 60s` | 不缓存 | Vary: Cookie 头 | 2. **缓存监控体系** - **核心指标**： - 浏览器缓存利用率（通过 `PerformanceResourceTiming` API 采集） - CDN 命中率（需从 CDN 服务商获取日志） - **告警阈值**： - CDN 命中率 < 85% → 触发优化任务 - HTML 文件缓存率 > 5% → 检查配置错误 --- #### 五、实践案例 **某新闻网站优化前后对比** | **问题** | 优化前现象 | 优化方案 | 结果 | |-------------------------|------------------------------|----------------------------------|------------------------------| | 首页加载慢 | JS/CSS 未缓存，重复下载 | 添加文件哈希 + 长期缓存头 | 资源加载时间减少 68% | | CDN 费用过高 | 图片请求回源率 45% | 调整 `Cache-Control: max-age=604800` | 回源率降至 12%，月节省 \$8k | | 用户看到旧页面 | HTML 被 CDN 缓存 | 强制 `no-cache` + 版本化部署 | 页面更新延迟从 2h 缩短至 10s | --- ### 相关问题 1. 如何通过 `Vary` 头实现个性化内容缓存？ 2. `s-maxage` 与 `max-age` 在 CDN 场景下的区别？ 3. 如何设计多环境（测试/生产）的 CDN 缓存策略？ 4. Service Worker 如何与 HTTP 缓存协同工作？[^1] --- : 引用自站内资料：浏览器缓存机制及 Nginx 配置方案 [^2]: 引用自站内资料：CDN 加速流程与缓存分层架构
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值