面试备战录

菜市口的跳脚长颌
56 阅读5分钟

1、HTTP 和 HTTPS 的区别？HTTPS 是如何保障安全通信的？

答：HTTP是明文传输，容易被窃听/篡改/伪造；HTTPS在HTTP上加入了TLS/SSL，通过“证书验证 + 非对称加密协商密钥 + 对称加密传输“，实现了机密性、完整性和身份认证，从而保障安全通信。

HTTP vs HTTPS 的区别

  • 端口：HTTP默认 80；HTTPS默认 443。
  • 安全性：HTTP明文传输，容易被窃听、篡改、伪造；HTTPS加密传输（SSL/TLS），防止窃听、篡改、伪造。
  • 证书：HTTP不需要证书；HTTPS需要数字证书（CA 签发）
  • 性能：HTTP较快（无加密/握手开销）；HTTPS较慢（TLS 握手、加密开销，但现代优化后差异不大）
  • 应用场景：HTTP一般只用于内网或测试；HTTPS几乎所有生产环境网站都要求HTTPS（尤其Chrome已强制提示HTTP不安全）

HTTPS 是如何保障安全通信的？

  • HTTPS = HTTP + TLS/SSL，主要提供 3 个保障：
    • 加密通信（防窃听）
      • 使用**对称加密（如 AES）**加密真正的数据内容；
      • 防止第三方（黑客、中间人）在网络上直接读取明文。
    • 完整性校验（防篡改）
      • 数据传输时附带 消息摘要（MAC/Hash）；
      • 接收方能验证数据是否被中途篡改。
    • 身份验证（防伪造）
      • 通过**数字证书（CA 签发）**验证服务器身份；
      • 确保客户端连接的真的是目标网站，而不是中间人伪装的。

HTTPS 握手过程（简化版 TLS 1.2/1.3）

  • 客户端发起请求（ClientHello）：告诉服务端：我支持哪些加密算法、TLS 版本。
  • 服务端响应（ServerHello + 证书）：选择加密算法；下发服务器的数字证书（包含公钥、公信 CA 签名）。
  • 客户端验证证书：检查证书是否有效（CA 签发/未过期/域名匹配）；确认服务器身份。
  • 密钥协商：客户端生成一个随机的“对称密钥”；用服务器公钥加密后发给服务器（或用 DH/ECDH 算法协商）；之后双方就用这个对称密钥加密通信（性能更好）。
  • 加密通信开始：双方都拥有相同的对称密钥，后续所有 HTTP 内容都加密传输。

优点：

  • 窃听无效：数据被加密，第三方只能看到乱码；
  • 篡改无效：有完整性校验，一改就能检测到；
  • 伪造无效：数字证书由权威 CA 签发，攻击者无法伪造合法证书。

2、浏览器缓存机制强缓存（Cache-Control / Expires）与协商缓存（ETag / Last-Modified）的区别

答：强缓存（Cache-Control / Expires）

  • 核心思想：直接用本地缓存，不跟服务器通信。
  • 触发条件：响应头有Cache-Control（优先级更高）或Expires
  • 过程：
    • 浏览器第一次请求资源 → 服务器返回资源，并带上缓存策略
    Cache-Control: max-age=3600
Expires: Wed, 27 Aug 2025 12:00:00 GMT
    • 之后在有效期内，浏览器请求相同资源时，直接使用本地缓存，不发请求。
  • 特点：
    • 快速（0 RTT，不走网络）
    • 可能过期不准（比如服务器更新了资源，但本地缓存还没过期 → 脏缓存问题）

协商缓存（ETag / Last-Modified）

  • 核心思想：浏览器问服务器“缓存还能用吗？”。
  • 触发条件：浏览器缓存过期，或者 Cache-Control: no-cache
  • 过程：
    • 浏览器带上验证字段请求：If-Modified-Since（对应Last-Modified）；If-None-Match（对应ETag）
    • 服务器判断：未修改 → 返回304 Not Modified，浏览器继续用本地缓存；已修改 → 返回新资源 + 新的ETag/Last-Modified
  • 特点：
    • 一定要发请求（比强缓存慢一些）
    • 不会有脏缓存问题

优化策略：强缓存 + 协商缓存组合拳

  • 对于静态资源，配合 文件名hash（比如app.12345.js），设置强缓存很长时间（Cache-Control: max-age=31536000, immutable）
  • 对于接口数据，通常用协商缓存，保证一致性

3、TCP 三次握手和四次挥手分别做了什么？为什么需要三次？

答：三次握手：保证双方能收能发，避免旧连接误触发；四次挥手：因为TCP是全双工，关闭要分“我先关、你再关”，所以需要 4 步。

**TCP 三次握手 (建立连接)**目的是：让双方都确认“自己能发、能收”，避免出现“半开连接”。

  • 第一次握手：
    • 客户端 → 服务端：发送一个SYN 报文（同步序号），告诉服务端：我要建立连接了，我的初始序号是 x。
    • 服务端收到了，知道了：客户端能发消息
  • 第二次握手：
    • 服务端 → 客户端：回一个SYN + ACK 报文，表示：
      • 我同意建立连接；
      • 这是我的初始序号 y；
      • 同时确认收到了你 x 的请求。
    • 客户端 收到了，知道了：服务端能收消息、能发消息
  • 第三次握手：
    • 客户端 → 服务端：再发一个ACK报文，确认收到了服务端的 y。
    • 服务端 收到了，知道了：客户端也能收消息。

为什么要三次，而不是两次？

  • 如果只用 两次握手：
    • 假设网络里有一个延迟的旧 SYN 报文突然到达服务端，服务端就会误以为客户端要建立新连接，发回 SYN+ACK，导致资源浪费（半开连接）。
    • 第三次握手的作用：客户端必须再确认一次，确保这是一个真正的、最新的连接请求。
  • 三次握手是最少保证“双方状态都正确”的次数。

TCP 四次挥手 (断开连接)目的是：双方都要单独关闭自己的发送方向。因为TCP是全双工，发送和接收要分别关闭。

  • 第一次挥手：客户端 → 服务端：发送FIN，表示我已经没有数据要发了（我这边的“发送通道”关闭了）。
  • 第二次挥手：
    • 服务端 → 客户端：回一个ACK，确认收到了。
    • 但此时服务端可能还有数据没发完，所以服务端的“发送通道”还开着。
  • 第三次挥手：
    • 服务端 → 客户端：等服务端数据发完了，发送FIN，告诉客户端我也没有数据要发了。
  • 第四次挥手：
    • 客户端 → 服务端：发送ACK，确认收到了。
    • 客户端进入TIME_WAIT状态（一般等2 * MSL时间），确保服务端收到了最后的确认。
avatar
文章
阅读
粉丝