HTTP 协议高频面试题总结

一、基础概念与传输层关联

1. 计算机网络分层模型

参考 TCP/IP 五层模型（面试高频考点，比 OSI 七层更实用）：

分层	协议示例	核心作用
应用层	HTTP、HTTPS、FTP、DNS	直接为应用程序提供服务，定义应用间通信格式（如 HTTP 报文结构）
传输层	TCP、UDP	负责端到端的数据传输，提供可靠性或高效性保障
网络层	IP、ICMP	负责跨网段的数据路由，将数据包从源主机发送到目标主机
数据链路层	以太网协议、ARP	负责相邻设备间的数据传输，将 IP 数据包封装为帧
物理层	网线、光纤、无线信号	负责二进制比特流的传输，处理物理介质的电气/机械特性

HTTP 与 TCP/UDP 的关系 ：
1. HTTP/1.0、HTTP/1.1、HTTP/2 均基于 TCP 协议传输，依赖 TCP 的可靠性保障。
2. HTTP/3 基于 QUIC 协议 传输，而 QUIC 是基于 UDP 实现的可靠传输协议。
3. UDP 本身不可靠，但可通过上层协议（如 QUIC）实现可靠性，兼顾 UDP 的高效和 TCP 的可靠。

2. TCP 和 UDP 的核心区别是什么？

TCP 和 UDP 是传输层的两大核心协议，特性差异直接决定上层应用的传输策略：

维度	TCP	UDP
连接性	面向连接（需三次握手建立连接，四次挥手断开连接）	无连接（无需建立连接，直接发送数据包）
可靠性	可靠传输（通过序列号、确认应答、重传机制保证数据不丢失、不重复、按序到达）	不可靠传输（不保证数据到达，也不保证顺序，可能丢包）
拥塞控制	有（慢启动、拥塞避免、快速重传/恢复等算法，防止网络拥塞）	无（发送方不感知网络状态，持续以固定速率发送）
传输方式	字节流传输（将数据视为连续字节，无边界）	数据报传输（以数据包为单位，有明确边界）
头部开销	大（20 - 60 字节，含序列号、确认号等字段）	小（仅 8 字节，含源端口、目的端口、长度、校验和）
适用场景	对可靠性要求高的场景：HTTP、HTTPS、FTP、邮件传输	对实时性要求高的场景：视频直播、语音通话、DNS 查询、IoT 设备通信

3. TCP 三次握手的过程是什么？为什么需要三次握手？

（1）三次握手核心流程（必须掌握，面试常画流程图）

TCP 是面向连接 的协议，客户端和服务器需通过三次握手建立可靠连接，核心是确认双方的发送和接收能力：

第一次握手（SYN） ：客户端 → 服务器
- 客户端发送 SYN 报文（同步报文），携带初始序列号 seq = x。
- 客户端进入 SYN_SENT 状态，等待服务器确认。
第二次握手（SYN + ACK） ：服务器 → 客户端
- 服务器收到 SYN 报文后，确认客户端发送能力正常。
- 服务器发送 SYN + ACK 报文，携带确认号 ack = x + 1（表示已收到 x 及之前的字节），同时携带自己的初始序列号 seq = y。
- 服务器进入 SYN_RCVD 状态。
第三次握手（ACK） ：客户端 → 服务器
- 客户端收到 SYN + ACK 报文后，确认服务器的发送和接收能力正常。
- 客户端发送 ACK 报文，携带确认号 ack = y + 1。
- 客户端和服务器均进入 ESTABLISHED 状态，连接建立完成。

（2）为什么需要三次握手？（核心是防止历史无效连接）

若只有两次握手：服务器发送 SYN + ACK 后就建立连接，但客户端可能未收到该报文，不会发送确认。此时服务器会一直等待客户端数据，浪费资源。
三次握手的本质：双方都确认了"我能发，你能收；你能发，我能收"，确保连接是双向有效。

4. TCP 四次挥手的过程是什么？为什么需要四次挥手？

TCP 连接是全双工 （双方可同时收发数据），断开连接需四次挥手，核心是双方都确认"没有数据要传输了"。

