企业官网建设流程全解析

📌PDF：大白话说Java面试题 — 09_Zookeeper篇

第2题：说一下什么是 Http 协议？

📚回答：

• 核心考点： HTTP 协议是互联网通信的基石，大厂面试中不会只问"应用层协议、请求响应模型"，而是深入考察HTTP 各版本的演进差异（队头阻塞的解决、二进制分帧、QUIC 协议）、报文结构的字节级解析（请求行/状态行、Header 压缩、Chunked 传输）、状态码的语义与使用场景（2xx/3xx/4xx/5xx 的精确区分）、以及生产环境的性能优化（Keep-Alive 调优、HTTP/2 服务端推送、TLS 握手优化）。核心考察维度包括：协议演进、报文结构、状态码语义、连接管理、安全机制、性能优化。

1. HTTP 协议的本质与定位

HTTP（HyperText Transfer Protocol）是应用层协议，基于 TCP（HTTP/1.1、HTTP/2）或 UDP+QUIC（HTTP/3），采用请求-响应（Request-Response）模型，客户端主动发起请求，服务器被动返回响应。

OSI 七层模型中的位置：

应用层: HTTP / HTTPS / FTP / DNS │ ▼ 传输层: TCP (HTTP/1.1, HTTP/2) / UDP+QUIC (HTTP/3) │ ▼ 网络层: IP / ICMP │ ▼ 链路层: Ethernet / WiFi

HTTP 的核心设计哲学：

• 简单性：文本协议，人类可读
• 可扩展性：Header 机制允许任意扩展
• 无状态性：每次请求独立，服务器不保存客户端状态（通过 Cookie/Session/Token 补偿）
• 统一接口：GET/POST/PUT/DELETE 等语义化方法

[citation:0]

2. HTTP 报文结构详解

• 2.1 请求报文（Request Message）

请求行 GET /api/users?page=1&size=20 HTTP/1.1 请求头 Host: api.example.com Accept: application/json Authorization: Bearer eyJhbGci... User-Agent: Mozilla/5.0... 空行 请求体 (GET 无请求体，POST/PUT 有)

请求行结构：

<方法> <URI> <协议版本> │ │ │ │ │ └── HTTP/1.1 或 HTTP/2 │ └────────── /api/users?page=1&size=20 └───────────────── GET / POST / PUT / DELETE / PATCH / HEAD / OPTIONS

常用方法语义：

幂等性：多次执行结果相同。GET/PUT/DELETE 是幂等的，POST/PATCH 不是。
安全性：不改变服务器状态。GET/HEAD/OPTIONS 是安全的，其他不是。

[citation:1]

• 2.2 响应报文（Response Message）

状态行 HTTP/1.1 200 OK 响应头 Content-Type: application/json Content-Length: 256 Cache-Control: max-age=3600 Set-Cookie: sessionId=abc123; HttpOnly; Secure 空行 响应体 {"code":200,"data":{"id":1,"name":"Alice"}}

状态行结构：

<协议版本> <状态码> <原因短语> │ │ │ │ │ └── OK / Not Found / Internal Server Error │ └─────────── 200 / 404 / 500 └───────────────────── HTTP/1.1 / HTTP/2

• 2.3 状态码的精确语义

2xx 成功：

3xx 重定向：

4xx 客户端错误：

5xx 服务器错误：

[citation:2]

3. HTTP 版本演进与核心差异

• 3.1 HTTP/1.0（1996）

特点：

• 每个请求/响应对需要独立的 TCP 连接
• 请求完成后立即关闭连接

问题：

请求 HTML 页面 ├── TCP 三次握手 ├── 发送 GET /index.html ├── 接收响应 └── TCP 四次挥手 请求 CSS 文件 ├── TCP 三次握手（再次！） ├── 发送 GET /style.css ├── 接收响应 └── TCP 四次挥手 请求 JS 文件 ├── TCP 三次握手（再次！） └── ... → 大量 TCP 握手/挥手开销，延迟高

• 3.2 HTTP/1.1（1997）——持久连接与管道化

