HTTP 高频问答整理，面试不用愁！

Sport
156 阅读19分钟

http1.0，http2.0 http3.0 区别各自解决了什么问题？

HTTP/1.0、HTTP/2.0、HTTP/3.0 是 HTTP 协议的三个核心版本，迭代的核心目标是解决性能瓶颈，尤其是队头阻塞和连接开销问题，三者在传输层协议、并发模型、性能优化手段上有本质区别。

HTTP 1.0 ： 基础的超文本传输协议

核心特点

  1. 短连接模型：默认一次 请求/响应 对应一个 TCP 连接，请求完成后 TCP 连接立即关闭。
    1. 每个 请求/响应 都需要重新 三次握手四次挥手。
    2. 延迟较高，如访问一个网页需要多次建立连接。
  1. 无管道化：请求必须串行执行，下一个请求必须等待上一个请求的响应返回后才能发送。
  2. 头部无压缩：HTTP 头部（如 User-Agent、Cookie）每次请求都会完整传输，大量重复字段造成带宽浪费。
  3. 功能简陋：不支持虚拟主机、断点续传、长连接等高级特性。

解决的问题

实现了超文本（HTML）的跨主机传输，是 Web 协议的基础，让浏览器能从服务器获取并渲染页面。

存在的核心痛点

  • 连接开销大：每次请求都要经历 TCP 三次握手 + 四次挥手，高频请求场景下延迟极高。
  • 队头阻塞严重：一个请求超时 / 阻塞，后续所有请求都要排队等待。
  • 并发能力弱：浏览器为了提升并发，只能开启多个 TCP 连接（通常限制 6-8 个），但连接数有限且会带来额外资源消耗。

HTTP 2.0 ：二进制与多路复用的突破

HTTP/2.0 基于 Google 的 SPDY 协议演进而来，核心是在 TCP 之上引入二进制分帧层，彻底解决 HTTP/1.x 的应用层队头阻塞问题。

核心特点

  1. 二进制分帧层：多路复用
    • 这是 HTTP/2.0 的核心创新。它将 HTTP 报文拆分为二进制帧（Frame），每个帧都有一个流 ID 标识归属的请求 / 响应。
    • 多个请求的帧可以在同一个 TCP 连接上并行传输，无需等待上一个请求的响应完成，这就是多路复用。
  1. 头部压缩（HPACK 算法）
    • 维护客户端与服务器的头部字典，存储重复出现的头部字段（如 Cookie、Accept-Encoding）。
    • 传输时只发送字典索引或差异字段，头部体积可减少 60%-90%。
  1. 服务器推送（Server Push）
    • 服务器可以主动向客户端推送资源，无需等待客户端请求。
    • 例如：客户端请求 index.html，服务器可主动推送对应的 style.css 和 app.js，减少请求次数。
  1. 请求优先级
    • 可以为不同的流（请求）设置优先级，服务器优先处理高优先级的帧（如页面核心渲染资源），优化页面加载顺序。

解决的问题

  1. 解决了 HTTP/1.x 的应用层队头阻塞：多路复用让同一个 TCP 连接上的多个请求并行执行。
  2. 解决了头部冗余问题：HPACK 压缩大幅降低头部传输带宽。
  3. 提升了并发效率：单个 TCP 连接即可承载大量并发请求，无需依赖多连接。

存在的核心痛点

  • 传输层队头阻塞未解决：HTTP/2.0 依然基于 TCP 协议，TCP 是字节流有序传输协议，一旦某个数据包丢失，整个 TCP 连接上的所有 HTTP 流都会阻塞，等待丢失的数据包重传。
  • TCP 握手开销高：尤其是 HTTPS 场景下，TCP 三次握手 + TLS 握手的延迟依然明显。
  • 连接迁移困难：TCP 连接与 IP 绑定，客户端网络切换（如 WiFi → 4G）时，IP 变化会导致连接断开，必须重新握手。

HTTP 3.0 ：基于 UDP 的新一代高性能协议

  • 用 UDP 替代 TCP，避免 TCP 三次握手的延迟，首次连接可在 1 个 RTT（往返时间）内完成（TCP 需 3 个 RTT）。
  • 无连接级队头阻塞： 每个请求 / 响应作为独立 Stream（流），单个 Stream 丢包不影响其他 Stream

HTTP/3.0 前身为 QUIC 协议，核心是抛弃 TCP，基于 UDP 构建可靠传输层，彻底解决 TCP 带来的队头阻塞问题。

