强缓存与协商缓存的实现机制

---

前言

强缓存与协商缓存的实现机制
1. 强缓存（逼迫缓存）

特点：欣赏器直接从当地缓存读取资源，不发送哀求到服务器。
实现方式：通过 Cache-Control 和 Expires 相应头控制。
(1) Cache-Control（HTTP/1.1 尺度，优先级更高）
• 常见指令：
• max-age=<seconds>：缓存有用期（如 max-age=3600 表现 1 小时内有用）。
• no-cache：不使用强缓存，直接进入协商缓存（向服务器验证）。
• no-store：完全禁用缓存，每次哀求都重新获取资源。
• public：答应署理服务器缓存（默认 private 仅欣赏器缓存）。
• immutable：资源永稳定，欣赏器直接使用缓存（实用于版本化文件名如 main.a1b2c3.js）。
• 示例：

1. Cache-Control: public, max-age=3600

复制代码

(2) Expires（HTTP/1.0 遗留，优先级低于 Cache-Control）
• 指定一个绝对过期时间（GMT 格式），若当地时间凌驾该时间则缓存失效。
• 示例：

1. Expires: Wed, 21 Oct 2025 07:28:00 GMT

复制代码

强缓存收效流程：

• 欣赏器哀求资源时，查抄 Cache-Control/Expires。
  
• 若未过期，直接从 内存缓存（Memory Cache） 或 磁盘缓存（Disk Cache） 加载，HTTP 状态码体现 200 (from cache)。
  
• 若已过期，进入协商缓存流程。
  

---

2. 协商缓存（对比缓存）

特点：欣赏器向服务器验证缓存是否有用，大概返回 304（Not Modified） 继续使用缓存。
实现方式：通过 Last-Modified/If-Modified-Since 和 ETag/If-None-Match 两组头部控制。
(1) Last-Modified + If-Modified-Since
• 服务器返回 Last-Modified：资源的末了修改时间（GMT 格式）。
• 欣赏器下次哀求：携带 If-Modified-Since（值为前次的 Last-Modified）。
• 服务器查抄：
• 若资源未修改（时间未变），返回 304 Not Modified，欣赏器使用缓存。
• 若已修改，返回 200 OK 和新资源。
• 示例：

1. # 首次请求（服务器响应）
2. Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT
4. # 再次请求（浏览器携带）
5. If-Modified-Since: Wed, 21 Oct 2025 07:28:00 GMT

复制代码

(2) ETag + If-None-Match（更精准）
• 服务器返回 ETag：资源的唯一标识符（如哈希值）。
• 欣赏器下次哀求：携带 If-None-Match（值为前次的 ETag）。
• 服务器查抄：
• 若 ETag 匹配，返回 304 Not Modified。
• 若不匹配，返回 200 OK 和新资源。
• 示例：

1. # 首次请求（服务器响应）
2. ETag: "33a64df551425fcc55e4d42a148795d9"
4. # 再次请求（浏览器携带）
5. If-None-Match: "33a64df551425fcc55e4d42a148795d9"

复制代码

协商缓存收效流程：

• 欣赏器发现强缓存失效（或 no-cache），携带 If-Modified-Since 或 If-None-Match 向服务器发起哀求。
  
• 服务器验证资源是否变革：
  • 未变革 → 返回 304，欣赏器使用缓存。
  • 已变革 → 返回 200 和新资源。
  

---

对比总结

缓存范例实现方式优先级特点强缓存Cache-Control/Expires高直接读缓存，不哀求服务器。协商缓存Last-Modified/ETag低需向服务器验证，大概返回 304。现实应用发起

• 静态资源（如 JS/CSS/图片）：
  • 使用强缓存 + 文件名哈希（如 main.a1b2c3.js），设置 Cache-Control: max-age=31536000, immutable。
  
• 动态资源（如 API 数据）：
  • 使用 Cache-Control: no-cache + ETag，确保及时性。
  
• 制止缓存题目：
  • 修改资源时更新文件名或 URL 参数（如 ?v=2）。
  

通过公道配置，可明显减少网络哀求，提升页面加载速率！ 🚀

---

1. 缓存配置的三种重要实现方式

