Expires,Cache-Control,Last-Modified,ETag

本文详细介绍了HTTP缓存机制,包括Expires、Cache-Control、Last-Modified和ETag等关键概念的作用及应用场景,帮助读者理解如何利用这些机制提高网站性能。

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

Expires、Cache-Control、Last-Modified、ETag都是在http response的返回header中
用来控制浏览器客户端缓存行为的。
1.Expires在HTTP/1.0中已经定义,Cache-Control:max-age=xxx在HTTP/1.1中才有定义,
为了向下兼容,仅使用max-age不够。
当某一个web资源被访问后,会被浏览器缓存,在以后对相同资源再次访问的时候浏览器会
检查缓存是否过期。
Expires指定的值为日期,在指定的日期到达之前再次访问则认为缓存有效。
max-age指定的值为多少秒,距第一次访问多少秒后再次访问则认为缓存有效。
这时候是不会发生网络请求的。
场景:1,用户在浏览器里输入一个曾经访问过的网址,2,点击URL link(href)链接到一个曾经访问
过的资源。3,网页中静态的JS,CSS,图片资源。

Last-Modified的值为一个日期,是资源最近一次修改的时间。
ETag的值为服务器对请求的资源的内容按照hash算法计算的一个值,当内容
发生改变的时候,这个值会相应的改变。

Expires和Cache-Control控制浏览器是否做缓存,如果缓存,缓存的有效期为多久。Expires值为-1和0不缓存。Cache-Control的值为no-cache不缓存.
Last-Modified和ETag是在缓存过期后到服务器做验证的时候的比较值。Last-Modified只能精确到秒级别,如果要到毫秒级别,就要用ETag.

当缓存过期后,浏览器会向服务器发送请求。
这时候request header会带上If-Modified-Since和If-None-Match参数。
If-Modified-Since的值为缓存中最初收到的Last-Modified的值。
If-None-Match的值为缓存中最初收到的ETag的值。
如果最初的返回中没有Last-Modified和ETag的值则不会带上这个请求参数。
服务器收到后会“验证”,如果相同则返回一个“304 Not Modified”响应,
不会将内容再传一次,节省了带宽。
场景:1,访问的时间在Expires日期之后或者max-age指定的时间之后,2,用户按F5刷新.

还有一种情况是用户按 CTRL+F5,这时候浏览器会在请求头中带上
Pragma参数,值为no-cache,同时在request header中去掉If-Modified-Since和If-None-Match。
服务器收到请求后会将内容重新传给浏览器,不管内容是否变化,就像是浏览器第一次请求一样。
响应码是200 ok。

下面是在JAVA代码中设置这些参数的方法:
//不允许浏览器端或缓存服务器缓存当前页面信息。    
response.setDateHeader("Expires", 0);  
response.addHeader( "Cache-Control", "no-cache" );
//本页面允许在浏览器端或缓存服务器中缓存,时限为10秒。
java.util.Date date = new java.util.Date();  
response.setDateHeader("Expires",date.getTime()+10000);
response.addHeader( "Cache-Control", "max-age=10" );
//设置修改时间
response.setDateHeader("Last-Modified",date.getTime());

在nginx中实验,nginx可以通过expires 或者add_header配置来为
response header添加 Expires和Cache-Control参数。
默认不指定的时候,response header如下,没有Expires和Cache-Control参数。
这时候默认有Last-Modified和Etag值,多次访问不会发生网络请求。
Connection    keep-alive
Date    Wed, 27 Nov 2013 05:17:24 GMT
Etag    "52957fcb-37"
Last-Modified    Wed, 27 Nov 2013 05:14:51 GMT
Server    nginx/1.5.7
nginx指定expires -1d,意思是过期时间为一天前。
这时候每次再次访问相同资源都会到服务器"验证",然后得到一个304返回.
Cache-Control    no-cache
Connection    keep-alive
Date    Wed, 27 Nov 2013 06:52:20 GMT
Etag    "5295898b-b6"
Expires    Tue, 26 Nov 2013 06:52:20 GMT
Last-Modified    Wed, 27 Nov 2013 05:56:27 GMT
Server    nginx/1.5.7
nginx指定expires 1d,意思是过期时间为一天后。
这时候每次再次访问相同资源,浏览器不会像服务器发请求。
这时候如果资源内容有改变,浏览器也不会知道。

当然如果你F5或者CTRL+F5可以看到最新的内容。

Cache-Control还可以设置的其它值:


