Skip to main content
Version: Next

经典大题详解（面试前必练）

3.1 浏览器输入 URL，按下回车，全过程（经典大题，必练）​

完整答题框架（层次清晰是关键）：

  1. URL 解析与预处理：浏览器解析 URL（协议、域名、端口、路径）；检查 HSTS 列表决定是否强制 HTTPS；有缓存则先走缓存判断（见 4.3）。
  2. DNS 解析：浏览器缓存 → 系统缓存 / hosts → 本地 DNS 递归查询（根 → 顶级域 → 权威）→ 拿到目标 IP；CDN 域名会先被 CNAME 调度到最近的边缘节点。
  3. 建立连接：
    • TCP 三次握手（SYN → SYN+ACK → ACK）；
    • 若是 HTTPS，再进行 TLS 握手（证书验证 + 密钥协商，见 4.6；HTTP/3 则是 QUIC 0/1-RTT）。
  4. 发送 HTTP 请求：浏览器构建请求行（方法、路径）、请求头（Host、Cookie、User-Agent、Cache-Control 等）、请求体，交给 TCP 分段发送。
  5. 服务端处理：流量经过 LVS（四层）→ Nginx（七层分流、TLS 卸载）→ 后端应用（业务逻辑、读写数据库/缓存）→ 组装响应（状态码、响应头、响应体）。
  6. 浏览器渲染：解析 HTML 构建 DOM 树、解析 CSS 构建 CSSOM、合成渲染树 → 布局（Layout）→ 绘制（Paint）；遇到 JS/CSS/图片等子资源再次发起请求（并行连接）；JS 执行可能阻塞解析（async/defer 优化）。
  7. 连接收尾：Keep-Alive 长连接复用；空闲超时或主动关闭时四次挥手。

加分项：提到强缓存/协商缓存的判断、CDN、301/302 重定向循环、HTTP/2 多路复用对渲染的影响、渲染管线细节。

3.2 ping 域名能通，但 curl 访问不通，排查思路​

先分析结论：ping 通说明 ICMP 通 + DNS 解析正常 + 三层路由正常，问题一定在四层及以上。

排查步骤：

  1. 测端口：telnet 目标IP 端口 或 nc -zv 目标IP 端口：
    • 端口不通 → 依次检查：
      • 服务是否监听：ss -tulnp（注意监听地址：绑定 127.0.0.1 时外部访问不到，应绑定 0.0.0.0）；
      • 防火墙 / 云安全组是否放行该端口（最常见原因）；
      • 中间 LB 的健康检查是否把后端摘除。
  2. 端口通了但 HTTP 报错 → 看返回码分层处理：
    • curl -v 看完整请求/响应过程；
    • 403：权限/黑名单/WAF 拦截、Nginx deny 规则；
    • 404：路径配错、Nginx root/proxy_pass 配置错误；
    • 502/504：网关到后端的问题（后端挂了 / 后端超时）；
    • 继续查应用日志（error log）、Nginx access/error log。
  3. 连 TLS 都失败：证书过期/不匹配、协议版本或加密套件不兼容。

3.3 服务大量 CLOSE_WAIT，原因和处理​

原因（本质：对端已关闭，我方应用没有调用 close()）：

  • 代码 Bug：异常分支漏关连接、连接池归还逻辑缺陷、finally 缺失；
  • 线程池/协程池打满，连接一直排队没被处理；
  • 响应处理完但未正确关闭（未走完整请求-响应周期）。

排查：ss -tanp | grep CLOSE_WAIT（或 netstat）统计并定位进程 PID → lsof -p PID 看句柄数是否持续增长 → 代码审查连接释放路径。

处理：修复代码（try/finally 确保关闭、修复连接池逻辑）→ 必要时临时重启缓解（治标）→ 需要开发一起处理，纯运维手段无法根治。

3.4 TCP 拥塞控制什么时候起作用？​

标准答案：发送方的实际发送窗口 = min(rwnd, cwnd)：

  • rwnd（接收窗口）：由接收方通告——接收缓冲区不足时变小，这是流量控制，保护「接收方」；
  • cwnd（拥塞窗口）：由发送方根据网络状况动态调整——出现丢包（3 个重复 ACK）或超时时减小、网络空闲时增长，这是拥塞控制，保护「网络」；
  • 两者取小者生效：接收方慢则流量控制主导，网络拥塞则拥塞控制主导。

3.5 Nginx 和 LVS 区别，什么时候选哪个？​

区别一句话：LVS 工作在四层（传输层，只看 IP + 端口，内核态转发，性能极高）；Nginx 工作在七层（应用层，解析 HTTP，能识别 URL、Host、Cookie 做内容分流）。

选 LVS：大流量高并发、追求极致性能、转发非 HTTP 协议（MySQL、Redis、K8s Service 等）。

选 Nginx：需要按 URL / Host / Cookie 分流、需要 HTTPS 加解密卸载、需要缓存压缩限流等应用层能力。

企业典型架构：用户 → LVS（四层入口，扛大流量） → Nginx（七层，精细化分流） → 后端应用。两层各司其职：四层保证转发性能上限，七层保证流量治理灵活性。