(1) 后端代码控制（如Node.js/Java/Python）
实用场景：动态API、须要业务逻辑判定是否缓存。
示例（Node.js Express）：

1. app.get('/data', (req, res) => {
2.   // 强缓存：1小时有效
3.   res.set('Cache-Control', 'public, max-age=3600');
4.   
5.   // 协商缓存：ETag
6.   const data = { id: 1, name: 'Example' };
7.   const etag = require('crypto').createHash('md5').update(JSON.stringify(data)).digest('hex');
8.   res.set('ETag', etag);
9.   
10.   // 检查客户端If-None-Match
11.   if (req.headers['if-none-match'] === etag) {
12.     return res.status(304).end(); // 返回304，使用缓存
13.   }
14.   
15.   res.json(data);
16. });

复制代码

(2) Web服务器配置（如Nginx/Apache）
实用场景：静态资源（HTML/CSS/JS/图片）的缓存。
Nginx示例：

1. server {
2.     location /static/ {
3.         # 强缓存：1年（适用于版本化文件名如main.a1b2c3.js）
4.         add_header Cache-Control "public, max-age=31536000, immutable";
5.         
6.         # 协商缓存：Last-Modified/ETag（默认启用，无需额外配置）
7.     }
9.     location /api/ {
10.         # 动态接口禁用强缓存，只用协商缓存
11.         add_header Cache-Control "no-cache";
12.         # Nginx会自动处理ETag/Last-Modified（需确保后端未覆盖）
13.     }
14. }

复制代码

(3) CDN控制（如Cloudflare/AWS CloudFront）
实用场景：环球加速的静态资源缓存。
Cloudflare规则示例：
• 缓存规则：匹配URL路径（如/images/*），设置缓存有用期（如1小时）。
• 边缘缓存TTL：覆盖源站的Cache-Control头。

---

2. 缓存策略选择与优先级
(1) 缓存配置的优先级

• CDN设置 > Nginx配置 > 后端代码
  • 假如CDN设置了缓存规则，它会覆盖Nginx或后端的Cache-Control头。
  • 假如Nginx配置了add_header，它会覆盖后端代码的相应头。
  

(2) 怎样决定使用哪种方式？
场景保举方式理由静态资源（JS/CSS/图片）Nginx/CDN高效、无需业务逻辑，直接通过文件名哈希（如main.a1b2c3.js）和强缓存优化。动态API数据后端代码须要根据业务逻辑判定是否缓存（如用户隐私数据不可缓存）。全局缓存策略CDN统一管理全部边缘节点的缓存活动，适当多地区摆设。(3) 逼迫禁用缓存的场景
• 须要及时数据的API（如股票代价）：

1. Cache-Control: no-store

复制代码

• 用户敏感信息（如个人资料）：

1. Cache-Control: private, no-cache

复制代码

---

3. 实战发起
(1) 静态资源优化

1. location /assets/ {
2.     # 文件名带哈希（如main.a1b2c3.js），强缓存1年
3.     add_header Cache-Control "public, max-age=31536000, immutable";
4. }

复制代码

• 使用Webpack/Vite等工具生成哈希文件名，确保内容变革后URL改变。
(2) 动态API优化

1. // 后端代码（Express/Koa）
2. res.set({
3.     'Cache-Control': 'no-cache', // 禁用强缓存，但允许协商缓存
4.     'ETag': generateETag(data)   // 基于内容生成ETag
5. });

复制代码

(3) 调试缓存活动
• Chrome DevTools → Network → 查察哀求头（Cache-Control/ETag）和相应状态（200/304）。
• cURL下令测试：

1. curl -I http://example.com/resource
2. # 检查响应头中的Cache-Control/ETag

复制代码

---

总结
• 谁控制缓存？
• 静态资源 → Nginx/CDN
• 动态API → 后端代码
• 全局策略 → CDN
• 怎样选择？
• 强缓存：Cache-Control: max-age=3600（Nginx/CDN优先）。
• 协商缓存：ETag/Last-Modified（后端或Nginx自动处理处罚）。
• 调试工具：Chrome DevTools、cURL、Web服务器日记。
公道配置缓存可明显提升性能，减少服务器压力！ 🚀

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。