核心改进：

Keep-Alive 的队头阻塞（Head-of-Line Blocking）：

HTTP/1.1 Keep-Alive 连接： 请求1: GET /api/a → 处理耗时 10s 请求2: GET /api/b → 处理耗时 1s 请求3: GET /api/c → 处理耗时 1s 虽然共用一个 TCP 连接，但响应必须按请求顺序返回！ → 请求2和3必须等请求1完成后才能返回 → 队头阻塞：前面的慢请求阻塞后面的快请求

解决方案：浏览器并行开启 6~8 个 TCP 连接（域名分片）。

• 3.3 HTTP/2（2015）——二进制分帧与多路复用

核心改进：

二进制分帧层：

HTTP/2 将请求/响应拆分为二进制帧： Stream 1 (请求 /index.html): HEADERS 帧: :method=GET, :path=/index.html DATA 帧: (空) Stream 3 (请求 /style.css): HEADERS 帧: :method=GET, :path=/style.css DATA 帧: (空) Stream 5 (请求 /script.js): HEADERS 帧: :method=GET, :path=/script.js DATA 帧: (空) → 三个 Stream 在同一个 TCP 连接上交错传输 → 互不阻塞，解决 HTTP/1.1 的队头阻塞

HPACK 头部压缩：

请求1: GET /page1 Host: api.example.com Accept: application/json Authorization: Bearer eyJhbGciOiJIUzI1NiIs... 请求2: GET /page2 Host: api.example.com ← 静态表索引，1 字节 Accept: application/json ← 静态表索引，1 字节 Authorization: Bearer ... ← 动态表索引，1 字节 → 后续请求 Header 只需几个字节！

但 HTTP/2 仍有 TCP 层队头阻塞：

HTTP/2 多路复用在一个 TCP 连接上： Stream 1 的帧丢失 → TCP 重传 → 所有 Stream 等待 → TCP 层队头阻塞：一个 Stream 的丢包阻塞所有 Stream

[citation:3]

• 3.4 HTTP/3（2022）——基于 QUIC 协议

核心改进：

QUIC 的 0-RTT 握手：

HTTP/2 (TCP + TLS 1.2): TCP 三次握手: 1 RTT TLS 握手: 2 RTT 总: 3 RTT 后才能发送请求 HTTP/3 (QUIC + TLS 1.3): 首次连接: 1 RTT (QUIC 握手内含 TLS 1.3) 后续连接: 0 RTT (使用之前会话的密钥) → 首次请求发送时间减少 67%

连接迁移：

HTTP/2 (TCP): 手机从 WiFi 切换到 4G → IP 变化 → TCP 连接断开 → 重新建立连接 HTTP/3 (QUIC): 手机从 WiFi 切换到 4G → IP 变化 → 连接 ID 不变 → 继续传输 → 网络切换无感知

[citation:4]

4. HTTP 安全机制

• 4.1 HTTPS = HTTP + TLS/SSL

HTTP HTTPS │ │ ▼ ▼ TCP 80 TLS/SSL │ ▼ TCP 443

TLS 1.2 握手（2-RTT）：

Client → Server: ClientHello (支持的加密套件、随机数) Client ← Server: ServerHello (选定加密套件、随机数、证书) Client → Server: ClientKeyExchange (预主密钥加密传输) Client ← Server: Finished (握手完成) → 2 RTT 后才能发送应用数据

TLS 1.3 握手（1-RTT）：

Client → Server: ClientHello + KeyShare (直接发送公钥) Client ← Server: ServerHello + EncryptedExtensions + Finished → 1 RTT 后发送应用数据 → 支持 0-RTT 模式（使用之前会话的 PSK）

• 4.2 HSTS（HTTP Strict Transport Security）

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

作用：

• 强制浏览器使用 HTTPS 访问，禁止 HTTP

• 防止 SSL 剥离攻击（中间人强制降级到 HTTP）

• 4.3 CSP（Content Security Policy）

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src *

作用：

