这是我参与「第五届青训营 」伴学笔记创作活动的第5天
前言
HTTP缓存机制是web性能优化的重要手段。从缓存中读取数据和直接向服务器中请求数据相比,节省了巨大的成本。对于有志于从事Web开发的人们来说,这些是必备的知识技能。
HTTP缓存机制
HTTP缓存是什么
HTTP缓存就是保存资源副本并在下次请求时直接使用该副本的技术。二次请求时Web缓存发现请求的资源已经被存储,它会拦截请求,返回该资源的拷贝,而不会去源服务器重新下载。
为什么会有缓存
打开网页后,网页中的代码和资源都需要从服务器下载,如果服务器和用户的浏览器离得比较远,那下载过程会比较耗时,网页打开就会很慢。下次再访问这个网页时又得重新再下载一次,很浪费时间和资源。因此,HTTP设计了缓存的功能。把下载的资源保存下来,下次打开网页的时候可直接读取。
缓存类型
缓存分为两种:强缓存和协商缓存
1.强缓存: 不会向服务器发送请求,直接从缓存中读取资源。
相关Header:
- Expires: Response Header里的过期时间。浏览器再次加载资源时,如果在这个过期时间内,则命中强缓存。 举例:
Expires: Sat,21 Feb 2023 23:59:59 GMT - Cache-control:
- 可缓存性
- no-cache: 虽然字面意义是“不要缓存”。但它实际上的机制是,仍然对资源使用缓存,但每一次在使用缓存之前必须向服务器对缓存资源进行验证
- no-store: 不使用任何缓存
- 到期
- max-age: 单位秒,存储的最长时间。(例如:当值设置为120时,则代表这个请求正确返回之后的2分钟之内再次加载资源就会命中强缓存)
- 重新验证
- must-revalidate:一旦资源过期,在成功向原始服务器验证之前,不能使用
- 可缓存性
例如:禁止进行缓存可以使用Cache-Control:no-cache, no-store, must-revalidate
我们还可以利用这些Header直接设置HTML页面,不让浏览器缓存:
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="Cache-Control" content="no-cache, must-revalidate">
<meta http-equiv="expires" content="Sat,21 Feb 2023 00:00:00 GMT"(当前时间)>
2.协商缓存: 向服务器发送请求,服务器会根据这个请求的Request Header的一些参数来判断是否命中协商缓存,如果命中,则返回304状态码并带上新的Response Header通知浏览器从缓存中读取资源。
相关Header:
- Etag/lf-None-Match: Etag是上一次加载资源时,服务器返回的Response Header,是该资源的唯一标识。浏览器在下一次加载资源向服务器发送请求时,会将上一次返回的Etag值放到Request header里的If-None-Match当中
- Last-Modified/lf-Modified-Since: 最后修改时间
浏览器缓存过程
(图片来源:字节内部课学习资料)
Cookie
Cookie是什么
Cookie是服务器发送到用户浏览器并保存在本地的一小块数据,会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。作用如图所示:
(图片来源于网络)
Cookie的存储
Cookie保存在客户端某个特定的目录下的一个扩展名为“.txt”文本文件中,井且不同站点的 Cookie数据保存不同的文件中。
Set-Cookie-Response
服务器使用Set-Cookie响应头部向浏览器发送cookie信息。
一个Cookie一般像这样Set-Cookie: <cookie名>=<cookie值>
Name=value —— 各种cookie的名称和值,用于创建Cookie Expires=Date —— Cookie 的有效期,缺省时Cookie仅在浏览器关闭之前有效
Path=Path —— 限制指定Cookie 的发送范围的文件目录,默认为当前
Domain=domain —— 限制cookie生效的域名,默认为创建cookie的服务域名
secure 仅在HTTPS —— 安全连接时,才可以发送Cookie
HttpOnly JavaScript —— 脚本无法获得Cookie
SameSite=[None|Strict|Lax] —— None 同站、跨站请求都可发送;Strict 仅在同站发送;允许与顶级导航一起发送,并将与第三方网站发起的GET请求一起发送