一口三个馍

Appearance

HTTP 与 HTTPS 协议 ​

❓ 面试官：在浏览器输入 URL 到页面显示，经历了什么过程？ ​

频率：🔥🔥🔥🔥🔥

💡 一句话总结（先抛结论）： 这是一个从网络寻址、建立连接、数据传输到浏览器渲染的完整链路过程。

📝 详细步骤解析：

  1. DNS 解析：浏览器先查看本地缓存，没有的话找本地 host 文件，再找本地 DNS 服务器，一层层把域名（如 www.baidu.com）解析成真实的 IP 地址。
  2. TCP 连接：拿到 IP 后，浏览器通过 TCP 的三次握手与服务器的 80（HTTP）或 443（HTTPS）端口建立连接。
  3. HTTPS 的 TLS 握手（如果是 HTTPS）：进行加密协议的握手，验证服务器证书，协商对称加密的密钥。
  4. 发送 HTTP 请求：浏览器组装 HTTP 请求报文（请求行、请求头、请求体）发送给服务器。
  5. 服务器处理：后端（如 SpringBoot、Nginx）接收请求，执行业务逻辑，返回 HTTP 响应报文（状态码、响应头、响应体 HTML）。
  6. 浏览器渲染：浏览器拿到 HTML，解析 DOM 树、CSSOM 树，合并成渲染树，进行布局（Layout）和绘制（Paint），最终展示给用户。
  7. 连接关闭：如果是 HTTP/1.0 且没有 Keep-Alive，直接四次挥手断开。现代 HTTP/1.1 默认 Keep-Alive 会保持连接一段时间。

❓ 面试官：常见的 HTTP 状态码有哪些？502 和 504 有什么区别？ ​

频率：🔥🔥🔥🔥

💡 一句话总结（分类记忆）： 1xx（信息），2xx（成功），3xx（重定向），4xx（客户端错误），5xx（服务端错误）。

📝 核心高频状态码：

  • 200 OK：请求成功。
  • 301 Moved Permanently：永久重定向。比如旧域名作废，SEO 搜索引擎会更新地址。
  • 302 Found：临时重定向。比如未登录用户访问后台，被临时跳转到登录页。
  • 400 Bad Request：前端传的参数类型或格式不对，后端 Spring 抛了异常。
  • 401 Unauthorized：未授权，没带 Token 或者 Token 错误。
  • 403 Forbidden：禁止访问，有 Token 但权限不够。
  • 404 Not Found：请求的接口路径写错了。
  • 500 Internal Server Error：后端代码报 NullPointerException 等未捕获异常了。

🌟 追问：502 和 504 的区别？（实战经验） 这两者通常发生在使用 Nginx 做反向代理的架构中。

  • 502 Bad Gateway（网关错误）：Nginx 转发请求给后端的 Tomcat，但 Tomcat 挂了（进程死了、端口不通），Nginx 连接不上后端，就会返回 502。
  • 504 Gateway Timeout（网关超时）：Nginx 连接上了 Tomcat，但 Tomcat 处理这个请求太慢了（比如慢 SQL 查了 30 秒），超过了 Nginx 配置的超时时间，Nginx 等得不耐烦了，主动断开并返回 504。

❓ 面试官：GET 和 POST 的区别是什么？ ​

频率：🔥🔥🔥

💡 常见“八股文”回答（表层）：

  • GET 参数放在 URL 后面，POST 参数放在请求体（Body）里。
  • GET 参数有长度限制（受浏览器和服务器限制），POST 没有。
  • GET 是不安全的（密码会被看到），POST 相对安全。

🌟 高分回答（深入底层与 RESTful 语义）： “除了表面的不同，它们最本质的区别在于语义和幂等性。”

  • 语义上：GET 用于获取数据，POST 用于提交数据（新建资源）。
  • 幂等性上：GET 请求是幂等的（不管请求多少次，服务端的资源状态都不变）。POST 是非幂等的（每次提交可能都会产生一条新订单）。
  • 缓存机制：因为 GET 是只读和幂等的，浏览器和 CDN 默认会主动缓存 GET 请求的结果；而 POST 请求默认不会被缓存。
  • 底层网络（TCP层，加分项）：绝大多数浏览器发送 GET 时，会把 Header 和 Data 放在一个 TCP 数据包里发送；而有些老版本的浏览器发送 POST 时，会先发 Header（收到 100 Continue 响应后），再发 Data 数据包。

❓ 面试官：HTTPS 为什么安全？它是如何加密的？（对称加密与非对称加密） ​

频率：🔥🔥🔥🔥🔥

💡 一句话总结（先抛结论）： HTTPS 在 HTTP 和 TCP 之间加了一层 SSL/TLS 层。它使用非对称加密来协商出一个安全的密钥，然后再用这个安全的密钥去进行对称加密传输真正的数据。这种“混合加密”既保证了绝对安全，又保证了传输速度。

📝 详细加密握手过程（非常核心）：

  1. 客户端向服务器索要公钥。
  2. 服务器返回自己的数字证书（包含了服务器的公钥和权威机构 CA 的签名）。
  3. 客户端用操作系统里内置的 CA 根证书，验证这个数字证书的真伪。确认没被篡改后，提取出里面的公钥。
  4. 客户端自己随机生成一个“对称加密的密钥（随机数）”。
  5. 客户端用刚才拿到的公钥，把这个随机数加密，发给服务器。（非对称加密的特性：只有服务器的私钥能解开，黑客截获了也没用）。
  6. 服务器收到后用自己的私钥解密，得到了这个“对称加密密钥”。
  7. 大功告成：现在双方都有了相同的“对称加密密钥”。接下来所有的 HTTP 业务数据，都用这个对称密钥进行极速的加解密传输。

🌟 为什么不一直用非对称加密？ 因为非对称加密的算法极其复杂，如果在每次传输业务图片、JSON 数据时都用它，会导致 CPU 爆炸，网页加载极其缓慢。所以非对称加密只在刚建连阶段用来交换“钥匙”，后面大量的数据传输用轻量级的对称加密。