（1）四次挥手核心流程

第一次挥手（FIN） ：客户端 → 服务器
- 客户端无数据发送，发送 FIN 报文（终止报文），表示"我没有数据要发了"，序列号 seq = u。
- 客户端进入 FIN_WAIT_1 状态，等待服务器确认。
第二次挥手（ACK） ：服务器 → 客户端
- 服务器收到 FIN 报文，发送 ACK 报文，确认号 ack = u + 1。
- 服务器进入 CLOSE_WAIT 状态（此时服务器可能还有数据要发给客户端，连接半关闭）。
- 客户端收到 ACK 后，进入 FIN_WAIT_2 状态。
第三次挥手（FIN） ：服务器 → 客户端
- 服务器数据发送完毕，发送 FIN 报文，表示"我也没有数据要发了"，序列号 seq = v。
- 服务器进入 LAST_ACK 状态，等待客户端确认。
第四次挥手（ACK） ：客户端 → 服务器
- 客户端收到 FIN 报文，发送 ACK 报文，确认号 ack = v + 1。
- 客户端进入 TIME_WAIT 状态（等待 2MSL 时间，确保服务器收到确认），之后关闭连接。
- 服务器收到 ACK 后，立即关闭连接。

（2）为什么需要四次挥手？

因为 TCP 是全双工通信 ，断开连接时，双方都需要独立发送 FIN 报文，告知对方"我这边的数据传输结束了"。
两次挥手无法实现全双工关闭（服务器可能还有数据未发送），三次挥手则会导致客户端无法确认服务器是否已完成数据发送。

5. HTTP 建立连接的过程（HTTP 与 TCP 三次握手的联动）

以 HTTP/1.1 为例，浏览器访问网页的完整连接流程：

DNS 解析 ：浏览器将域名（如 www.baidu.com）解析为目标服务器的 IP 地址。
TCP 三次握手：客户端（浏览器）与服务器基于 IP 地址建立 TCP 连接。
发送 HTTP 请求：客户端向服务器发送 HTTP 请求报文（请求行 + 请求头 + 请求体）。
接收 HTTP 响应：服务器处理请求后，返回 HTTP 响应报文（状态行 + 响应头 + 响应体）。
断开/复用 TCP 连接 ：
- HTTP/1.0：默认短连接，响应后立即四次挥手断开 TCP 连接。
- HTTP/1.1：默认长连接 （Connection: keep-alive），连接会保持一段时间，供后续请求复用，超时/达到最大请求数后断开。

6. 什么是 TCP 队头阻塞？它对 HTTP 有什么影响？

（1）TCP 队头阻塞定义

TCP 是字节流、按序传输 的协议：如果一个 TCP 报文段在传输过程中丢失/延迟，即使后续报文段已到达，接收方也必须等待丢失的报文段重传成功后，才能将数据交给上层应用。这种"前面的报文段阻塞后面所有报文段"的现象，称为 TCP 队头阻塞。

（2）对 HTTP 的影响

HTTP/1.1 管道化请求 ：同一 TCP 连接下，客户端可连续发送多个请求，但服务器必须按序返回响应。若第一个请求的响应因 TCP 丢包被阻塞，后续所有响应都会被卡住。
HTTP/2 多路复用 ：HTTP/2 虽在应用层实现了"同一 TCP 连接下并行传输多个请求-响应流"，但底层仍基于 TCP。一旦发生 TCP 丢包，所有流都会被阻塞，只是阻塞的粒度比 HTTP/1.1 更细。
解决方案：HTTP/3 基于 QUIC 协议（UDP 之上的可靠传输），彻底解决了 TCP 队头阻塞问题。

二、HTTP 核心基础（请求响应、方法、状态码）

7. HTTP 请求报文和响应报文的完整结构是什么？（含字段详解）

（1）请求报文结构

复制代码

请求行 → Method + Request-URI + HTTP-Version + \r\n
请求头 → Header-Name: Header-Value + \r\n （多个字段，空行 \r\n 结束）
空行 → \r\n （分隔请求头和请求体）
请求体 → 可选（POST/PUT 请求的参数，如 JSON、表单数据）

