导航
Object.keys(localStorage).forEach(key => {
console.log(localStorage.getItem(key));
});
都是用的系统时间,但
缓存分为两种: 强缓存和协商缓存,根据响应的 header 内容来决定。
缓存类型 | 获取资源形式 | 状态码 | 发送请求到服务器 |
---|---|---|---|
强缓存 | 从缓存取 | 200(from cache) | 否,直接从缓存取 |
协商缓存 | 从缓存取 | 304(not modified) | 是,通过服务器来告知缓存是否可用 |
强缓存相关字段有 expires,cache-control。如果 cache-control 与 expires 同时存 在的话,cache-control 的优先级高于 expires。协商缓存相关字段有 Last-Modified/If-Modified-Since,Etag/If-None-Match
可以分成Service Worker、Memory Cache、Disk Cache 和 Push Cache,那请求的时候 from memory cache 和 from disk cache 的依据是什么,哪些数据什么时候存放在 Memory Cache 和 Disk Cache 中?
Cache-Control
如果有某些 API 或动态资源是通过 Node.js 提供的,可以在响应中设置 Cache-Control
头。
const express = require('express');
const app = express();
// 设置静态文件缓存
app.use('/static', express.static('public', {
maxAge: '30d', // 缓存时间为30天
}));
// 设置 API 缓存
app.get('/api/data', (req, res) => {
res.set('Cache-Control', 'public, max-age=3600'); // 缓存1小时
res.json({ data: 'Your data here' });
});
app.listen(3000, () => {
console.log('Server is running on port 3000');
});
Cache-Control
如果前端资源(例如 dist
目录)是通过 Nginx 提供的,可以在 Nginx 配置文件中设置缓存策略。下面是一个简单的 Nginx 配置示例:
server {
listen 80;
server_name yourdomain.com;
location / {
root /path/to/your/vue/dist;
try_files $uri $uri/ /index.html;
}
# 针对静态资源设置缓存
location ~* \\.(js|css|png|jpg|jpeg|gif|svg|ico|woff|woff2|ttf)$ {
root /path/to/your/vue/dist;
expires 30d; # 缓存时间为30天
add_header Cache-Control "public, max-age=2592000"; # 设置Cache-Control头
try_files $uri $uri/ /index.html;
}
}
对于前端资源(如 JavaScript、CSS、图像等),你可以通过 Nginx 的 expires
指令设置缓存时间。常见的做法是为静态资源设置长时间缓存,例如 30 天或更长。
no-cache
来确保每次请求都从服务器获取最新版本。app.12345.js
)来实现持久缓存,这样在资源更新时只需修改引用路径即可。Vue CLI 默认在生产构建时会对资源进行哈希处理以实现版本化。例如:
// vue.config.js
module.exports = {
configureWebpack: {
output: {
filename: '[name].[contenthash].js',
chunkFilename: '[name].[contenthash].js',
},
},
};
通过这种方式,即使设置了长时间的缓存策略,当文件内容变化时,文件名会变更,浏览器会请求新的资源。
Cache-Control
设置。jwt 举例:
以最常见的 token 格式 jwt 为例
token 分为三段,分别是 header、payload、signature
其中,header 标识签名算法和令牌类型;payload 标识主体信息,包含令牌过期时间、发布时间、发行者、主体内容等;signature 是使用特定的算法对前面两部分进行加密,得到的加密结果。
token 有防篡改的特点,如果攻击者改动了前面两个部分,就会导致和第三部分对应不上,使得 token 失效。而攻击者不知道加密秘钥,因此又无法修改第三部分的值。
所以,在秘钥不被泄露的前提下,一个验证通过的 token 是值得被信任的。
根据同源策略,cookie 是区分端口的,但是浏览器实现来说,“cookie 区分域,而不区分端口,也就是说,同一个 ip 下的多个端口下的 cookie 是共享的!
et-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly 不同协议 http 和 https,也可以共享 但是带有 Secure 属性的不能被 http 共享 带有 HttpOnly 属性的 cookie 无法被 document.cookie 访问
cookie 和 localStorage 都受同源策略的限制
但在同一浏览器的相同域名、不同端口号下: