HTTP（HyperText Transfer Protocol，超文本传输协议）是构建 Web 的基石，也是面试中最高频、最基础但也最容易深入的知识点。从浏览器输入 URL 到页面展示，从 RESTful API 设计到微服务通信，HTTP 贯穿整个 Web 开发生命周期。
以下是对 HTTP 的全面技术解析，涵盖基础概念、协议演进、核心机制及高频面试题详解：
一、HTTP 到底是什么？
1.1 协议定位
HTTP 是应用层协议（OSI 第 7 层），基于 TCP/IP（HTTP/1.1、HTTP/2）或 QUIC/UDP（HTTP/3）传输，采用客户端-服务器（C/S）架构和请求-响应（Request-Response）模型。
┌─────────────────────────────────────────┐
│ 应用层 (HTTP) │ ← 定义数据格式和交互语义
├─────────────────────────────────────────┤
│ 传输层 (TCP/UDP) │ ← 定义端到端连接（端口）
├─────────────────────────────────────────┤
│ 网络层 (IP) │ ← 定义寻址和路由（IP地址）
└─────────────────────────────────────────┘
1.2 设计特点
- 无状态（Stateless）：服务器不保存客户端上下文，每次请求独立（需 Cookie/Session 解决）
- 无连接（Non-persistent）：HTTP/1.0 默认短连接，HTTP/1.1 起默认长连接（Keep-Alive）
- 灵活可扩展：Header 机制允许任意扩展，支持多种数据类型（MIME）
- 简单快速：报文文本化，易于调试和Mock
二、HTTP 进化史（面试常考时间线）
| 版本 | 发布时间 | 核心特性 | 痛点 |
|---|---|---|---|
| HTTP/0.9 | 1991 | 只有 GET，纯文本传输 | 无状态码、无 Header |
| HTTP/1.0 | 1996 | 引入 POST/HEAD、状态码、Header、短连接 | 每次请求新建 TCP 连接（三次握手开销） |
| HTTP/1.1 | 1997 | 持久连接（Keep-Alive）、管线化（Pipelining）、Host 头、缓存控制 | 队头阻塞（Head-of-Line Blocking） |
| HTTP/2 | 2015 | 二进制分帧、多路复用（Multiplexing）、头部压缩（HPACK）、服务器推送 | TCP 层队头阻塞 |
| HTTP/3 | 2022 | 基于 QUIC（UDP）、0-RTT 握手、连接迁移、彻底解决队头阻塞 | 中间设备兼容性问题 |
三、HTTP 报文解构（必须手写水平）
3.1 请求报文结构
POST /api/user HTTP/1.1 ← 请求行（方法 + URL + 版本）
Host: api.example.com ← 请求头（Header）
Content-Type: application/json ← 请求头
Content-Length: 39 ← 请求头
← 空行（CRLF）
{"name":"张三","age":25} ← 实体主体（Body，可选）
请求行解析：
- 方法（Method）：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE、CONNECT
- URL：协议名://主机名:端口/路径?查询参数#片段标识符
- 版本：HTTP/1.1 或 HTTP/2
3.2 响应报文结构
HTTP/1.1 200 OK ← 状态行（版本 + 状态码 + 原因短语）
Date: Mon, 27 Jan 2026 08:00:00 GMT
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
← 空行
{"id":1,"name":"张三"} ← 响应体
四、HTTP 方法（Method）深度对比
4.1 安全（Safe）与幂等（Idempotent）
- 安全方法：不修改服务器状态（GET、HEAD、OPTIONS）
- 幂等方法：多次执行结果相同（GET、PUT、DELETE），POST 和 PATCH 不幂等
4.2 GET vs POST（面试必问）
| 特性 | GET | POST |
|---|---|---|
| 语义 | 获取资源 | 创建/提交资源 |
| 幂等性 | 幂等 | 非幂等（多次提交创建多条记录） |
| 缓存 | 可被缓存 | 默认不缓存 |
| 书签 | 可收藏 | 不可收藏 |
| 长度限制 | URL 长度受限（浏览器通常 2KB-8KB） | 无限制（受服务器配置限制） |
| 数据位置 | URL 参数（?key=value） | Body 中 |
| 编码 | 只能 ASCII | 任意编码（通常 UTF-8） |
| 安全性 | 参数暴露（勿传密码） | 相对安全（但 HTTP 下仍明文） |
重要误区：
- POST 比 GET 安全？ → 错误的。HTTP 明文传输，两者都不安全，必须上 HTTPS。
- GET 不能带 Body？ → 协议允许，但多数服务器/框架会忽略或拒绝（如 Nginx、Django）。
- RESTful 必须用 GET/POST/PUT/DELETE？ → 实际中很多公司统一用 POST + Body 标识动作（规避公司防火墙对 PUT/DELETE 的拦截）。
五、HTTP 状态码（Status Code）详解
5.1 分类记忆法
- 1xx：Informational（信息性），如 100 Continue
- 2xx：Success（成功），200 OK，201 Created，204 No Content
- 3xx：Redirection（重定向），301 Moved Permanently，302 Found，304 Not Modified
- 4xx：Client Error（客户端错误），400 Bad Request，401 Unauthorized，403 Forbidden，404 Not Found，405 Method Not Allowed，409 Conflict
- 5xx：Server Error（服务器错误），500 Internal Server Error，502 Bad Gateway，503 Service Unavailable，504 Gateway Timeout
5.2 高频状态码场景题
301 vs 302 vs 307
- 301（永久重定向）：搜索引擎会更新 URL 索引，书签会自动更新。用于 HTTPS 强制跳转、域名更换。
- 302（临时重定向）：搜索引擎保留原 URL，用于未登录跳转登录页（但现代浏览器 302 也会把 POST 改为 GET）。
- 307（临时重定向，严格遵循）：要求重定向后的请求方法必须与原请求一致（如 POST 重定向后仍是 POST），解决 302 的历史遗留问题。
401 vs 403
- 401 Unauthorized：未认证（没登录），需携带
WWW-Authenticate头。 - 403 Forbidden：已认证但无权限（登录了但不是管理员），或服务器直接拒绝服务（IP 黑名单）。
502 vs 504
- 502 Bad Gateway：网关/代理（如 Nginx）从上游服务器（如 Django/gunicorn）收到无效响应（如连接被重置、PHP 语法错误）。
- 504 Gateway Timeout：网关超时未收到上游响应（上游处理太慢，超过 proxy_read_timeout）。
六、HTTP 连接管理演进
6.1 短连接（HTTP/1.0）
Connection: close
每次 HTTP 请求都要经历 TCP 三次握手 -> 传输 -> 四次挥手，开销巨大。
6.2 长连接 / 持久连接（HTTP/1.1 Keep-Alive）
Connection: keep-alive
Keep-Alive: timeout=5, max=1000
优势： TCP 连接复用，避免重复握手。 缺陷： 队头阻塞（Head-of-Line Blocking）——同一条连接上的请求必须串行响应，前一个响应慢，后面的请求即使处理好了也必须等着。
6.3 HTTP/2 多路复用（Multiplexing）
将请求/响应分割为二进制帧（Frame），不同 Stream ID 的帧可以交错发送，彻底解决 HTTP 层的队头阻塞。
:method GET
:scheme https
:authority api.example.com
:path /data ← Stream ID: 1
:method POST
:scheme https
:authority api.example.com
:path /upload ← Stream ID: 3（与 Stream 1 并发传输）
注意： HTTP/2 只是解决了 HTTP 层的队头阻塞，TCP 层的队头阻塞依然存在（一个 TCP 包丢失，所有流都要等待重传）。这就是 HTTP/3 改用 QUIC/UDP 的根本原因。
七、HTTP 缓存机制（高频考点）
缓存是 HTTP 性能优化的核心，分为强缓存和协商缓存。
7.1 强缓存（不会发请求到服务器）
由 Expires（HTTP/1.0）或 Cache-Control（HTTP/1.1，优先级更高）控制：
HTTP/1.1 200 OK
Cache-Control: max-age=3600 # 缓存 1 小时（相对时间，单位秒）
Expires: Wed, 21 Oct 2026 07:28:00 GMT # 绝对时间（受客户端时钟影响）
# 其他指令
Cache-Control: no-store # 禁止缓存（敏感数据）
Cache-Control: no-cache # 可以缓存，但必须重新验证（走协商缓存）
Cache-Control: private # 仅客户端缓存（CDN 不缓存）
Cache-Control: public # 代理服务器也可缓存
浏览器行为：首次请求后，在 max-age 时间内再次访问，直接从本地磁盘/内存读取，状态码显示 200 (from disk cache) 或 200 (from memory cache)。
7.2 协商缓存（发请求询问服务器是否可用）
当强缓存过期后，浏览器携带缓存标识询问服务器：
# 浏览器发送
GET /data HTTP/1.1
If-None-Match: "33a64df5" # 上次响应的 ETag
If-Modified-Since: Wed, 21 Oct 2026 07:28:00 GMT # 上次响应的 Last-Modified
# 服务器响应（内容未变）
HTTP/1.1 304 Not Modified # 无 Body，节省带宽
ETag: "33a64df5" # 更新 ETag（可能不变）
Last-Modified: Wed, 21 Oct 2026 07:28:00 GMT
ETag vs Last-Modified：
- Last-Modified：秒级精度，可能误判（1 秒内修改多次），且无法识别内容实质未变（仅 touch 文件）。
- ETag：实体标签，通常是文件内容的哈希值（如 MD5），优先级高于 Last-Modified，精确但计算有开销。
面试陷阱： 304 Not Modified 是客户端缓存生效，不是不请求，而是请求后服务器告诉客户端"用你本地的"。
八、Cookie 与 Session（状态管理）
HTTP 无状态，通过 Cookie/Session 维持登录态。
8.1 Set-Cookie 属性
Set-Cookie: sessionid=abc123; Expires=Wed, 09 Jun 2027 10:18:14 GMT;
Max-Age=3600; Domain=.example.com; Path=/; Secure; HttpOnly; SameSite=Lax
- Expires/Max-Age：过期时间（Max-Age 优先级更高，单位为秒）
- Domain：
.example.com表示所有子域（www.example.com、api.example.com）共享 - Path：
/admin仅 admin 路径下携带 - Secure：仅 HTTPS 传输（防中间人）
- HttpOnly：禁止 JavaScript 访问（
document.cookie读不到，防 XSS） - SameSite：防止 CSRF
Strict：仅同站请求携带（外部链接跳转会丢失登录态）Lax：允许顶级导航 GET 请求携带（如点击链接跳转）None：允许第三方请求携带（必须同时设置Secure）
8.2 Session vs JWT
| 方案 | 存储位置 | 优点 | 缺点 |
|---|---|---|---|
| Session | 服务器内存/Redis | 可控（可随时强制下线）、安全性高 | 服务器有状态、分布式需共享 Session |
| JWT | 客户端（LocalStorage/Cookie） | 无状态、易水平扩展 | Token 无法提前吊销（需等过期）、体积较大 |
九、HTTPS 与 HTTP 本质区别（面试重点）
9.1 不仅仅是 "HTTP + SSL/TLS"
HTTPS = HTTP + TLS/SSL（传输层安全协议），默认端口 443。
TLS 握手（简版）：
- 客户端发送支持的加密算法列表 + 随机数
- 服务器返回证书（含公钥）+ 选中的算法 + 随机数
- 客户端验证证书 -> 生成 Pre-master 随机数，用公钥加密发送
- 双方用三个随机数生成对称密钥（Session Key），后续通信全用此密钥加密
为什么用对称加密通信？ 非对称加密（RSA）计算量太大，仅用于握手阶段的密钥交换。
9.2 中间人攻击与证书链
- CA（Certificate Authority）：浏览器内置根证书，用于验证服务器证书真实性。
- 中间人攻击：如果没有证书验证，黑客可伪造公钥截获通信（如公共 WiFi 钓鱼）。
- 自签名证书：测试环境可用，生产环境浏览器会警告（NET::ERR_CERT_AUTHORITY_INVALID）。
十、CORS 跨域（Cross-Origin Resource Sharing）
浏览器同源策略（Same-Origin Policy）限制：协议、主机、端口三者必须完全一致。
10.1 简单请求 vs 预检请求（Preflight）
简单请求：满足以下全部条件：
- 方法：GET、HEAD、POST
- Header：仅
Accept、Accept-Language、Content-Language、Content-Type（且值仅为application/x-www-form-urlencoded、multipart/form-data、text/plain） - 无自定义 Header
非简单请求（如 Content-Type: application/json，或方法为 PUT/DELETE）： 浏览器自动发送 OPTIONS 预检请求：
OPTIONS /api/data HTTP/1.1
Host: api.example.com
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
# 服务器响应
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Max-Age: 86400 # 预检结果缓存 1 天
10.2 携带 Cookie 的跨域
fetch('https://api.example.com/data', {
credentials: 'include' // 或 axios withCredentials: true
});
服务器必须返回：
Access-Control-Allow-Origin: https://www.example.com # 不能为 *
Access-Control-Allow-Credentials: true
十一、高频面试题详解（含参考答案）
Q1：在浏览器地址栏输入 URL 后回车，发生了什么？（经典）
参考答案（分层阐述）：
- URL 解析：检查格式合法性，如果是域名进入 DNS 查询。
- DNS 解析：浏览器缓存 -> OS 缓存 -> 本地 DNS 服务器 -> 根域 -> 顶级域 -> 权威域，获取 IP 地址。
- 建立连接：
- HTTP/1.1：TCP 三次握手（SYN -> SYN+ACK -> ACK）
- HTTPS：额外 TLS 握手（证书验证 + 密钥交换）
- HTTP/3：QUIC 握手（0-RTT 或 1-RTT）
- 发送 HTTP 请求：构造请求行和 Header，如果是 POST 还要序列化 Body。
- 服务器处理：Nginx 反向代理 -> 应用服务器（Django/Node.js）-> 数据库查询 -> 业务逻辑 -> 组装响应。
- 浏览器渲染：解析 HTML -> 构建 DOM 树 -> 解析 CSS -> 构建 CSSOM -> 合并 Render Tree -> Layout -> Painting -> Composite。
- 连接关闭或复用：HTTP/1.1 Keep-Alive 复用连接，或 HTTP/2 多路复用。
Q2：GET 和 POST 的区别？（避免八股文答案）
除了表格对比，需强调：
- 语义差异：GET 是安全幂等的"获取"，POST 是"提交处理"。
- TCP 层面：GET 和 POST 都是 TCP 连接，没有本质区别。但部分浏览器/服务器对 GET URL 长度有限制（因为 URL 通常存在接收缓冲区首部）。
- RESTful 实践：POST 用于创建（201 Created），GET 用于查询（200 OK），幂等性保证重试安全。
Q3：HTTP/1.1 的 Keep-Alive 和 HTTP/2 的多路复用有什么区别？
- Keep-Alive：串行，一个时刻只能处理一个请求/响应对，必须等前一个完全回传才能发下一个（队头阻塞）。
- Multiplexing：并行，多个请求分割成帧，在一个 TCP 连接上乱序发送，服务器按 Stream ID 组装，互相不阻塞。
Q4：什么是队头阻塞（Head-of-Line Blocking）？如何解决？
- HTTP/1.1 层：一个连接上请求串行，前面的响应慢阻塞后面的。解决方案：开多个 TCP 连接（浏览器通常限制 6-8 个同域并发）。
- TCP 层（HTTP/2）：即使 HTTP 层多路复用，TCP 依然是可靠有序流。如果一个 TCP 包丢失，后续所有 HTTP 流的帧都必须等它重传。解决方案：HTTP/3 基于 QUIC（UDP），UDP 无连接状态，丢包只影响单个 Stream。
Q5：HTTP 是无状态的，为什么需要无状态？如何保持状态？
- 无状态优点：服务器设计简单，容易横向扩展（任何服务器实例都能处理请求，无需共享上下文）。
- 状态保持：通过 Cookie（客户端存 Session ID）或 Token（JWT）让客户端每次请求携带身份信息，服务器通过 ID 查数据库/Redis 获取状态。
Q6：HTTP 和 RPC（如 gRPC）有什么区别？
| 维度 | HTTP/REST | RPC（gRPC） |
|---|---|---|
| 协议层 | 应用层（文本协议） | 通常基于 HTTP/2，但语义封装 |
| 序列化 | JSON/XML（文本，可读） | Protobuf（二进制，高效） |
| 约束 | 统一接口（GET/POST/URL） | 自由（直接调用远程函数） |
| 性能 | 较低（文本解析 + Header 冗余） | 高（二进制 + 长连接复用） |
| 调试 | 简单（curl 即可） | 需专用工具 |
选择：对外暴露用 HTTP/REST（通用性），内部微服务通信用 gRPC（性能）。
Q7：什么是 304？它和 200 (from cache) 有什么区别？
- 304 Not Modified：客户端发现本地缓存过期（超过 max-age），携带 ETag/Last-Modified 询问服务器，服务器返回 304（无 Body，省流量），浏览器用本地缓存展示。
- 200 (from cache)：强缓存生效，没有发请求到服务器，直接从本地磁盘/内存读取。
Q8：HTTPS 一定安全吗？什么情况下仍不安全？
- 证书劫持：如果设备被植入根证书（如某些企业防火墙、恶意软件），可以伪造证书进行中间人攻击。
- 混合内容（Mixed Content）：HTTPS 页面中加载 HTTP 资源（图片、JS），这些资源可能被篡改。
- XSS/CSRF：HTTPS 只保证传输加密，不防注入攻击。
- 本地泄露：HTTPS 无法防止浏览器插件、恶意软件窃取内存中的 Cookie/Token。
十二、总结与学习建议
HTTP 看似简单，实则涉及网络协议、性能优化、安全防护等多个维度。面试准备时：
- 抓包实践：用 Chrome DevTools Network 面板观察真实站点的 Header、缓存策略、HTTP/2 帧。
- 搭建环境：本地用 Nginx 配置 HTTPS、Gzip、缓存头，观察不同配置下的请求行为。
- 深入 RFC：阅读 RFC 7230-7235（HTTP/1.1 语义和内容）和 RFC 7540（HTTP/2）。
- 区分概念：明确区分 TCP 连接、HTTP 请求、HTTP 响应、TLS 握手 的生命周期。
掌握 HTTP 不仅是应对面试，更是构建高性能、高可用、高安全 Web 系统的基石。
