面试知识库
极高 进阶

从URL输入到页面显示#

一句话答案#

URL 解析→DNS 解析→TCP 连接→TLS 握手→HTTP 请求→服务器处理→响应返回→浏览器渲染(DOM/CSSOM/Layout/Paint)。

核心要点

完整流程(10步):

1. URL 解析

解析 URL 各部分:协议(https)、域名(www.example.com)、路径(/page)、参数
判断是否有效 URL;无效则作为搜索关键词提交到搜索引擎
plaintext

2. 检查 HTTP 缓存

Service Worker → 内存缓存 / 磁盘缓存
强缓存(Cache-Control: max-age 未过期)命中:直接用本地资源,不发网络请求,后面几步都跳过
过期了带 If-None-Match / If-Modified-Since 去做协商缓存,命中返回 304
plaintext

3. DNS 解析(将域名解析为 IP)

浏览器 DNS 缓存 → 操作系统缓存(含 hosts 文件)→ 本地 DNS 服务器(运营商/公共 DNS)
Chrome 等浏览器开启"安全 DNS"时走 DoH(DNS over HTTPS)直接问 DoH 服务器,绕过系统解析

客户端 → 本地 DNS 服务器是递归查询;本地 DNS 服务器再迭代查询:
  本地 DNS 服务器 → 根域名服务器(返回 .com 的 NS)
                   → .com 顶级域名服务器(返回 example.com 的 NS)
                   → example.com 权威 DNS 服务器(返回 www.example.com 的 IP)
  → 缓存 IP,返回给浏览器
浏览器还会查 HTTPS 记录(RFC 9460),如果声明了 alpn=h3,可以第一次访问就直接走 HTTP/3
plaintext

4. 建立 TCP 连接(三次握手)

客户端 → SYN → 服务端
客户端 ← SYN-ACK ← 服务端
客户端 → ACK → 服务端
连接建立(约 1 RTT)

HTTP/3 例外:服务端通过 DNS HTTPS 记录或响应头 Alt-Svc 声明支持 h3 时,
浏览器改用 QUIC(UDP),没有 TCP 三次握手,传输握手和 TLS 1.3 合并成 1 RTT,恢复会话可 0-RTT
plaintext

5. TLS 握手(HTTPS 时)

TLS 1.2:额外 2 RTT
TLS 1.3:额外 1 RTT(优化),会话恢复可 0-RTT
建立加密通道;ALPN 在握手中协商用 HTTP/1.1 还是 HTTP/2
plaintext

6. 发送 HTTP 请求

构造 HTTP 请求报文:
GET /page HTTP/1.1
Host: www.example.com
Cookie: ...
Accept: text/html
User-Agent: ...
plaintext

7. 服务端处理请求并返回响应

Web 服务器(Nginx)接收请求
→ 反向代理到后端(Tomcat/Spring Boot)
→ 应用层处理(Controller → Service → DB → Cache)
→ 构造 HTTP 响应报文返回
plaintext

8. 浏览器解析 HTML

解析 HTML → 构建 DOM 树
解析 CSS → 构建 CSSOM 树
DOM + CSSOM → Render Tree(渲染树)

遇到 <script>:
  默认阻塞解析(等脚本加载执行完)
  async:异步加载,加载完立即执行(不阻塞解析)
  defer:异步加载,HTML 解析完后执行(不阻塞)
plaintext

9. 页面渲染

布局(Layout / Reflow):计算每个元素的位置和大小
绘制(Paint):将元素绘制到位图
合成(Composite):多层合并,输出最终页面
plaintext

10. 关闭 TCP 连接(四次挥手)或保持连接(Keep-Alive)

面试回答(2分钟版)

我从整个链路来讲。用户输入URL后,浏览器首先解析URL提取协议、域名和路径,先查 HTTP 强缓存,命中就不发请求;没命中再进行DNS解析,依次查浏览器缓存、OS缓存、本地DNS服务器,本地DNS服务器再依次迭代查询根域名服务器、顶级域名服务器、权威DNS服务器拿到IP地址。接着建立TCP连接,经过三次握手耗时约1个RTT;如果是HTTPS还需要TLS握手,TLS 1.2额外2个RTT,TLS 1.3优化到1个RTT;如果服务端支持HTTP/3,就走基于UDP的QUIC,传输和加密握手合并成1个RTT。连接建立后浏览器发送HTTP请求,服务端经过Nginx反向代理到后端应用处理,返回HTTP响应。浏览器拿到HTML后解析构建DOM树,同时解析CSS构建CSSOM树,两者合并成渲染树,再经过Layout计算布局、Paint绘制、Composite合成三个阶段完成页面渲染。其中遇到script标签默认会阻塞解析,可以用async或defer优化。每个阶段都有优化空间,比如DNS预解析、CDN加速、HTTP/2多路复用、浏览器缓存策略等。

追问与易错

追问方向:

  • “每个阶段可以优化什么?”→ DNS 预解析(dns-prefetch)、CDN 加速静态资源、HTTP/2 多路复用、浏览器强缓存/协商缓存、JS async/defer 异步加载
  • “浏览器渲染流程?”→ 解析 HTML 构建 DOM → 解析 CSS 构建 CSSOM → 合并成 Render Tree → Layout 计算布局 → Paint 绘制 → Composite 合成输出

易错点:

  • ❌ “DNS 全程是递归查询”——客户端到本地 DNS 是递归,本地 DNS 到根/顶级/权威服务器是迭代
  • ❌ “HTTPS 一定先 TCP 三次握手再 TLS”——HTTP/3 走 QUIC(UDP),没有 TCP 握手
  • ❌ “每次都要走 DNS 和建连”——强缓存命中时根本不发请求
  • ❌ “浏览器直接请求服务器”——可能经过代理/CDN/负载均衡