核心特点

  1. 基于 UDP 协议
    • UDP 是无连接、无序的传输协议，本身没有队头阻塞特性。HTTP/3 在 UDP 之上实现了可靠传输、流量控制、拥塞控制等 TCP 具备的核心功能。
  1. 彻底解决队头阻塞
    • 每个 HTTP 流的数据在 QUIC 中是独立传输的，单个流的数据包丢失不会影响其他流。例如：流 A 丢包重传时，流 B 可以正常传输，这是 HTTP/2.0 无法实现的。
  1. 快速握手（0-RTT/1-RTT）
    • QUIC 把 TCP 握手和 TLS 握手合并为一次，支持 0-RTT 握手（会话复用场景下，客户端无需等待服务器响应即可发送请求），大幅降低连接建立延迟。
  1. 连接迁移
    • QUIC 用 Connection ID 标识连接，而非 IP + 端口。客户端网络切换时，只要 Connection ID 不变，连接就不会断开，无需重新握手。
  1. 兼容 HTTP/2 特性
    • 保留了 HTTP/2 的多路复用、头部压缩（QPACK 算法，HPACK 的升级版）、服务器推送等功能。

解决的问题

  1. 解决了 HTTP/2.0 基于 TCP 的传输层队头阻塞，这是 HTTP/3 最核心的价值。
  2. 解决了 TCP 握手延迟高的问题，尤其是 HTTPS 场景下的连接建立速度。
  3. 解决了 网络切换时的连接稳定性问题，提升移动端等动态网络环境下的体验。

HTTP 状态码的分类及常见状态码的含义？

HTTP 状态码是服务器对客户端 HTTP 请求的响应状态标识，由 3 位数字组成，第一位数字定义了响应的类别，共分为 5 大类。 核心是区分客户端 / 服务器责任：

分类含义常见状态码及场景
1xx信息性响应100：客户端继续发送请求体（常用于大文件上传）；
2xx成功响应200：请求成功；201：资源创建成功（如 POST 新增订单）；204：请求成功，但服务器无数据返回；
3xx重定向301：永久重定向，SEO 友好；302：临时重定向，浏览器不会缓存；304：协商缓存命中，前端性能优化手段；
4xx客户端错误400：请求参数错误，格式不合法；401：未授权，需登录；403：服务器拒绝访问，客户端已认证但权限不足；404：资源不存在；405：请求方法不被允许，如只支持 GET，但使用POST；
5xx服务器错误500：服务器内部错误；502：网关错误，如 Nginx 反向代理失败；503：服务器过载 / 维护，通常是临时的；504：网关超时，等待上游服务器响应超时；

HTTPS 和 HTTP 的区别以及HTTPS 的加密原理？

HTTPS 和 HTTP 的区别

HTTP（超文本传输协议）和 HTTPS（超文本传输安全协议）的本质差异在于是否通过加密保障传输安全，具体区别如下表：

对比维度HTTPHTTPS
传输安全性明文传输，数据可被劫持、篡改、窃听加密传输，数据全程保密，防篡改
协议基础直接基于 TCP/IP 协议HTTP + SSL/TLS 加密层
默认端口80443
证书要求无需证书需要 CA（证书颁发机构）颁发的数字证书
性能消耗无额外加密开销，速度快握手阶段有加密运算，略耗性能（可通过优化缓解）
浏览器信任地址栏无标识，风险网站会提示地址栏显示锁形图标，支持 HTTP/2 等高效协议

简单来说：HTTPS 就是 “加密版的 HTTP” ，通过在 HTTP 和 TCP 之间增加 SSL/TLS 层，解决了 HTTP 明文传输的安全漏洞。

HTTPS 的加密原理

HTTPS 并非单一加密方式，而是结合了 非对称加密、对称加密 和 数字证书 三种技术，既保证了安全，又兼顾了传输效率，核心流程分为 SSL/TLS 握手阶段 和 数据传输阶段。

核心概念铺垫

在理解流程前，先明确两个加密方式的特点：

  1. 对称加密
    • 特点：加密和解密用同一把密钥，运算速度快，适合大量数据传输。
    • 缺点：密钥一旦泄露，整个通信就会被破解；密钥传输过程本身存在安全风险。
  1. 非对称加密
    • 特点：有一对密钥 ——公钥（公开给所有人）和私钥（服务器自己保存）。
    • 公钥加密的数据，只有私钥能解密；私钥加密的数据，只有公钥能解密。
    • 缺点：运算速度慢，不适合大量数据传输。