• 限制页面加载资源的来源，防止 XSS 攻击
• default-src 'self'：默认只允许同源资源
• script-src：限制 JS 来源
• img-src *：允许任意来源图片

[citation:5]

5. HTTP 性能优化

• 5.1 连接层优化

• 5.2 应用层优化

• 5.3 Nginx HTTP/2 配置示例

server { listen 443 ssl http2; server_name api.example.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'; # HTTP/2 Server Push location = /index.html { add_header Link "</style.css>; rel=preload; as=style" always; add_header Link "</app.js>; rel=preload; as=script" always; } # Brotli 压缩 brotli on; brotli_types text/plain text/css application/json application/javascript; # 缓存控制 location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg)$ { expires 1y; add_header Cache-Control "public, immutable"; } }

[citation:6]

6. 面试官追问与高分回答模板

• 追问 1：“说一下 HTTP 协议？”

低分回答：“HTTP 是应用层协议，基于请求响应模型，无状态。”（太浅）

高分回答：

"HTTP 是应用层协议，基于 TCP（HTTP/1.1、HTTP/2）或 UDP+QUIC（HTTP/3），采用请求-响应模型。
核心特点：

1. 无状态：每次请求独立，服务器不保存客户端状态，通过 Cookie/Session/Token 补偿。
2. 统一接口：GET（获取）、POST（创建）、PUT（全量更新）、PATCH（部分更新）、DELETE（删除）等方法语义明确。
3. 可扩展：Header 机制允许任意扩展，如 Authorization、Cache-Control 等。
   版本演进：HTTP/1.0 短连接 → HTTP/1.1 Keep-Alive（仍有队头阻塞） → HTTP/2 二进制分帧+多路复用（解决应用层队头阻塞，但 TCP 层仍存在） → HTTP/3 QUIC（基于 UDP，彻底解决队头阻塞，支持连接迁移）。"

• 追问 2：“HTTP/1.1 的队头阻塞是什么？HTTP/2 怎么解决的？HTTP/3 又解决了什么？”

高分回答：

"HTTP/1.1 的队头阻塞是应用层的：Keep-Alive 连接上，响应必须按请求顺序返回。如果第一个请求处理慢（如 10 秒），后面的请求即使处理快（如 1 秒）也必须等待。
HTTP/2 通过二进制分帧 + 多路复用解决应用层队头阻塞：将请求/响应拆分为二进制帧，多个 Stream 在同一个 TCP 连接上交错传输，互不阻塞。
但 HTTP/2 仍有TCP 层队头阻塞：一个 Stream 的帧丢失，TCP 重传会阻塞所有 Stream。
HTTP/3 基于QUIC 协议（UDP + TLS 1.3）彻底解决：

• QUIC 在应用层实现可靠传输，每个 Stream 独立拥塞控制和重传
• 一个 Stream 丢包不影响其他 Stream
• 支持 0-RTT 握手和连接迁移（网络切换不中断）"

• 追问 3：“GET 和 POST 有什么区别？”

高分回答：

"GET 和 POST 的核心区别在语义和使用场景，而非传参方式：

1. 语义：GET 是获取资源，POST 是创建资源。GET 是安全且幂等的，POST 不是。
2. 缓存：GET 请求可被浏览器缓存，POST 默认不缓存。
3. 书签/历史：GET URL 可被收藏和分享，POST 不能。
4. 参数位置：GET 参数在 URL（有长度限制，约 2KB~8KB），POST 参数在 Body（无限制）。
5. 幂等性：GET 多次执行结果相同，POST 多次执行可能创建多个资源。
   常见误区：

• ‘GET 参数在 URL，POST 在 Body’ → 技术上 GET 也可以有 Body（虽然不推荐），POST 也可以有 URL 参数
• ‘POST 比 GET 安全’ → 都不安全，HTTPS 才安全
  实际选型：获取数据用 GET，创建/提交数据用 POST。"

• 追问 4：“301 和 302 有什么区别？什么时候用 307 和 308？”

高分回答：

"301 和 302 的核心区别在于永久性和方法保留：

• 301 Moved Permanently：永久重定向，SEO 权重转移到新 URL。但某些客户端会将 POST 改为 GET（历史遗留问题）。
• 302 Found：临时重定向，SEO 权重保留在原 URL。同样存在 POST 变 GET 的问题。
• 307 Temporary Redirect：302 的修正版，强制保留请求方法。POST 重定向后仍是 POST。
• 308 Permanent Redirect：301 的修正版，强制保留请求方法。POST 重定向后仍是 POST。
  使用建议：
• 永久重定向且需要保留方法 → 308
• 临时重定向且需要保留方法 → 307
• 兼容老旧客户端 → 301/302"

• 追问 5：“HTTPS 的握手过程是怎样的？TLS 1.3 相比 1.2 有什么改进？”

高分回答：

"TLS 1.2 握手需要 2 RTT：

1. ClientHello (支持的加密套件、随机数)
2. ServerHello + Certificate + ServerKeyExchange
3. ClientKeyExchange (预主密钥加密传输)
4. Finished
   → 2 RTT 后才能发送应用数据。
   TLS 1.3 改进：
5. 1-RTT 握手：ClientHello 直接包含 KeyShare（公钥），ServerHello 返回选定参数，1 RTT 后发送数据。
6. 0-RTT 模式：使用之前会话的 PSK（Pre-Shared Key），首次请求 0 RTT。
7. 简化加密套件：从 1.2 的数十种减少到 1.3 的 5 种，减少协商复杂度。
8. 前向安全：即使长期私钥泄露，历史会话也不受影响。
   HTTP/3 的 QUIC 将 TLS 1.3 集成到握手过程中，实现 0-RTT 或 1-RTT 的首次请求。"

• 追问 6：“HTTP/2 的服务端推送是什么？有什么使用场景和限制？”

高分回答：

"HTTP/2 Server Push 允许服务器在客户端请求 HTML 时，主动推送 CSS、JS 等关键资源，减少客户端解析 HTML 后再发请求的时间。
使用场景：

• 推送首屏关键 CSS/JS，减少渲染阻塞
• 推送 API 预加载数据（如用户登录后推送个人配置）
  限制：
• 浏览器可能已缓存该资源，推送浪费带宽
• 推送资源必须与主请求同源
• 优先级控制复杂，可能推送非关键资源
• 部分浏览器（如 Safari）已禁用 Server Push
  替代方案：
• Link: <url>; rel=preload头：客户端收到后主动请求，比 Server Push 更可控
• 资源内联：将关键 CSS/JS 直接嵌入 HTML，减少请求数"

7. 方案选型速查表

💡面试官想要的满分总结：

HTTP 协议是互联网通信的基石，理解它必须抓住版本演进、报文语义、性能瓶颈三个维度：

版本演进：HTTP/1.0 短连接 → HTTP/1.1 Keep-Alive（应用层队头阻塞） → HTTP/2 二进制分帧+多路复用（解决应用层队头阻塞，TCP 层仍存在） → HTTP/3 QUIC（基于 UDP，彻底解决队头阻塞，0-RTT，连接迁移）。

报文语义：方法（GET/POST/PUT/PATCH/DELETE）的幂等性和安全性是设计 RESTful API 的基础。状态码的精确使用（201 Created、202 Accepted、409 Conflict、422 Unprocessable Entity）体现 API 设计的专业性。

性能优化：连接层（Keep-Alive、TLS 1.3、HTTP/3）、应用层（HPACK/QPACK 压缩、缓存策略、CDN）、安全层（HSTS、CSP）三个层面综合优化。

最后记住：HTTP 是无状态的应用层协议，状态管理通过 Cookie/Session/Token 补偿。HTTPS 不是单独的协议，而是 HTTP over TLS。HTTP/2 的多路复用解决了应用层队头阻塞，但 TCP 层队头阻塞需要 HTTP/3 的 QUIC 才能彻底解决。

觉得对您有帮助，麻烦点点关注啦，您的关注是我创作的最大动力~ 🎯