浏览器缓存机制与分类(二)

简介: 浏览器缓存机制与分类

🍰按失效策略分类


强缓存

当客户端请求时,先访问缓存数据库看缓存是否存在,存在直接返回,不存在,请求真实服务器,响应后加入到缓存数据库。

强缓存,直接减少了请求数,是提升最大的缓存策略。。 它的优化覆盖率请求数据的三个步骤。如果考虑缓存来优化页面性能,则强缓存应该被首选。

实现方式有两种:ExpiresCache-contrl


Expires

这个是HTTP1.0字段,表示缓存到期时间,是绝对时间(当前时间+缓存时间),在响应消息头设置后,在未过期之前步需要再次请求。但是弊端很大:


Expires: Thu, 10 Nov 2017 08:45:11 GMT
  • 修改本地时间、时差等都会造成客户端与服务端时间不一致
  • 写法复杂


Cache-contrl

表示缓存的最大有效时间,该时间为相对时间。

Cache-control: max-age=2592000
  • max-age:即最大有效时间
  • must-revalidate:如果超过了 max-age 的时间,浏览器必须向服务器发送请求,验证资源是否还有效。
  • no-cache:虽然字面意思是“不要缓存”,但实际上还是要求客户端缓存内容的,只是是否使用这个内容由后续的对比来决定。
  • no-store: 真正意义上的“不要缓存”。所有内容都不走缓存,包括强制和对比。
  • public:所有的内容都可以被缓存 (包括客户端和代理服务器, 如 CDN)
  • private:所有的内容只有客户端才可以缓存,代理服务器不能缓存。默认值。

max-age到期应该重新验证,no-cache是必须验证,(max-agemust-revalidate等价于no-cache),Cache-control优先级高于Expires。


对比缓存


对比缓存也叫做协商缓存,当强制缓存失效(超过规定时间),就会使用对比缓存,由服务器决定缓存内荣是否失效。

浏览器先请求缓存数据库,返回一个缓存标识。之后浏览器拿这个标识和服务器通讯。如果缓存未失效,则返回 HTTP 状态码 304 表示继续使用,于是客户端继续使用缓存;如果失效,则返回新的数据和缓存规则,浏览器响应数据后,再把规则写入到缓存数据库

对比缓存在请求数和没有缓存是一致的,但是返回304,返回的仅仅是状态码,没有实际的文件内容,因此  节省了响应体体积,缩短网络传输时间。。 和强制缓存来说提升幅度较小。对比缓存有两种方式:


Last-Modified & If-Modified-Since


1.服务器用Last-Modified字段告知客户端资源最后一次被修改的时间

Last-Modified: Mon, 10 Nov 2018 09:10:11 GMT

  2.浏览器储存这个值和内容

  3.下一次请求相同资源时时,浏览器从自己的缓存中找出“不确定是否过期的”缓存。因此在请求头中将上次的 Last-Modified 的值写入到请求头的 If-Modified-Since 字段。

   4.服务器会将 If-Modified-Since 的值与 Last-Modified 字段进行对比。如果相等,则表示未修改,响应 304;反之,则表示修改了,响应 200 状态码,并返回数据。


缺陷:


  • 资源更新速度以秒以下单位则会失效,因为它的时间单位最低为秒
  • 文件是服务器动态生成的,那么方法的更新时间永远都是生成时间,尽管文件未变化


Etag & If-None-Match


Etag & If-None-Match解决了上述问题。Etag 存储的是文件的特殊标识(一般都是 hash 生成的),服务器存储着文件的 Etag 字段。之后的流程和 Last-Modified 一致,只是 Last-Modified 字段和它所表示的更新时间改变成了 Etag 字段和它所表示的文件 hash,把 If-Modified-Since 变成了 If-None-Match。服务器同样进行比较,命中返回 304, 不命中返回新资源和 200。


  • Etag 的优先级高于 Last-Modified


🍔总结


  • 调用 Service Worker 的 fetch 事件响应
  • 查看 memory cache
  • 查看 disk cache。这里又细分:

        如果有强制缓存且未失效,则使用强制缓存,不请求服务器。这时的状态码全部是 200

        如果有强制缓存但已失效,使用对比缓存,比较后确定 304 还是 200

  • 发送网络请求,等待网络响应
  • 把响应内容存入 disk cache (如果 HTTP 头信息配置可以存的话)
  • 把响应内容 的引用 存入 memory cache (无视 HTTP 头信息的配置)
  • 把响应内容存入 Service Worker 的 Cache Storage (如果 Service Worker 的脚本调用了 cache.put())

本文参考:一文读懂前端缓存