<think>嗯,用户之前问过关于HTTP请求报文中的CRLF的问题,现在又问到Cache-Control是否是请求头的内容码。需要先确认用户的背景。可能他们刚开始学习HTTP协议,或者在做Web开发相关的工作。用户的问题提到Cache-Control是请求头的内容码,这里的“内容码”可能是指头字段的某个值或编码,但需要确认是否正确。 首先,Cache-Control确实是一个HTTP头字段,但既可以用在请求头,也可以用在响应头中。用户可能混淆了请求头和响应头的使用场景,或者想了解它的具体作用。需要解释清楚Cache-Control的作用,以及它在请求和响应中的不同用途。 接下来,用户可能想知道Cache-Control的常见指令,比如max-age、no-cache、no-store等。需要分别说明这些指令在请求和响应中的意义。例如,当客户端在请求头中使用Cache-Control: no-cache时,是要求服务器返回新鲜的资源,而服务器在响应头中使用同样的指令,则是允许缓存但需要验证。 还需要考虑用户可能的误区,比如是否认为Cache-Control只在请求中使用,或者不清楚各个指令的具体效果。可能需要举例说明不同指令的影响,以及如何通过设置这些指令来控制缓存行为,提升性能或确保数据的最新性。 此外,用户可能在实际开发中遇到了缓存问题,例如页面没有及时更新,或者希望优化资源加载速度。这时候,正确配置Cache-Control就显得尤为重要。需要强调安全性和性能之间的平衡,比如使用no-store来避免敏感信息缓存,或者通过max-age设置合理的缓存时间。 最后,要确保回答的结构清晰,分点解释,避免技术术语过于复杂,让用户能够轻松理解。同时,提醒用户在实际应用中,结合其他缓存头如ExpiresETag来综合管理缓存策略,可能是一个好的实践建议。</think>**Cache-Control** 是 HTTP 协议中用于**控制缓存行为**的关键头字段,它既可以出现在**请求头**(客户端告诉服务器/代理如何处理缓存),也可以出现在**响应头**(服务器告诉客户端/代理如何缓存资源)。以下是详细解析: --- ### **1. Cache-Control 的作用** 通过设置不同的指令(Directives),`Cache-Control` 可以精确控制: - **资源是否可以被缓存** - **缓存的存储位置**(浏览器、代理服务器等) - **缓存的有效时间** - **缓存是否需要重新验证** --- ### **2. 常见指令及用途** 以下是 `Cache-Control` 的常用指令,分为**请求头**和**响应头**两类: #### **(1)请求头中的 Cache-Control**(客户端 → 服务器) | 指令 | 说明 | |------------------|---------------------------------------------------------------------| | `max-age=<秒>` | 客户端要求返回缓存时间不超过指定秒数的资源(优先于服务器设置的时间)。 | | `no-cache` | 客户端要求**不直接使用本地缓存**,必须向服务器验证缓存是否有效。 | | `no-store` | 客户端要求**完全不缓存**(不存储到本地或代理服务器),每次必须重新请求。| | `max-stale=<秒>` | 客户端可以接受过期但不超过指定秒数的缓存(通常用于离线场景)。 | **示例请求头**: ```http GET /data HTTP/1.1 Host: example.com Cache-Control: no-cache, max-stale=3600 ``` --- #### **(2)响应头中的 Cache-Control**(服务器 → 客户端) | 指令 | 说明 | |-----------------------|---------------------------------------------------------------------| | `public` | 允许任何中间缓存(如代理服务器)缓存此响应。 | | `private` | 仅允许用户浏览器缓存此响应,禁止代理服务器缓存(适用于用户私有数据)。 | | `max-age=<秒>` | 资源在缓存中的最大有效时间(从请求时间开始计算)。 | | `no-store` | 禁止任何缓存存储此响应(适用于敏感数据)。 | | `no-cache` | 缓存可以存储资源,但使用前必须向服务器验证有效性。 | | `must-revalidate` | 缓存过期后必须向服务器验证,不可直接使用过期缓存。 | | `s-maxage=<秒>` | 专为代理服务器设置的缓存时间(优先级高于 `max-age`)。 | **示例响应头**: ```http HTTP/1.1 200 OK Cache-Control: public, max-age=3600, must-revalidate Content-Type: text/html ``` --- ### **3. 典型场景示例** #### **场景 1:静态资源长期缓存** ```http HTTP/1.1 200 OK Cache-Control: public, max-age=31536000 # 缓存 1 年(适用于 JS/CSS 文件) ``` #### **场景 2:敏感数据禁止缓存** ```http HTTP/1.1 200 OK Cache-Control: private, no-store # 仅浏览器缓存且不存储(适用于用户隐私数据) ``` #### **场景 3:动态资源实时验证** ```http HTTP/1.1 200 OK Cache-Control: no-cache # 可缓存,但每次使用前必须向服务器验证 ``` --- ### **4. 与其他缓存头的关系** - **`Expires`**:旧版缓存控制方式(指定绝对过期时间),**优先级低于 `Cache-Control` 的 `max-age`**。 - **`ETag`/`Last-Modified`**:配合 `Cache-Control` 实现缓存验证(如 `no-cache` 时需验证资源是否修改)。 --- ### **5. 注意事项** - **优先级**:同一头字段中多个指令共存时,需遵循协议优先级(如 `no-store` 会覆盖其他缓存指令)。 - **兼容性**:某些旧代理服务器可能不支持所有指令,需测试目标环境。 - **安全风险**:错误设置 `Cache-Control`(如对敏感数据设为 `public`)可能导致数据泄露。 --- ### **总结** - **Cache-Control** 是 HTTP 缓存机制的核心控制字段,通过灵活组合指令实现性能优化与数据安全。 - 在请求头中,客户端可主动控制缓存行为;在响应头中,服务器定义资源的缓存策略。 - 实际开发中建议结合 `max-age`、`no-cache`、`must-revalidate` 等指令,平衡缓存效率与数据实时性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值