核心请求头字段 ：
- Host：目标服务器域名/IP（HTTP/1.1 必选，支持一台服务器托管多个域名）。
- Content-Type：请求体的数据格式（如 application/json、application/x-www-form-urlencoded）。
- Content-Length：请求体的字节长度。
- Connection：控制连接类型（keep-alive 长连接 / close 短连接）。
- Cookie：携带客户端的 Cookie 信息，解决 HTTP 无状态问题。

（2）响应报文结构

复制代码

状态行 → HTTP-Version + Status-Code + Reason-Phrase + \r\n
响应头 → Header-Name: Header-Value + \r\n （多个字段，空行 \r\n 结束）
空行 → \r\n （分隔响应头和响应体）
响应体 → 服务器返回的资源（HTML、JSON、图片二进制流等）

核心响应头字段 ：
- Set-Cookie：服务器向客户端设置 Cookie。
- Cache-Control：控制缓存策略（如 max-age=3600）。
- ETag：资源的唯一标识，用于协商缓存。
- Access-Control-Allow-Origin：CORS 跨域配置，允许指定域名访问。

8. HTTP 请求方法的幂等性和安全性详解

方法	作用	幂等性	安全性	典型场景
GET	获取资源	是	是	查询用户信息、商品列表
POST	创建资源	否	否	提交表单、创建订单
PUT	全量更新资源	是	否	更新用户全部信息（需传完整字段）
DELETE	删除资源	是	否	删除订单、删除文件
PATCH	部分更新资源	否	否	更新用户昵称（仅传 nickname 字段）
HEAD	获取响应头（无响应体）	是	是	检查资源是否存在、获取文件大小
OPTIONS	预检请求（查询服务器支持的方法/头）	是	是	CORS 跨域预检、API 接口探测

关键概念辨析 ：
- 幂等性 ：多次执行同一请求，服务器端的状态不变 。如 PUT /user/1 多次执行，用户 1 的信息最终只保留最后一次更新结果；而 POST /order 多次执行会创建多个订单。
- 安全性 ：请求不会修改服务器端的资源状态。如 GET/HEAD/OPTIONS 仅读取资源，不会产生副作用。

9. HTTP 状态码分类及高频状态码深层含义

状态码由 3 位数字组成，首位表示类别，面试需掌握常见状态码的触发场景：

分类	首位	核心含义	高频状态码及场景
信息性响应	1xx	服务器已接收请求，需客户端继续操作	100 Continue：客户端发送大请求体前，服务器告知"可继续发送"；101 Switching Protocols：协议升级（如 HTTP 升级为 WebSocket）
成功响应	2xx	请求已成功处理	200 OK：请求成功；201 Created：资源创建成功（如 POST 创建订单）；204 No Content：请求成功但无响应体（如 DELETE 请求）
重定向响应	3xx	需客户端进一步操作（跳转）	301 Moved Permanently：永久重定向（域名更换，浏览器缓存新地址）；302 Found：临时重定向（未登录跳转登录页）；304 Not Modified：资源未修改，使用缓存；307 Temporary Redirect：临时重定向（严格保留原请求方法）
客户端错误	4xx	客户端请求有误，服务器无法处理	400 Bad Request：请求参数错误（如 JSON 格式非法）；401 Unauthorized：未授权（需登录，携带 Token）；403 Forbidden：权限不足（如普通用户访问管理员接口）；404 Not Found：资源不存在；405 Method Not Allowed：请求方法不支持（如用 GET 调用 POST 接口）；408 Request Timeout：客户端请求超时；429 Too Many Requests：请求频率超限（限流）
服务器错误	5xx	服务器处理请求时发生错误	500 Internal Server Error：服务器未知错误（如代码 bug）；502 Bad Gateway：网关错误（如 Nginx 反向代理的后端服务宕机）；503 Service Unavailable：服务器过载/维护；504 Gateway Timeout：网关超时（后端服务响应慢）

三、HTTP 版本演进（含 QUIC/HTTP3 底层传输）

10. HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3 核心区别（含传输层协议）

版本	发布时间	核心特性	底层传输协议	核心缺陷
HTTP/0.9	1991 年	极简协议，仅支持 GET 方法，无请求头/响应头，响应体仅为 HTML	TCP	功能单一，不支持图片、视频等资源
HTTP/1.0	1996 年	1. 支持 GET/POST/HEAD 方法 2. 引入请求头/响应头（如 Content-Type） 3. 默认短连接	TCP	短连接导致频繁三次握手/四次挥手，性能低
HTTP/1.1	1999 年	1. 默认长连接（`Connection: keep-alive`） 2. 支持管道化请求 3. 引入分块传输（`Transfer-Encoding: chunked`） 4. 新增 PUT/DELETE 等方法	TCP	1. 队头阻塞（管道化请求按序响应） 2. 明文传输，安全性低
HTTP/2	2015 年	1. 二进制帧：报文拆分为二进制帧，解析效率更高 2. 多路复用：同一 TCP 连接并行传输多个请求-响应流 3. 服务器推送：主动推送 CSS/JS 等资源 4. 头部压缩（HPACK 算法）	TCP	底层 TCP 队头阻塞未解决，丢包会阻塞所有流
HTTP/3	2022 年	1. 基于 QUIC 协议传输 2. 彻底解决 TCP 队头阻塞 3. 0-RTT/1-RTT 快速连接建立 4. 内置 TLS 1.3 加密	UDP（QUIC 基于 UDP）	兼容性差，部分老设备/浏览器不支持；服务器部署成本高

11. 什么是 QUIC 协议？它为什么能解决 TCP 队头阻塞？

QUIC（Quick UDP Internet Connections）是 Google 设计的基于 UDP 的可靠传输协议，是 HTTP/3 的底层传输核心，兼具 UDP 的高效和 TCP 的可靠。

（1）QUIC 核心特性

无队头阻塞 ：QUIC 为每个 HTTP 请求-响应流分配独立的序列号，单个流的丢包不会影响其他流。例如流 1 丢包重传时，流 2、流 3 的数据可正常交付给应用层。
快速连接建立 ：
- TCP + TLS 建立连接需 3-RTT（TCP 三次握手 1-RTT + TLS 握手 2-RTT）。
- QUIC 内置 TLS 1.3，首次连接仅需 1-RTT ，会话复用可实现 0-RTT（直接使用之前的密钥）。
连接迁移 ：QUIC 用 Connection ID 标识连接，而非 IP+端口。当客户端网络切换（如 WiFi → 4G），IP 变化但 Connection ID 不变，连接无需重建，适用于移动端。

（2）QUIC 解决 TCP 队头阻塞的本质

TCP 的队头阻塞源于连接级别的按序传输 ，而 QUIC 实现了 流级别的独立传输，丢包影响范围从"整个连接"缩小到"单个流"。

四、HTTP 缓存机制

12. HTTP 缓存完整执行流程（强缓存 → 协商缓存）

缓存是提升 HTTP 性能的核心手段，优先级：强缓存 > 协商缓存，完整执行步骤如下：

客户端首次请求资源：无缓存，发送 HTTP 请求 → 服务器返回 200 + 资源 + 缓存头（Cache-Control/Expires/ETag/Last-Modified）→ 客户端缓存资源及缓存头。
客户端再次请求同一资源：
- 第一步：判断强缓存 ：
  - 若 Cache-Control: max-age=xxx 未过期 → 直接使用本地缓存，返回 200 from disk/memory cache，不发请求到服务器。
  - 若强缓存过期 → 进入第二步协商缓存。
- 第二步：执行协商缓存 ：
  - 客户端携带缓存标识请求服务器：
    - 带 If-None-Match: 上次的 ETag（优先级高）；
    - 带 If-Modified-Since: 上次的 Last-Modified。
  - 服务器对比标识：
    - 资源未修改 → 返回 304 Not Modified，不携带响应体，客户端使用本地缓存；
    - 资源已修改 → 返回 200 + 新资源 + 新缓存标识，客户端更新缓存。