目录
相关文章
|
9月前
|
缓存 并行计算 PyTorch
PyTorch CUDA内存管理优化:深度理解GPU资源分配与缓存机制
本文深入探讨了PyTorch中GPU内存管理的核心机制,特别是CUDA缓存分配器的作用与优化策略。文章分析了常见的“CUDA out of memory”问题及其成因,并通过实际案例(如Llama 1B模型训练)展示了内存分配模式。PyTorch的缓存分配器通过内存池化、延迟释放和碎片化优化等技术,显著提升了内存使用效率,减少了系统调用开销。此外,文章还介绍了高级优化方法,包括混合精度训练、梯度检查点技术及自定义内存分配器配置。这些策略有助于开发者在有限硬件资源下实现更高性能的深度学习模型训练与推理。
1712 0
|
缓存 Java 数据库连接
mybatis复习05,mybatis的缓存机制(一级缓存和二级缓存及第三方缓存)
文章介绍了MyBatis的缓存机制,包括一级缓存和二级缓存的配置和使用,以及如何整合第三方缓存EHCache。详细解释了一级缓存的生命周期、二级缓存的开启条件和配置属性,以及如何通过ehcache.xml配置文件和logback.xml日志配置文件来实现EHCache的整合。
mybatis复习05,mybatis的缓存机制(一级缓存和二级缓存及第三方缓存)
|
缓存 应用服务中间件 nginx
Web服务器的缓存机制与内容分发网络(CDN)
【8月更文第28天】随着互联网应用的发展,用户对网站响应速度的要求越来越高。为了提升用户体验,Web服务器通常会采用多种技术手段来优化页面加载速度,其中最重要的两种技术就是缓存机制和内容分发网络(CDN)。本文将深入探讨这两种技术的工作原理及其实现方法,并通过具体的代码示例加以说明。
1054 1
|
11月前
|
存储 缓存 分布式计算
【赵渝强老师】Spark RDD的缓存机制
Spark RDD通过`persist`或`cache`方法可将计算结果缓存,但并非立即生效,而是在触发action时才缓存到内存中供重用。`cache`方法实际调用了`persist(StorageLevel.MEMORY_ONLY)`。RDD缓存可能因内存不足被删除,建议结合检查点机制保证容错。示例中,读取大文件并多次调用`count`,使用缓存后执行效率显著提升,最后一次计算仅耗时98ms。
324 0
【赵渝强老师】Spark RDD的缓存机制
|
缓存 应用服务中间件 Apache
缓存代理服务器的实现机制和技术选型
缓存代理服务器是一种特殊的代理服务器,其主要功能是缓存从目标服务器(通常是Web服务器)获取的数据,并在客户端再次请求相同数据时直接提供缓存的数据。通过缓存代理服务器可以加快访问速度并减轻目标服务器的负载。
623 95
|
存储 缓存 监控
后端开发中的缓存机制:深度解析与最佳实践####
本文深入探讨了后端开发中不可或缺的一环——缓存机制,旨在为读者提供一份详尽的指南,涵盖缓存的基本原理、常见类型(如内存缓存、磁盘缓存、分布式缓存等)、主流技术选型(Redis、Memcached、Ehcache等),以及在实际项目中如何根据业务需求设计并实施高效的缓存策略。不同于常规摘要的概述性质,本摘要直接点明文章将围绕“深度解析”与“最佳实践”两大核心展开,既适合初学者构建基础认知框架,也为有经验的开发者提供优化建议与实战技巧。 ####
|
缓存 Java 数据库连接
深入探讨:Spring与MyBatis中的连接池与缓存机制
Spring 与 MyBatis 提供了强大的连接池和缓存机制,通过合理配置和使用这些机制,可以显著提升应用的性能和可扩展性。连接池通过复用数据库连接减少了连接创建和销毁的开销,而 MyBatis 的一级缓存和二级缓存则通过缓存查询结果减少了数据库访问次数。在实际应用中,结合具体的业务需求和系统架构,优化连接池和缓存的配置,是提升系统性能的重要手段。
492 4
|
缓存 Java 数据库连接
MyBatis缓存机制
MyBatis提供两级缓存机制:一级缓存(Local Cache)默认开启,作用范围为SqlSession,重复查询时直接从缓存读取;二级缓存(Second Level Cache)需手动开启,作用于Mapper级别,支持跨SqlSession共享数据,减少数据库访问,提升性能。
239 1
|
存储 消息中间件 设计模式
缓存数据一致性策略如何分类?
数据库与缓存数据一致性问题的解决方案主要分为强一致性和最终一致性。强一致性通过分布式锁或分布式事务确保每次写入后数据立即一致,适合高要求场景,但性能开销大。最终一致性允许短暂延迟,常用方案包括Cache-Aside(先更新DB再删缓存)、Read/Write-Through(读写穿透)和Write-Behind(异步写入)。延时双删策略通过两次删除缓存确保数据最终一致,适用于复杂业务场景。选择方案需根据系统复杂度和一致性要求权衡。
413 0