极高 进阶
从URL输入到页面显示#
一句话答案#
URL 解析→DNS 解析→TCP 连接→TLS 握手→HTTP 请求→服务器处理→响应返回→浏览器渲染（DOM/CSSOM/Layout/Paint）。
核心要点
完整流程（10步）：
1. URL 解析
解析 URL 各部分：协议（https）、域名（www.example.com）、路径（/page）、参数
判断是否有效 URL；无效则作为搜索关键词提交到搜索引擎2. 检查缓存
浏览器缓存 → 操作系统缓存 → 路由器缓存 → ISP DNS 缓存
命中缓存：直接返回缓存的 IP，跳过 DNS 查询3. DNS 解析（将域名解析为 IP）
本地 hosts 文件 → 本地 DNS 缓存 → 递归查询 DNS 服务器
递归 DNS 查询过程：
本地 DNS 服务器 → 根域名服务器（返回 .com 的 NS）
→ .com 顶级域名服务器（返回 example.com 的 NS）
→ example.com 权威 DNS 服务器（返回 www.example.com 的 IP）
→ 缓存 IP，返回给浏览器4. 建立 TCP 连接（三次握手）
客户端 → SYN → 服务端
客户端 ← SYN-ACK ← 服务端
客户端 → ACK → 服务端
连接建立（约 1 RTT）5. TLS 握手（HTTPS 时）
TLS 1.2：额外 2 RTT
TLS 1.3：额外 1 RTT（优化）
建立加密通道6. 发送 HTTP 请求
构造 HTTP 请求报文：
GET /page HTTP/1.1
Host: www.example.com
Cookie: ...
Accept: text/html
User-Agent: ...7. 服务端处理请求并返回响应
Web 服务器（Nginx）接收请求
→ 反向代理到后端（Tomcat/Spring Boot）
→ 应用层处理（Controller → Service → DB → Cache）
→ 构造 HTTP 响应报文返回8. 浏览器解析 HTML
解析 HTML → 构建 DOM 树
解析 CSS → 构建 CSSOM 树
DOM + CSSOM → Render Tree（渲染树）
遇到 <script>：
默认阻塞解析（等脚本加载执行完）
async：异步加载，加载完立即执行（不阻塞解析）
defer：异步加载，HTML 解析完后执行（不阻塞）9. 页面渲染
布局（Layout / Reflow）：计算每个元素的位置和大小
绘制（Paint）：将元素绘制到位图
合成（Composite）：多层合并，输出最终页面10. 关闭 TCP 连接（四次挥手）或保持连接（Keep-Alive）
面试回答（2分钟版）
我从整个链路来讲。用户输入URL后，浏览器首先解析URL提取协议、域名和路径，然后进行DNS解析，依次查浏览器缓存、OS缓存、本地DNS服务器，最终通过递归查询根域名服务器、顶级域名服务器、权威DNS服务器拿到IP地址。接着建立TCP连接，经过三次握手耗时约1个RTT；如果是HTTPS还需要TLS握手，TLS 1.2额外2个RTT，TLS 1.3优化到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/TCP/TLS 是不同的阶段）
- ❌ “浏览器直接请求服务器”——可能经过代理/CDN/负载均衡