HTTPS 完整加密流程（SSL/TLS 握手 + 数据传输）

  1. 客户端发起 HTTPS 请求浏览器向服务器发送请求，同时携带自己支持的 SSL/TLS 版本、加密算法列表。
  2. 服务器返回数字证书和公钥， 服务器选择合适的加密算法，然后向客户端返回核心内容：
    • 服务器的公钥（包含在数字证书中）
    • 数字证书：由 CA 机构颁发，包含服务器域名、公钥、CA 机构的签名等信息。
  1. 客户端验证数字证书的有效性这一步是为了防止中间人攻击，浏览器会做两件事：
    • 验证证书是否由可信的 CA 机构颁发，证书是否过期，证书中的域名是否和当前访问的域名一致。
    • 通过 CA 机构的公钥验证证书上的签名，确保证书没有被篡改，从而确认证书中的公钥确实属于目标服务器。
    • 若验证失败，浏览器会提示 “网站证书不安全”；验证通过则继续下一步。
  1. 客户端生成对称密钥并加密传输客户端生成一个随机的对称密钥（后续数据传输的核心密钥），然后用服务器的公钥对这个对称密钥进行加密，发送给服务器。
    • 这里用非对称加密的原因：只有服务器的私钥能解开这个密文，确保对称密钥在传输过程中不会被窃取。
  1. 服务器解密获取对称密钥服务器用自己的私钥解密客户端发送的密文，得到客户端生成的对称密钥。
  2. 双方用对称密钥进行数据传输握手阶段结束，后续客户端和服务器之间的所有 HTTP 数据，都用同一把对称密钥进行加密和解密。
    • 这里用对称加密的原因：运算效率高，能支撑大量数据的快速传输。

加密设计思路

用非对称加密解决对称密钥的安全传输问题，用对称加密解决大量数据的高效传输问题，所以 HTTPS 只在 SSL/TLS 握手阶段 用非对称加密传输对称密钥，后续的数据传输阶段 全程用对称加密。两者结合实现 “安全 + 高效” 的平衡。

不全程用 非对称加密 的核心原因：性能差距

  • 非对称加密（如 RSA、ECC）的算法复杂度高，运算速度慢，若全程用它传输数据，会导致网页加载、接口请求的延迟大幅增加，尤其对前端来说，会直接影响用户体验。
  • 对称加密（如 AES）的运算速度是非对称加密的 数百倍甚至上千倍，适合处理 HTTP 传输的大量数据（如 HTML、CSS、图片资源等）。

密钥交换流程

数字证书保证了 “客户端拿到的公钥是真实服务器的”，避免了公钥被中间人篡改的风险。

  • 客户端向服务器请求证书，验证通过后，用服务器公钥加密一个随机生成的会话密钥，发送给服务器；
  • 服务器用自己的私钥解密，获取会话密钥；
  • 后续的所有数据传输，都使用这个会话密钥进行 对称加密；

哈希验证保障数据完整性，防篡改

数字证书结合哈希算法，可以验证传输数据是否被篡改

  • 服务器在传输数据时，会先对数据生成一个哈希值，并用私钥对这个哈希值进行签名（生成 “数字签名”）；
  • 客户端收到数据和数字签名后，用服务器公钥验证签名：
    • 若验证通过，说明数据在传输过程中没有被篡改；
    • 若验证失败，说明数据已被篡改，客户端会拒绝接收。

关键补充：数字证书的作用

很多人会疑惑 “为什么不直接用非对称加密传输数据？” 或者 “公钥被篡改了怎么办？”

  • 非对称加密效率低，大量数据传输会拖慢速度，因此只用来传输对称密钥这个 “小数据”。
  • 数字证书的核心作用是：证明服务器公钥的合法性，避免公钥被中间人篡改 —— 因为 CA 机构是可信的第三方，只有它能给证书签名。

GET 和 POST 请求的区别？

GET 和 POST 是 HTTP 协议中最常用的两种请求方法，二者在参数传递、用途、安全性、幂等性等多个维度存在核心区别，以下是详细对比