13. 缓存相关字段的优先级及冲突处理

强缓存字段优先级 ：Cache-Control（HTTP/1.1） > Expires（HTTP/1.0）。
- 原因：Expires 是绝对时间（如 Expires: Wed, 21 Oct 2025 07:28:00 GMT），依赖客户端本地时间，若客户端时间错误会导致缓存失效；Cache-Control 是相对时间（如 max-age=3600），更可靠。
协商缓存字段优先级 ：ETag/If-None-Match > Last-Modified/If-Modified-Since。
- 原因：Last-Modified 是秒级精度，无法区分 1 秒内的资源修改；ETag 是基于资源内容的哈希值，内容变则 ETag 变，精度更高。
特殊场景 ：若服务器同时返回 Cache-Control 和 Expires，以 Cache-Control 为准；若同时返回 ETag 和 Last-Modified，服务器优先判断 ETag。

五、跨域与安全

14. 跨域的本质及解决方案

（1）跨域本质

浏览器的 同源策略 限制：只有当两个页面的协议、域名、端口完全一致时，才视为同源，非同源页面无法相互访问 DOM、Cookie 或发送 AJAX 请求。同源策略是浏览器的安全机制，防止恶意网站窃取数据。

同源示例：http://www.example.com:80 和 http://www.example.com:80/api（协议、域名、端口一致）。
跨域示例：http://www.a.com 和 https://www.a.com（协议不同）；http://a.com 和 http://b.a.com（域名不同）。

（2）跨域解决方案

方案	核心原理	适用场景	配置示例
CORS（跨域资源共享）	服务器端配置响应头，允许指定域名跨域	前后端分离项目（推荐）	Nginx 配置： `add_header Access-Control-Allow-Origin *;` `add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE';` `add_header Access-Control-Allow-Headers 'Content-Type, Token';`
Nginx 反向代理	客户端访问同源的 Nginx 服务器，Nginx 转发请求到目标服务器（跨域在服务器端完成）	后端服务无法修改配置时	Nginx 配置： `location /api {` `proxy_pass http://www.target.com; # 目标服务器地址` `}`
JSONP	利用 `<script>` 标签不受同源策略限制，动态创建 script 标签请求资源	仅支持 GET 方法的老旧项目	客户端： `function callback(data) { console.log(data); }` `var script = document.createElement('script');` `script.src = 'http://www.target.com/api?callback=callback';` `document.body.appendChild(script);`
WebSocket	WebSocket 协议本身不限制同源，握手阶段通过 HTTP 升级为 WebSocket 连接	实时通信场景（如聊天、弹幕）	客户端： `var ws = new WebSocket('ws://www.target.com/ws');` `ws.onmessage = function(event) { console.log(event.data); };`

15. HTTP 常见安全漏洞及底层防护机制

漏洞类型	原理	防护措施	传输层/应用层联动防护
XSS（跨站脚本攻击）	注入恶意脚本，窃取 Cookie/伪造操作	1. 输入输出转义；2. 启用 CSP；3. Cookie 设置 `HttpOnly`	`HttpOnly` 禁止 JS 读取 Cookie，即使脚本注入也无法窃取
CSRF（跨站请求伪造）	诱导用户在已登录状态下发送恶意请求	1. 验证 `Referer`/`Origin`；2. 使用 CSRF Token；3. 敏感操作需二次验证	基于 TCP 连接的会话标识（Session ID）需与 CSRF Token 绑定，防止伪造
中间人攻击	劫持客户端与服务器的通信，篡改/窃取数据	1. 使用 HTTPS 协议；2. 验证服务器证书合法性	HTTPS 基于 TLS 加密传输，TCP 连接的可靠性保障加密报文不丢失
请求劫持	篡改 DNS 解析结果，将请求导向恶意服务器	1. 使用 HTTPS；2. 配置 DNSSEC；3. 客户端缓存正确 IP	网络层使用 IP 协议的路由校验，传输层 TCP 三次握手验证服务器身份

16. HTTPS 的完整握手过程

HTTPS = HTTP + TLS/SSL，其握手过程是 TCP 三次握手 + TLS 握手 的组合，确保传输安全：

