1. 完整回答
HTTP 是浏览器、移动端和服务器之间传输网页资源及接口数据的应用层协议。它通过请求方法、URL、请求头、响应状态码和响应体来组织通信，采用请求—响应模式，协议本身是无状态的。普通 HTTP 缺少传输加密和身份认证，链路上的攻击者可能读取或篡改数据。
HTTPS 在 HTTP 通信中引入 TLS，主要解决三个问题：防窃听、防篡改、验证服务器身份。以浏览器访问登录接口为例，通常先完成域名解析和 TCP 连接，然后进行 TLS 握手。客户端和服务端协商协议参数、完成临时密钥交换，服务端提供数字证书，浏览器校验证书及服务器身份。双方确认握手成功后，用协商出的对称密钥加密 HTTP 请求和响应。这里的密钥交换以现代 TLS 1.3 为例；它主要通过临时密钥协商建立会话密钥，证书中的公钥主要承担身份认证的作用。
从性能看，HTTP/1.1 支持连接复用，HTTP/2 通过多路复用和头部压缩提高传输效率，HTTP/3 则基于 UDP 上的 QUIC，进一步缓解 TCP 丢包引起的跨请求阻塞，TLS 1.3 也集成在 QUIC 的安全握手中。实际项目里，登录、支付、业务接口和静态资源都应使用 HTTPS，并配合证书维护、HSTS 和安全的 Cookie 配置。HTTPS 保护的是传输过程，服务端漏洞和恶意网页本身仍需要其他安全措施来防范。
2. 核心原理与关键概念
2.1 HTTP 的请求—响应机制
客户端发起请求 → 服务器处理 → 返回状态码、响应头和响应体 → 客户端处理结果。
例如，浏览器使用 GET 获取商品详情，服务器可能返回 200 OK 和 JSON 数据；资源不存在时通常返回 404 Not Found。请求方法表达操作意图，状态码表达处理结果，头部负责描述数据格式、缓存策略、身份凭据等信息。HTTP 本身不记录前一次请求的业务状态，登录态通常依赖 Cookie、Session 或令牌在多次请求之间关联。
2.2 HTTPS 的建立流程（以 TCP + TLS 1.3 为例）
- 域名解析 → TCP 建连：浏览器获取服务器地址并建立 TCP 连接。已有可复用连接时可以省去重复建连。
- ClientHello → ServerHello：双方协商 TLS 版本、加密算法等参数，交换用于临时密钥协商的信息，并据此推导握手密钥。
- 服务器证明身份 → 客户端校验：服务器发送证书及握手签名等信息；浏览器检查可信证书链、域名匹配、有效期，并验证服务器持有相应私钥。
- 握手确认 → 生成应用数据密钥：双方验证握手消息没有被篡改，推导用于保护后续通信的密钥。
- 加密发送 HTTP 请求 → 加密返回响应：采用高效的对称认证加密，同时保护数据的机密性和完整性。
这个流程描述的是首次、完整的 TLS 1.3 握手。TLS 1.2 的握手细节可能不同；HTTP/3 则通过 QUIC 建连并集成 TLS 1.3，不需要先建立 TCP 连接。
2.3 必要的关键概念
| 概念 | 作用 |
|---|---|
| 请求方法与状态码 | 方法说明希望对资源执行什么操作；状态码说明处理结果。 |
| 无状态 | 每个 HTTP 请求在协议语义上独立；业务登录态需要应用层机制维持。 |
| TLS | 为通信提供机密性、完整性和对端身份认证能力。 |
| 数字证书与 CA | 将域名身份与公钥建立可信关联；浏览器通过证书链及服务器签名验证身份。 |
| 临时密钥交换与对称加密 | 前者安全地协商共享秘密，后者高效保护实际的 HTTP 数据。 |
| 多路复用 | 一条连接可以并发承载多个请求，减少重复建连和应用层排队。 |
3. 高频面试追问
3.1 从输入 HTTPS 网址到收到响应，发生了什么？
通常是域名解析 → 建立连接 → TLS 握手 → 发送 HTTP 请求 → 处理响应。浏览器先查询域名对应的地址；使用 HTTP/1.1 或 HTTP/2 时，通常先进行 TCP 三次握手，再协商 TLS 参数并验证服务器证书。安全连接建立后，浏览器发送请求，服务器返回状态码、响应头和数据，浏览器再解析页面并请求其他资源。连接可能被复用，DNS、连接和部分资源也可能命中缓存，所以实际请求未必每次都完整经历这些步骤。HTTP/3 走 QUIC，建连方式不同。
3.2 HTTPS 为什么同时用到非对称密码技术和对称加密？
**因为密钥协商和大规模数据传输的需求不同。**在 TLS 1.3 中，双方通常使用 ECDHE 这样的临时密钥交换机制得到共享秘密，再推导出应用数据密钥；服务器使用证书对应的私钥完成身份认证。真正传输请求头、Cookie、响应体时，采用 AES-GCM 或 ChaCha20-Poly1305 等对称认证加密算法，效率更高，还能检测数据是否被篡改。直接拿证书公钥加密整个 HTTP 报文，既不符合现代 TLS 的主流流程，性能也不合适。
3.3 浏览器如何判断证书可信？能否防止中间人攻击？
**证书校验是防止服务器被冒充的关键。**浏览器会检查证书链能否连接到受信任的根证书、访问域名是否匹配、证书是否在有效期内，并按浏览器和平台策略进行其他检查。TLS 握手还会验证服务器是否持有证书对应的私钥。攻击者即使拦截网络流量，通常也无法伪造完整的身份验证和握手证明。
继续追问：自签名证书能用于 HTTPS 吗？
可以建立加密连接，但默认情况下浏览器通常不会信任它。企业内网可以把自建 CA 纳入受信任根证书列表；对公众网站一般应使用受信任 CA 签发的证书。忽略证书错误会削弱身份认证的意义。
3.4 TLS 1.2 和 TLS 1.3 有什么主要区别？
**TLS 1.3 的改进集中在安全性和握手延迟。**它移除了许多过时算法和旧式 RSA 密钥传输方式，常规完整握手通常只需约 1 个网络往返时延，而典型 TLS 1.2 完整握手通常需要约 2 个。TLS 1.3 还支持基于先前会话的恢复；在符合条件时，客户端可以发送 0-RTT 早期数据。
继续追问：0-RTT 可以直接用于支付或下单请求吗？
一般不建议。0-RTT 早期数据存在重放风险，更适合服务端能安全处理重复执行的请求。支付、下单等状态变更操作应避免直接使用早期数据，并在业务层做好幂等控制。
3.5 HTTPS 加密了哪些信息？用了 HTTPS 就绝对安全吗？
**HTTPS 能保护 TLS 连接里的 HTTP 请求和响应，包括 URL 路径、查询参数、请求头、Cookie 和正文。**但传输过程中，目标 IP、流量大小和时间等元数据通常仍可观察；域名也可能通过普通 DNS 查询或未加密的 SNI 暴露，具体取决于部署方式。TLS 在代理或 CDN 处终止时，终止节点能看到解密后的内容。因此 HTTPS 并不能替代输入校验、权限控制和防 XSS 等措施，也不能证明一个网站本身没有恶意内容。
3.6 HTTP/1.1、HTTP/2、HTTP/3 为什么不断演进？
**主要为了解决连接利用率和高延迟、丢包环境下的性能问题。**HTTP/1.1 默认使用持久连接，但同一连接上的响应存在顺序约束，浏览器通常通过多条连接并发请求。HTTP/2 引入二进制分帧、多路复用和头部压缩，一条 TCP 连接可以并发处理多个请求，但 TCP 丢包仍可能阻塞同一连接内的其他流。HTTP/3 把传输层改为基于 UDP 的 QUIC，不同流可以独立推进，减少跨流队头阻塞；不过同一流内的顺序约束和网络拥塞仍然存在。三个版本的 HTTP 方法和状态码语义基本一致。
3.7 HTTP 无状态，为什么又有长连接和登录状态？
**无状态、长连接和登录状态属于不同层面。**HTTP 无状态指协议不会自动把前后两次请求关联成同一个业务会话；长连接是传输层连接可以被反复使用，减少建连开销；登录状态由应用通过 Cookie、Session 或令牌等机制实现。比如用户登录后，浏览器在后续请求中携带会话 Cookie，服务器据此识别用户。即使这些请求共用一条 TCP 连接，HTTP 的无状态特性也没有改变。
3.8 GET 和 POST 有什么区别？幂等性如何理解？
**GET 主要用于获取资源，按协议语义应当安全、幂等；POST 用于提交数据，其操作通常可能产生状态变化，默认不保证幂等。**幂等指相同请求执行一次和多次，对目标资源产生的预期效果相同，例如重复 PUT 同一份资源内容。它不代表返回码必须相同。GET 的参数经常出现在 URL 中，但不能简单以“GET 走 URL、POST 走请求体”作为协议边界。对支付、下单一类 POST 接口，我会通过幂等键、唯一业务流水号等机制避免重复处理。
3.9 HTTP 缓存是怎么工作的？HTTPS 会影响缓存吗？
HTTP 缓存主要靠响应头控制，HTTPS 仍然可以正常使用浏览器缓存和 CDN 缓存。响应带有 Cache-Control: max-age 等信息时，客户端可在内容新鲜期间直接复用缓存；过期后可以携带 If-None-Match 或 If-Modified-Since 做条件请求。资源没有变化，服务器通常返回 304 Not Modified，客户端继续使用已有内容。no-cache 允许存储，但复用前需要重新验证；no-store 要求缓存不要存储。用户私有数据应额外考虑 private 和敏感信息防缓存策略。
3.10 项目里如何把 HTTP 平稳切换为 HTTPS？
我会先保证证书和整条业务链路可用，再做全站升级。部署有效证书、配置 TLS 版本和自动续期后，把 HTTP 请求重定向到 HTTPS，检查图片、脚本、接口是否存在混合内容，并给登录 Cookie 设置 Secure、HttpOnly 和合适的 SameSite。如果前面有负载均衡器或 CDN，还要确认它与源站之间的连接是否得到适当保护。最后观察证书过期告警、重定向循环和握手失败，再逐步启用 HSTS；HSTS 已生效后，浏览器会直接优先使用 HTTPS，减少明文降级风险。
继续追问：301、302 和 307、308 重定向有什么差别？
301、308 表示永久重定向，302、307 表示临时重定向。307 和 308 要求保留原请求方法及请求体；301 和 302 在浏览器处理 POST 时可能转为 GET。页面级 HTTP 升级常见 301；需要严格保留接口请求方法时，应考虑 307 或 308，同时确认客户端兼容性。
4. 易混淆概念对比
4.1 HTTP 与 HTTPS
| 维度 | HTTP | HTTPS |
|---|---|---|
| 传输保护 | 通常明文，无内置 TLS 保护 | 通过 TLS 或集成 TLS 的 QUIC 保护传输 |
| 身份认证 | 无内置服务器证书校验 | 通常用证书验证服务器身份 |
| 默认端口 | 80 | 443 |
| 主要用途 | 非敏感的受控测试环境等 | 互联网网页、接口、登录、支付等 |
| 共同点 | 使用 HTTP 的请求方法、状态码等语义 | 使用相同的 HTTP 应用语义 |
4.2 密钥交换、数字签名、对称加密
| 机制 | 在现代 HTTPS 中的角色 | 解决的问题 |
|---|---|---|
| ECDHE 等临时密钥交换 | 双方协商共享秘密并推导密钥 | 避免直接传输会话密钥，并支持前向保密 |
| CA 证书与服务器数字签名 | 建立域名、公钥与服务器身份的可信关联 | 降低服务器被冒充的风险 |
| 对称认证加密 | 加密 HTTP 数据，并校验完整性 | 高效防窃听、防篡改 |
4.3 HTTP/1.1、HTTP/2、HTTP/3
| 维度 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 底层传输 | TCP | TCP | QUIC（基于 UDP） |
| 并发方式 | 常通过多条连接并发 | 单连接多路复用 | 多条 QUIC 流并发 |
| 头部传输 | 文本格式 | 二进制帧、HPACK 压缩 | 二进制帧、QPACK 压缩 |
| 阻塞特点 | 同一连接有响应顺序约束 | 消除了 HTTP 层的跨请求顺序阻塞，仍受 TCP 丢包影响 | 缓解跨流丢包阻塞，单流和拥塞约束仍在 |
| HTTPS 的关系 | 可运行在 TLS 上 | 浏览器中通常使用 TLS | QUIC 集成 TLS 1.3 |
4.4 HTTP 无状态与 HTTP 长连接
| 概念 | 关注点 | 示例 |
|---|---|---|
| 无状态 | 多次请求之间的业务上下文不会由 HTTP 自动保存 | 登录后依靠 Cookie 或令牌识别用户 |
| 长连接 | 一条底层连接能否处理多次请求 | HTTP/1.1 默认支持持久连接 |
二者可以同时成立：一条连接可以复用很多次，但请求之间的业务状态仍需应用维护。
5. 总结
HTTP 是客户端和服务器通过请求、响应交换资源与接口数据的应用层协议，核心特点是请求—响应和无状态。HTTPS 为 HTTP 通信增加 TLS 安全保护，通过证书验证服务器身份、通过密钥协商建立加密密钥，再用对称认证加密保护数据的机密性和完整性。HTTP/1.1、HTTP/2 和 HTTP/3 的主要变化在于传输效率：HTTP/2 支持多路复用，HTTP/3 基于 QUIC 缓解跨流丢包阻塞。项目里一般会全站使用 HTTPS，配合证书续期、HSTS 和安全 Cookie。不过 HTTPS 主要负责传输安全，业务权限、XSS 和服务端漏洞还需要单独处理。