HTTP 协议与缓存机制
校招考察频度：★ 高频（核心必背·高频生死线） 一句话速记：强缓存走本地（Cache-Control/max-age），协商缓存问服务端（ETag 比对 304）；HTTP/2 多路复用解应用层队头阻塞，HTTP/3 QUIC 解传输层阻塞。
HTTP 是应用层最重要的基石协议。校招面试中，考官主要围绕三大轴心展开考察：版本演进差异（队头阻塞）、核心状态码语义区分、强缓存与协商缓存的完整判定流程。
一、HTTP 版本演进：队头阻塞的层层突围
面试核心逻辑：“从 1.0 到 3.0，到底解决了什么痛点？队头阻塞是在哪一层解决的？”
| 版本 | 关键新特性 | 遗留痛点 / 队头阻塞位置 |
|---|---|---|
| HTTP/1.0 | 确立请求/响应模型，支持各类媒体类型。 | 短连接：每个 HTTP 请求都要重新三次握手建 TCP 连接，请求完立即断开，延迟极大。 |
| HTTP/1.1 | ① Connection: keep-alive 默认长连接；② 支持管道化（Pipelining）；③ 引入 Host 头支持虚拟主机；④ 增加断点续传（Range/206 Partial Content）。 | 应用层队头阻塞（Head-of-Line Blocking）：同一个 TCP 连接上，请求虽然可以连续发送，但服务端必须严格按照请求发送的顺序依次返回响应！如果前面的请求处理卡住了（如耗时 DB 查询），后面的所有请求全部被堵死。 |
| HTTP/2 | ① 二进制分帧（Binary Framing）：把报文拆为帧和流（Stream）；② 多路复用（Multiplexing）：单个 TCP 连接上并发双向传输多个流，交错传输；③ HPACK 头部压缩；④ 服务器推送（Server Push）。 | 传输层（TCP 层）队头阻塞：应用层不再阻塞了，但所有流共用同一个 TCP 连接。只要底层网络发生丢包，TCP 协议就会暂停所有后续数据的交付，直到丢的包重传成功！单个流丢包会导致连接内所有流全部停顿。 |
| HTTP/3 | 抛弃 TCP，改用基于 UDP 的 QUIC 协议 实现可靠传输。 | 彻底终结队头阻塞：QUIC 在 UDP 之上实现了独立的流级可靠性。流 1 丢包只需重传流 1，流 2、流 3 毫无影响，互不干涉；同时实现 0-RTT 建连 与 连接迁移（切 Wi-Fi/5G 不断连）。 |
二、HTTP 缓存机制：强缓存 vs 协商缓存（高频必考！）
浏览器发起资源请求时，缓存命中遵循严密的顺序：先看强缓存，强缓存失效再走协商缓存。
HTTP 缓存完整决策判定流程图
1. 强缓存（不与服务器交互，直接用本地）
- 触发机制：浏览器检查本地缓存头，若依然有效，直接从内存或磁盘读取，网络面板显示
200 (from memory cache)或200 (from disk cache)，耗时 0ms。 - 核心响应头：
Cache-Control: max-age=3600（HTTP/1.1，绝对主力）：表示资源在客户端可缓存 3600 秒（相对时间），优先级最高。Expires（HTTP/1.0 遗留）：绝对时间戳，受限于客户端本地时间可能不准。
- 关键指令辨析（面试高频）：
no-cache：不是不缓存！而是跳过强缓存，每次使用前必须向服务器发起协商缓存验证。no-store：彻底禁止任何缓存，每次都必须从服务器下载完整资源（用于敏感金融数据）。public/private：是否允许中间代理节点（如 CDN）缓存资源。
2. 协商缓存（必须与服务器校验，未变则返 304）
当强缓存失效（过期或标了 no-cache），浏览器带着凭证向服务器询问“我手里的资源变了没有”：
| 机制 | 首次响应头（Server -> Client） | 再次请求头（Client -> Server） | 校验逻辑与优劣势 |
|---|---|---|---|
| 基于时间戳 | Last-Modified（资源最后修改时间） | If-Modified-Since | 服务器比对时间。缺点：① 精度仅到秒级，1 秒内多次修改无法识别；② 文件只是打开保存但内容没变，也会导致缓存误失效。 |
| 基于内容指纹 | ETag（实体标签，文件内容的 Hash 摘要） | If-None-Match | 服务器比对 Hash。精度最高，只要内容变了 Hash 必变。优先级高于 Last-Modified。 |
三、常用状态码高频辨析
| 状态码 | 英文短语 | 核心含义与面试高频对比 |
|---|---|---|
| 200 | OK | 成功返回响应体。 |
| 204 | No Content | 请求成功，但响应报文不含任何主体（常用在 DELETE 或 OPTIONS 预检请求）。 |
| 301 | Moved Permanently | 永久重定向。浏览器和搜索引擎会缓存新 URL，后续请求直接打到新地址（SEO 权重转移）。 |
| 302 | Found | 临时重定向。搜索引擎不会修改原链接索引，浏览器每次依然请求原 URL。 |
| 304 | Not Modified | 协商缓存命中。服务器通知客户端本地缓存依然新鲜，报文不带主体，大幅省流。 |
| 400 | Bad Request | 客户端请求参数格式错误，服务端无法解析。 |
| 401 | Unauthorized | 未认证：用户未登录或提供的 Token 无效/过期（“你是谁？”）。 |
| 403 | Forbidden | 已认证但无权限：知道你是谁，但你无权访问该资源（“你没有权限”）。 |
| 404 | Not Found | 目标资源路径不存在。 |
| 429 | Too Many Requests | 请求触发限流（超出 Rate Limit）。 |
| 500 | Internal Server Error | 业务代码抛出未捕获异常崩溃。 |
| 502 | Bad Gateway | 网关错误：作为代理的 Nginx 收到了上游后端服务进程抛出的无效响应（如后端进程挂掉直接断连）。 |
| 504 | Gateway Timeout | 网关超时：Nginx 等待上游后端服务响应超时（后端 SQL 慢查询或死锁卡住未在规定时间内返回）。 |
四、面试追问
- GET 和 POST 请求有什么区别？
- 语义与幂等：GET 用于获取资源，安全且幂等（多次执行结果相同且不修改资源状态）；POST 用于提交数据，不安全且非幂等。
- 参数位置与长度：GET 参数拼在 URL query 字符串中（受浏览器 URL 长度限制，通常 2KB~8KB）；POST 参数在 Request Body 中，理论上无限制。
- 缓存支持：GET 天然支持浏览器强缓存/协商缓存；POST 默认不可缓存。
- 什么是 HTTP 管道化（Pipelining）？为什么它被废弃了？
- 管道化允许客户端在收到前一个请求的响应之前就发送下一个请求。但因为 HTTP/1.1 要求服务端的响应必须严格按照请求发送的先后顺序返回，导致严重的队头阻塞，且部分网络中间节点（代理/路由器）支持很差，最终被各大浏览器默认关闭，直到 HTTP/2 采用多路复用彻底替代。