TCP 三次握手：客户端与服务器建立 TCP 连接。
TLS 握手（以 TLS 1.2 为例，2-RTT） ：
- 客户端发送 Client Hello：携带支持的加密套件、TLS 版本、随机数 Client Random。
- 服务器发送 Server Hello：确认加密套件、TLS 版本、随机数 Server Random，并返回 数字证书（含服务器公钥）。
- 客户端验证证书合法性：通过 CA 证书链验证，确保服务器身份真实。
- 客户端生成 预主密钥：用服务器公钥加密后发送给服务器。
- 服务器用私钥解密预主密钥，客户端和服务器基于 Client Random + Server Random + 预主密钥 生成 会话密钥（对称加密密钥）。
- 双方发送 Finished 报文：用会话密钥加密，确认握手完成。
HTTP 通信：后续的 HTTP 请求/响应都用会话密钥加密传输。

六、高频关联面试题

17. 为什么 HTTP 基于 TCP 而不是 UDP？

HTTP 的核心需求是可靠性 ：用户访问网页时，需要确保 HTML、CSS、JS 等资源不丢失、按序到达。UDP 是不可靠传输，丢包后无法重传，会导致页面加载失败。
TCP 的特性适配 HTTP：TCP 的三次握手、确认应答、重传机制，能保证 HTTP 报文的可靠传输；长连接机制能复用 TCP 连接，减少性能开销。
例外情况：HTTP/3 基于 QUIC（UDP 之上的可靠协议），是因为 TCP 的队头阻塞问题无法解决，QUIC 兼顾了 UDP 的高效和 TCP 的可靠。

18. 浏览器输入 URL 后，完整的请求流程是什么？

这是面试压轴题，需按顺序描述 10 个核心步骤：

输入 URL ：用户在浏览器地址栏输入 www.baidu.com。
DNS 解析：浏览器查询本地 DNS 缓存 → 若未命中，向本地 DNS 服务器发送请求 → 本地 DNS 服务器递归查询根服务器、顶级域名服务器、权威服务器，最终返回 IP 地址。
建立 TCP 连接：客户端与服务器基于 IP 地址执行 TCP 三次握手。
TLS 握手（HTTPS 场景）：完成 TLS 握手，生成会话密钥。
发送 HTTP 请求：客户端发送 HTTP 请求报文（请求行 + 请求头 + 请求体）。
服务器处理请求：服务器解析请求，查询数据库/处理业务逻辑，生成响应数据。
返回 HTTP 响应：服务器发送 HTTP 响应报文（状态行 + 响应头 + 响应体）。
浏览器渲染页面：解析 HTML → 构建 DOM 树 → 解析 CSS → 构建 CSSOM 树 → 合成渲染树 → 布局 → 绘制。
关闭/复用 TCP 连接：若为长连接，复用连接；若为短连接，执行 TCP 四次挥手。
页面加载完成：浏览器执行 JS 脚本，绑定事件，页面交互可用。

19. 什么是 TCP 滑动窗口？它对 HTTP 传输性能有什么影响？

（1）TCP 滑动窗口定义

滑动窗口是 TCP 实现 流量控制 和 高效传输 的核心机制：

接收方通过 Window Size 字段告知发送方"自己当前的缓冲区剩余容量"，发送方只能发送窗口大小内的数据，避免接收方缓冲区溢出。
窗口滑动：发送方发送数据后，无需等待逐个确认，只要窗口未填满就继续发送；接收方确认一批数据后，窗口向右滑动，允许发送方继续发送新数据。

（2）对 HTTP 传输性能的影响

提升传输效率 ：滑动窗口实现了 流水线传输，发送方无需等待每个报文段的确认，可连续发送数据，大幅提升 HTTP 大资源（如视频、大文件）的传输速度。
适配网络状态：当网络拥塞时，接收方会减小窗口大小，发送方降低发送速率；当网络通畅时，窗口大小增大，发送速率提升。这种动态调整确保 HTTP 传输在不同网络环境下的稳定性。

HTTP 协议高频面试题总结