PDF大白话说Java面试题 — 09_Zookeeper篇第2题说一下什么是 Http 协议回答核心考点 HTTP 协议是互联网通信的基石大厂面试中不会只问应用层协议、请求响应模型而是深入考察HTTP 各版本的演进差异队头阻塞的解决、二进制分帧、QUIC 协议、报文结构的字节级解析请求行/状态行、Header 压缩、Chunked 传输、状态码的语义与使用场景2xx/3xx/4xx/5xx 的精确区分、以及生产环境的性能优化Keep-Alive 调优、HTTP/2 服务端推送、TLS 握手优化。核心考察维度包括协议演进、报文结构、状态码语义、连接管理、安全机制、性能优化。1. HTTP 协议的本质与定位HTTPHyperText Transfer Protocol是应用层协议基于 TCPHTTP/1.1、HTTP/2或 UDPQUICHTTP/3采用请求-响应Request-Response模型客户端主动发起请求服务器被动返回响应。OSI 七层模型中的位置应用层: HTTP / HTTPS / FTP / DNS │ ▼ 传输层: TCP (HTTP/1.1, HTTP/2) / UDPQUIC (HTTP/3) │ ▼ 网络层: IP / ICMP │ ▼ 链路层: Ethernet / WiFiHTTP 的核心设计哲学简单性文本协议人类可读可扩展性Header 机制允许任意扩展无状态性每次请求独立服务器不保存客户端状态通过 Cookie/Session/Token 补偿统一接口GET/POST/PUT/DELETE 等语义化方法[citation:0]2. HTTP 报文结构详解2.1 请求报文Request Message请求行 GET /api/users?page1size20 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?page1size20 └───────────────── GET / POST / PUT / DELETE / PATCH / HEAD / OPTIONS常用方法语义方法语义幂等性安全性典型场景GET获取资源✅ 幂等✅ 安全查询数据POST创建资源❌ 不幂等❌ 不安全提交表单、创建订单PUT全量更新资源✅ 幂等❌ 不安全更新用户信息PATCH部分更新资源❌ 不幂等❌ 不安全修改用户昵称DELETE删除资源✅ 幂等❌ 不安全删除订单HEAD获取响应头无体✅ 幂等✅ 安全检查资源是否存在OPTIONS获取支持的方法✅ 幂等✅ 安全CORS 预检请求幂等性多次执行结果相同。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-age3600 Set-Cookie: sessionIdabc123; HttpOnly; Secure 空行 响应体 {code:200,data:{id:1,name:Alice}}状态行结构协议版本 状态码 原因短语 │ │ │ │ │ └── OK / Not Found / Internal Server Error │ └─────────── 200 / 404 / 500 └───────────────────── HTTP/1.1 / HTTP/22.3 状态码的精确语义2xx 成功状态码语义使用场景200 OK请求成功GET 查询成功、POST 创建成功返回资源201 Created资源创建成功POST 创建资源成功响应头 Location 指向新资源202 Accepted请求已接受异步处理中提交异步任务如文件上传、批量处理204 No Content请求成功无返回体DELETE 删除成功、PUT 更新成功206 Partial Content部分内容断点续传、Range 请求3xx 重定向状态码语义使用场景301 Moved Permanently永久重定向网站换域名SEO 权重转移302 Found临时重定向登录后跳转、短链接304 Not Modified缓存有效协商缓存客户端使用本地缓存307 Temporary Redirect临时重定向方法不变302 的修正版POST 重定向后仍用 POST308 Permanent Redirect永久重定向方法不变301 的修正版POST 重定向后仍用 POST4xx 客户端错误状态码语义使用场景400 Bad Request请求参数错误参数缺失、格式错误、校验失败401 Unauthorized未认证未登录、Token 过期403 Forbidden无权限已登录但无访问权限404 Not Found资源不存在URL 错误、资源已删除409 Conflict资源冲突并发修改冲突、唯一约束冲突429 Too Many Requests请求过多限流触发422 Unprocessable Entity语义错误参数格式正确但业务逻辑错误5xx 服务器错误状态码语义使用场景500 Internal Server Error服务器内部错误未捕获异常、代码 Bug502 Bad Gateway网关错误Nginx 代理的后端服务不可用503 Service Unavailable服务不可用服务维护、过载保护504 Gateway Timeout网关超时后端服务响应超时[citation:2]3. HTTP 版本演进与核心差异3.1 HTTP/1.01996特点每个请求/响应对需要独立的 TCP 连接请求完成后立即关闭连接问题请求 HTML 页面 ├── TCP 三次握手 ├── 发送 GET /index.html ├── 接收响应 └── TCP 四次挥手 请求 CSS 文件 ├── TCP 三次握手再次 ├── 发送 GET /style.css ├── 接收响应 └── TCP 四次挥手 请求 JS 文件 ├── TCP 三次握手再次 └── ... → 大量 TCP 握手/挥手开销延迟高3.2 HTTP/1.11997——持久连接与管道化核心改进特性说明配置持久连接Keep-Alive多个请求复用同一 TCP 连接Connection: keep-alive默认开启管道化Pipelining客户端可连续发送多个请求无需等待响应实际因队头阻塞问题很少使用分块传输Chunked服务器边生成边发送无需预先知道 Content-LengthTransfer-Encoding: chunked缓存控制更精细的缓存策略Cache-Control、ETag、Last-ModifiedHost 头支持虚拟主机同一 IP 多域名Host: api.example.comKeep-Alive 的队头阻塞Head-of-Line BlockingHTTP/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/22015——二进制分帧与多路复用核心改进特性HTTP/1.1HTTP/2效果传输格式文本二进制分帧更高效解析错误率更低多路复用单连接串行单连接并行多流解决队头阻塞头部压缩无压缩HPACK 算法减少重复 Header 传输服务端推送不支持支持服务器主动推送资源流优先级不支持支持优先传输关键资源二进制分帧层HTTP/2 将请求/响应拆分为二进制帧 Stream 1 (请求 /index.html): HEADERS 帧: :methodGET, :path/index.html DATA 帧: (空) Stream 3 (请求 /style.css): HEADERS 帧: :methodGET, :path/style.css DATA 帧: (空) Stream 5 (请求 /script.js): HEADERS 帧: :methodGET, :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/32022——基于 QUIC 协议核心改进特性HTTP/2HTTP/3效果传输层TCP TLSQUIC (UDP TLS 1.3)减少握手延迟队头阻塞TCP 层存在无基于 UDP彻底解决连接迁移不支持支持连接 ID网络切换不中断握手延迟2-3 RTT0-1 RTT首次连接更快拥塞控制TCP 内核实现用户空间实现更灵活快速迭代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 不变 → 继续传输 → 网络切换无感知版本连接建立队头阻塞头部压缩多路复用连接迁移适用场景HTTP/1.03 RTT/请求无单请求无无❌已淘汰HTTP/1.13 RTT 首次后续复用应用层无单连接串行❌兼容老旧系统HTTP/23 RTT 首次后续复用TCP 层HPACK单连接并行❌当前主流HTTP/31 RTT 首次0 RTT 后续无QPACK单连接并行✅移动端、高延迟网络[citation:4]4. HTTP 安全机制4.1 HTTPS HTTP TLS/SSLHTTP HTTPS │ │ ▼ ▼ TCP 80 TLS/SSL │ ▼ TCP 443TLS 1.2 握手2-RTTClient → Server: ClientHello (支持的加密套件、随机数) Client ← Server: ServerHello (选定加密套件、随机数、证书) Client → Server: ClientKeyExchange (预主密钥加密传输) Client ← Server: Finished (握手完成) → 2 RTT 后才能发送应用数据TLS 1.3 握手1-RTTClient → Server: ClientHello KeyShare (直接发送公钥) Client ← Server: ServerHello EncryptedExtensions Finished → 1 RTT 后发送应用数据 → 支持 0-RTT 模式使用之前会话的 PSK4.2 HSTSHTTP Strict Transport SecurityStrict-Transport-Security: max-age31536000; includeSubDomains; preload作用强制浏览器使用 HTTPS 访问禁止 HTTP防止 SSL 剥离攻击中间人强制降级到 HTTP4.3 CSPContent Security PolicyContent-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 连接层优化优化手段配置效果Keep-Alive 超时调优KeepAliveTimeout 65减少 TCP 握手开销TCP Fast Open内核参数tcp_fastopen3减少 1 RTTTLS 1.3升级 OpenSSL/Nginx减少 1 RTTHTTP/2 Server PushLink: /style.css; relpreload; asstyle服务器主动推送关键资源HTTP/3升级 Nginx/Cloudflare彻底解决队头阻塞5.2 应用层优化优化手段实现效果Gzip/Brotli 压缩Content-Encoding: br减少 70%~80% 传输体积缓存策略Cache-Control: max-age31536000, immutable减少重复请求CDN 分发边缘节点缓存静态资源减少源站压力降低延迟域名分片静态资源使用独立域名突破浏览器 6~8 连接限制资源合并CSS/JS 合并、雪碧图减少请求数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; relpreload; asstyle always; add_header Link /app.js; relpreload; asscript 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 是应用层协议基于 TCPHTTP/1.1、HTTP/2或 UDPQUICHTTP/3采用请求-响应模型。核心特点无状态每次请求独立服务器不保存客户端状态通过 Cookie/Session/Token 补偿。统一接口GET获取、POST创建、PUT全量更新、PATCH部分更新、DELETE删除等方法语义明确。可扩展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 的核心区别在语义和使用场景而非传参方式语义GET 是获取资源POST 是创建资源。GET 是安全且幂等的POST 不是。缓存GET 请求可被浏览器缓存POST 默认不缓存。书签/历史GET URL 可被收藏和分享POST 不能。参数位置GET 参数在 URL有长度限制约 2KB~8KBPOST 参数在 Body无限制。幂等性GET 多次执行结果相同POST 多次执行可能创建多个资源。常见误区‘GET 参数在 URLPOST 在 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 Redirect302 的修正版强制保留请求方法。POST 重定向后仍是 POST。308 Permanent Redirect301 的修正版强制保留请求方法。POST 重定向后仍是 POST。使用建议永久重定向且需要保留方法 → 308临时重定向且需要保留方法 → 307兼容老旧客户端 → 301/302追问 5“HTTPS 的握手过程是怎样的TLS 1.3 相比 1.2 有什么改进”高分回答TLS 1.2 握手需要 2 RTTClientHello (支持的加密套件、随机数)ServerHello Certificate ServerKeyExchangeClientKeyExchange (预主密钥加密传输)Finished→ 2 RTT 后才能发送应用数据。TLS 1.3 改进1-RTT 握手ClientHello 直接包含 KeyShare公钥ServerHello 返回选定参数1 RTT 后发送数据。0-RTT 模式使用之前会话的 PSKPre-Shared Key首次请求 0 RTT。简化加密套件从 1.2 的数十种减少到 1.3 的 5 种减少协商复杂度。前向安全即使长期私钥泄露历史会话也不受影响。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; relpreload头客户端收到后主动请求比 Server Push 更可控资源内联将关键 CSS/JS 直接嵌入 HTML减少请求数7. 方案选型速查表场景推荐协议/配置核心理由传统 Web 应用HTTP/2 TLS 1.3当前主流兼容性好移动端/高延迟网络HTTP/3 (QUIC)0-RTT连接迁移抗丢包内部微服务通信HTTP/2 gRPC二进制协议高效序列化静态资源 CDNHTTP/2 Brotli压缩率高多路复用API 网关HTTP/2 限流高并发连接复用实时通信WebSocket / HTTP/3低延迟全双工遗留系统兼容HTTP/1.1兼容性优先面试官想要的满分总结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 才能彻底解决。觉得对您有帮助麻烦点点关注啦您的关注是我创作的最大动力~