维度GETPOST
参数位置拼接在 URL 中（query 字符串）， 格式为 URL?key1=value1&key2=value2放在请求体（body）中，不会暴露在 URL 里， 请求体支持多种格式（application/json、application/x-www-form-urlencoded、multipart/form-data 等）。
长度限制受浏览器 / 服务器 URL 长度限制， 一般为 2KB~8KB，无法传递大量数据无明确长度限制，取决于服务器配置，适合传递大量数据
缓存可被浏览器缓存（默认），可以通过设置请求头禁用缓存默认不缓存，每次请求都会触发服务器的新处理逻辑
语义从服务器获取资源（幂等）向服务器提交资源（非幂等）
安全性明文暴露参数，安全性低参数在 body，相对更安全，但仍可以通过抓包工具查看。（若传递敏感信息，需结合 https 协议加密传输）

补充：幂等性 → 多次执行相同请求，结果一致。

  • GET 是幂等的（多次获取同一资源结果相同），不会改变服务器状态和资源；
  • POST 非幂等（多次提交可能创建多个资源，如订单），会修改服务器状态和资源；

Cookie、Session、Token 的区别是什么？

Cookie、Session、Token 是 Web 开发中身份认证与状态保持的核心技术，三者的核心差异体现在 存储位置、工作机制、状态性、安全性 等方面。

核心区别

特性CookieSessionToken（如 JWT）
存储位置客户端（浏览器）服务端（内存 / Redis）客户端（Storage / 文件）
状态性客户端状态服务端状态无状态
容量限制约 4KB，数量有限无明确限制无明确限制（建议精简）
传输方式自动携带在请求头依赖 Cookie 传递 ID手动放在请求头 / 体
分布式支持不支持（依赖客户端）需 Session 共享（如 Redis）天然支持（无状态）
跨域支持弱（受同源策略限制）弱（依赖 Cookie）强（不依赖 Cookie）
安全性中等（需配置 HttpOnly/Secure）较高（数据在服务端）较高（依赖加密签名）
服务器资源占用无有（存储 Session 数据）无（不存储）

Cookie

客户端（浏览器）存储的小型文本文件，由服务器生成，通过响应头 Set-Cookie 下发给浏览器，浏览器会自动保存，并在后续同域名请求中携带 Cookie 到服务端。

核心特点

  • 存储位置：客户端（浏览器内存或本地文件）。
  • 容量限制：单个 Cookie 最大约 4KB，一个域名下最多存储几十条 Cookie。
  • 生命周期：可通过 expires 或 max-age 设置过期时间；若不设置，默认是会话级 Cookie（浏览器关闭即失效）。
  • 安全性：可配置 HttpOnly: true 防止 JS 读取，避免 XSS 攻击；配置 Secure: true 仅在 HTTPS 下传输；配置 SameSite 防止 CSRF 攻击。

工作流程

  1. 用户首次请求服务器 → 服务器生成 Cookie（含用户标识等信息），通过响应头下发。
  2. 浏览器保存 Cookie → 后续请求时，自动在请求头 Cookie 中携带该数据。
  3. 服务器解析 Cookie，识别用户身份。

Session

服务器端的会话存储机制，用于保存用户的会话状态（如登录信息、购物车数据）。服务器会为每个用户会话分配唯一的 Session ID，并通过 Cookie 或 URL 参数传递给客户端。

核心特点

  • 存储位置：服务端（内存、数据库、Redis 等）。
  • 容量限制：无明确限制，取决于服务端存储能力。
  • 生命周期：默认随服务器会话失效（如 Tomcat 默认 30 分钟无操作过期），可手动配置。
  • 安全性：数据存储在服务端，相对更安全；但 Session ID 若泄露，攻击者可伪造请求（需配合 SameSite 等防护）。

工作流程

  1. 用户首次登录 → 服务器创建 Session 对象，生成唯一 Session ID。
  2. 服务器通过 Set-Cookie 将 Session ID 下发给浏览器，浏览器保存。
  3. 后续请求时，浏览器携带 Session ID → 服务器根据 ID 找到对应的 Session 数据，识别用户。
  4. 注意：Session 依赖 Cookie 传递 Session ID，若用户禁用 Cookie，需通过 URL 重写（如 url?jsessionid=xxx）实现，但安全性降低。

Token

服务端生成的加密字符串凭证，用于标识用户身份，常见形式有 JWT（JSON Web Token） 、OAuth2.0 Token 等，核心是无状态认证。

核心特点

  • 存储位置：客户端（浏览器 localStorage/sessionStorage 或本地文件）。
  • 状态性：无状态，服务端不存储 Token 数据，仅通过加密算法验证 Token 有效性。
  • 传输方式：通常放在请求头（如 Authorization: Bearer <token>），也可放在请求体或 URL（不推荐）。
  • 安全性：依赖签名 / 加密（如 JWT 的 HS256/RSA 签名），防止篡改；Token 可设置过期时间，泄露后风险可控。
  • 跨域 / 分布式友好：不依赖 Cookie，天然支持跨域请求；服务端无需存储，适合分布式集群（无需 Session 共享）。

