第 5 卷

1. HTTP/2兼容HTTP/1.1：客户端可使用HTTP/1.1的请求方式（如GET/POST），服务端自动适配，

无需修改业务逻辑；

1. HTTP/2与HTTPS：虽然HTTP/2协议本身不强制要求加密，但主流浏览器仅支

持“HTTPS+HTTP/2”（主要为了安全和兼容性），因此HTTP/2通常与HTTPS搭配使用；

1. 性能提升效果：HTTP/2在高并发、多资源加载场景下性能优势明显，可将页面加载时间缩短

30%-50%，尤其适用于移动端和复杂页面。

1. 如何通过HTTP头信息控制缓存？

HTTP缓存是前端性能优化的核心手段之一，通过浏览器本地缓存静态资源（CSS/JS/图片等），减少重复HTTP请求，提升页面加载速度。HTTP头信息是控制缓存的核心载体，主要分为强缓存和协商缓

存两大类，分别通过不同的HTTP头字段实现，具体控制方式如下：

一、强缓存（优先触发，无需请求服务端）

强缓存通过HTTP响应头字段告知浏览器：“在指定时间内，直接使用本地缓存，无需向服务端发起请求”。若缓存未过期，浏览器直接从本地读取资源，返回 200 OK (from disk cache/memory

cache)；若过期，则进入协商缓存流程。核心控制头字段有2个：

1. Cache-Control（HTTP/1.1 核心，优先级更高）

最常用的强缓存控制字段，支持多种指令组合，格式： Cache-Control: 指令1, 指令2，核心指令：

• max-age=秒数：设置缓存有效期，从资源首次请求成功后开始计时（如 max-age=3600，表

示缓存1小时）；

• public：资源可被浏览器和中间代理服务器（如CDN）缓存（默认值，可省略）；

• private：资源仅能被浏览器缓存，禁止代理服务器缓存（适用于敏感资源，如用户个人页

面）；

• no-cache：不使用强缓存，直接进入协商缓存（需向服务端验证缓存有效性）；

• no-store：禁止任何缓存，每次都需向服务端发起全新请求（适用于实时性极高的资源，如动

态验证码）；

• must-revalidate：强缓存过期后，必须向服务端验证缓存有效性，不允许浏览器直接使用过

期缓存。

示例： Cache-Control: public, max-age=86400（资源可被公共缓存，有效期1天）

局限性：依赖客户端本地时间，若用户修改本地时间，可能导致缓存提前过期或永久有效，因此目前已被Cache-Control替代，仅作为兼容性兜底。

二、协商缓存（强缓存过期后触发，需请求服务端验证）

强缓存过期后，浏览器无法确定资源是否更新，需向服务端发起“缓存验证请求”（请求头携带缓存标识），服务端对比标识后告知浏览器“使用缓存”或“更新资源”。核心通过“请求头+响应头”的

标识对实现，主要有2组标识：

1. Last-Modified + If-Modified-Since（基于资源修改时间）

最常用的协商缓存组合，逻辑简单：

1. 首次请求：服务端返回资源时，通过响应头 Last-Modified: 资源修改时间（GMT）告知浏览

器资源的最后修改时间；

1. 缓存过期后请求：浏览器通过请求头 If-Modified-Since: 上次获取的Last-Modified

值，将缓存的修改时间发送给服务端；

1. 服务端验证：对比服务端资源当前修改时间与请求头携带的时间：

• 若资源未修改（时间一致）：返回 304 Not Modified，无响应体，浏览器使用本地缓存；
• 若资源已修改（时间不一致）：返回 200 OK 和最新资源，更新浏览器缓存。

局限性：无法识别资源的“细微修改”（如文件内容修改后又恢复，修改时间变化但内容一致），且时间精度为秒级，高频修改的资源可能出现缓存误差。

1. ETag + If-None-Match（基于资源内容哈希，优先级更高）

为解决Last-Modified的局限性而生，通过资源内容的哈希值（如MD5、SHA1）作为缓存标识，内容不变则哈希值不变：

1. 首次请求：服务端计算资源内容的哈希值，通过响应头 ETag: "哈希值"（如 ETag:

"abc123"）返回给浏览器；

1. 缓存过期后请求：浏览器通过请求头 If-None-Match: 上次获取的ETag值，将缓存的哈希值

发送给服务端；

1. 服务端验证：对比服务端当前资源的哈希值与请求头携带的哈希值：

• 哈希值一致（资源未修改）：返回 304 Not Modified，使用本地缓存；
• 哈希值不一致（资源已修改）：返回 200 OK 和最新资源，更新缓存的ETag和内容。

优势：精度更高，能识别内容的细微修改；不受修改时间影响，仅关注内容本身。

三、缓存控制头信息的优先级与执行流程

1. 完整执行流程
2. 浏览器请求资源时，先检查本地是否有缓存；
3. 若有缓存，先判断强缓存是否过期（通过Cache-Control: max-age或Expires）：

• 未过期：直接使用强缓存，不发起请求；
• 已过期：发起协商缓存请求，携带If-Modified-Since/If-None-Match；

1. 服务端验证协商缓存：

• 验证通过（304）：使用本地缓存，更新缓存过期时间；
• 验证失败（200）：下载最新资源，更新本地缓存（内容+强缓存/协商缓存标识）；

1. 若本地无缓存：发起全新请求，服务端返回200和资源，同时返回缓存控制头信息，浏览器缓存资

源。

✅ 补充核心要点

1. 静态资源（CSS/JS/图片）建议设置： Cache-Control: public, max-age=31536000

（1年强缓存）+ 文件名哈希（如 app.[hash].js），资源更新时通过修改哈希值使缓存失效；

1. 动态资源（如接口数据）建议设置： Cache-Control: no-cache，仅使用协商缓存，确保数

据实时性；

1. 若同时设置Cache-Control和Expires，优先遵循Cache-Control；若同时设置ETag和Last-

Modified，服务端优先验证ETag。

1. 解释HTTP/3的主要特点和改进。它与HTTP/2相比有哪些不同？

HTTP/3是HTTP协议的最新版本，核心设计目标是解决HTTP/2在高延迟、弱网络（如移动端）场景下的性能瓶颈，其最大革新是底层传输协议从TCP改为QUIC。基于QUIC协议，HTTP/3实现了更优的连

接建立速度、抗丢包能力和并发性能，具体特点、改进及与HTTP/2的差异如下：

一、HTTP/3的主要特点和核心改进

1. 底层传输协议升级：从TCP改为QUIC

这是HTTP/3最核心的改进，QUIC（Quick UDP Internet Connections）是基于UDP的“可靠传输协议”，兼具UDP的速度优势和TCP的可靠特性，解决了TCP的3大痛点：

• 解决TCP队头阻塞：TCP是“面向连接的字节流协议”，同一条连接中，一个数据包丢失会导致后

续所有数据包排队等待重传（队头阻塞）；QUIC基于“流”的设计，每个流独立传输，单个流丢