工作流程（以 JWT 为例）

  1. 用户登录 → 服务端验证账号密码后，生成 JWT（包含 Header、Payload、Signature 三部分），返回给客户端。
  2. 客户端保存 JWT（如 localStorage）。
  3. 后续请求时，客户端在请求头携带 JWT → 服务端验证签名和过期时间，解析 Payload 中的用户信息，完成认证。

适用场景

  • Cookie：适合简单的状态保持，如记住登录状态、保存用户偏好（如主题设置）。
  • Session：适合服务端需要严格控制会话的场景，如银行、电商后台（需实时销毁会话）。
  • Token：适合前后端分离、分布式系统、跨域请求场景，如移动端 App、小程序、大型微服务架构。

注意点

  • Session 依赖 Cookie 传递 Session ID，但 Session 不是 Cookie，二者是客户端 - 服务端的配合关系。
  • Token 不一定是 JWT，JWT 是 Token 的一种标准化实现；Token 也可存储在 Cookie 中，但通常不这么做（避免同源限制）。
  • Cookie 有同源策略限制，Token 无此限制，因此更适合跨域认证（如第三方登录）

Cookie 的 HttpOnly、Secure、SameSite 属性分别有什么作用？

Cookie 的 HttpOnly、Secure、SameSite 是三个核心安全属性，分别用于防御不同类型的 Web 攻击，保障 Cookie 在传输和使用过程中的安全性。

HttpOnly

核心作用：禁止 JavaScript 通过 document.cookie 访问该 Cookie，仅允许 HTTP/HTTPS 请求在请求头中携带。

防御目标：主要抵御 XSS（跨站脚本攻击）。

  • XSS 攻击的常见手段是注入恶意脚本，窃取用户的 Cookie 信息（通过 document.cookie 获取），进而冒充用户身份。
  • 当 Cookie 标记为 HttpOnly 后，前端 JS 无法读取或修改该 Cookie，恶意脚本也就无法窃取，从根源上切断了 XSS 攻击窃取 Cookie 的路径。

注意点

  • 该属性不影响 HTTP/HTTPS 请求携带 Cookie，服务器依然能正常接收和处理。
  • 可以和 Secure、SameSite 同时配置。

Secure

核心作用：强制 Cookie 仅在 HTTPS 协议下传输，HTTP 协议的请求不会携带该 Cookie。

防御目标：防止 Cookie 在传输过程中被窃听、篡改（比如在公共 WiFi 等不安全网络环境下的中间人攻击）。

  • HTTP 是明文传输，Cookie 会以明文形式暴露在网络中；HTTPS 基于 TLS/SSL 加密，能保障 Cookie 传输的安全性。

注意点

  • 即使 Cookie 设为 Secure，如果未设置 HttpOnly，前端 JS 依然可以通过 document.cookie 访问它。
  • 当 SameSite=None 时，必须同时配置 Secure，否则现代浏览器会拒绝设置该 Cookie。

SameSite

核心作用：限制 Cookie 在跨站请求中的携带策略，核心防御 CSRF（跨站请求伪造） 攻击。

防御目标：CSRF 攻击利用用户的登录状态（Cookie），诱导用户在已登录的情况下发起跨站的恶意请求。SameSite 通过控制跨站请求是否携带 Cookie，阻断这种攻击路径。

三个取值及规则 ：

  • Strict： 最严格，仅同站点请求携带 Cookie。跨站的任何请求（包括链接跳转、表单提交）都不会携带。
  • Lax：宽松模式（现代浏览器默认值），部分跨站 GET 请求允许携带 Cookie，如：链接跳转、预加载请求；POST 请求、AJAX 请求等跨站操作不携带。
  • None： 允许所有跨站请求携带 Cookie，但必须同时配置 Secure 属性，否则浏览器会拒绝设置。

同站点的判断：域名的主域名 + 二级域名相同，且协议、端口一致

  • 比如 a.example.com 和 b.example.com 属于同站点；example.com 和 test.com 属于跨站点。

最后：关于其他考点，比如tcp连接过程，跨域，缓存等，会再单独出一篇浏览器相关的文章，敬请期待

avatar
文章
阅读
粉丝