从输入URL到页面展示全流程

第一阶段：网络连接

1. URL 解析与前置检查

当你在浏览器输入 https://www.example.com/index.html 时，浏览器首先将其拆解：

协议（Protocol） ：https（默认端口 443）
域名（Host） ：www.example.com
路径（Path） ：/index.html

在正式出发前，浏览器会进行安全与缓存检查：Service Worker 缓存 、浏览器缓存 ，以及检查该域名是否命中 HSTS（HTTP Strict Transport Security，若命中则强制将 HTTP 请求重定向为 HTTPS 安全连接）。

2. DNS 域名解析

由于网络传输基于 IP 地址，浏览器必须将域名转换为 IP。解析过程遵循"由近及远"的逐级查找缓存与查询机制：

$浏览器缓存→操作系统缓存→Hosts文件→本地DNS服务器(LDNS)\text{浏览器缓存} \rightarrow \text{操作系统缓存} \rightarrow \text{Hosts文件} \rightarrow \text{本地DNS服务器(LDNS)}$ 浏览器缓存→操作系统缓存→Hosts文件→本地DNS服务器(LDNS)

若本地无果，LDNS 将发起全球迭代查询：

$)} \rightarrow \text{返回目标IP}$ 根DNS服务器(.)→顶级域DNS(.com)→权威DNS(example.com)→返回目标IP

3. TCP 三次握手

拿到 IP 后，客户端与服务器通过 TCP 协议建立可靠连接。通过"三次握手"确保双方的收发能力正常并初始化序列号：

Client $→\rightarrow$ → Server : 发送 SYN（请求建立连接）。
Server $→\rightarrow$ → Client : 回应 SYN + ACK（同意连接并确认收到）。
Client $→\rightarrow$ → Server : 发送 ACK（确认收到，连接建立）。

4. TLS 安全握手

由于是 HTTPS 协议，在 TCP 建立后必须进行 TLS 握手：

身份验证（防冒充） ：服务器发送数字证书。浏览器使用内置的 CA 公钥验证数字签名，并重新计算证书摘要进行比对，确认证书合法且未被篡改。
密钥协商（防窃听） ：双方通过非对称加密（TLS 1.2 的 RSA/ECDHE 或 TLS 1.3 的强制 ECDHE）安全地协商出会话密钥（Session Key） 。
后续通信 ：由于非对称加密极耗性能，握手完成后，后续所有数据交互全部转用高效的对称加密（如 AES、ChaCha20） 。

💡 提问：现代网络请求一定会每次都建立连接吗？

并不是。网络协议经历了四代演进，极大地减少了握手开销：

HTTP/1.0：短连接。每个请求都要经历三次握手和四次挥手，性能极差。

HTTP/1.1 ：默认开启 Keep-Alive 长连接。多个请求可复用同一个 TCP 通道。

HTTP/2 ：引入多路复用。在单条 TCP 连接中划分不同的 Stream，多个请求可以同时并发传输，解决了应用层队头阻塞。

HTTP/3 ：彻底抛弃 TCP，基于 UDP 协议上的 QUIC 协议运行。在传输层解决了队头阻塞，实现 0-RTT/1-RTT 极速建连。

第二阶段：数据交互

5. 发送 HTTP 请求

浏览器封装好 HTTP 请求报文（包含 Request Method、Headers、Cookies 等），通过已建立的安全通道发送给服务器。

6. 服务端多层架构处理

请求到达服务器后，通常会流经标准的企业级后端架构：

Nginx（反向代理/网关） ：负责负载均衡、安全防护、SSL 证书卸载以及静态资源分发。
应用服务 ：Nginx 将动态请求转发给后端集群，执行核心业务逻辑。
Redis ：高频数据优先从内存缓存中读取，减轻数据库压力。
持久化数据库 ：执行复杂的业务查询、事务处理。

7. 返回 HTTP 响应

服务端处理完毕后，组装 HTTP 响应报文（包含状态码 200 OK、响应头及 HTML 文本）。为了减少网络带宽消耗，响应体通常会使用 Gzip 或更先进的 Brotli 算法进行高比例压缩。

第三阶段：浏览器渲染

当浏览器接收到 HTML 字节流后，渲染引擎开始高速运转，启动浏览器渲染流水线：

8. 解析 HTML 构建 DOM 树

浏览器将 HTML 文本转换为浏览器能理解的树状结构------DOM Tree（文档对象模型树） 。

9. 解析 CSS 构建 CSSOM 树

当遇到 <link rel="stylesheet"> 时，浏览器异步下载并解析 CSS，构建出 CSSOM Tree（样式对象模型树） 。

10. 应对 JavaScript 阻塞机制

当解析器遇到 <script src="app.js"> 时：

默认行为 ：HTML 解析被强行暂停，等待 JS 脚本下载并执行完毕后，才继续解析 HTML。这是因为 JS 可能会操作 DOM。
现代优化方案：
- defer：异步下载，等 HTML 全部解析完毕后，按照声明顺序依次执行。
- async：异步下载，下载完立即执行，执行时依然会阻塞 HTML 解析。

11. 合并生成渲染树（Render Tree）

DOM 树与 CSSOM 树构建完成后，浏览器将二者合并生成 Render Tree（渲染树） 。

渲染树只包含屏幕上可见的节点。
设置了 display: none; 的元素不会进入渲染树；而 visibility: hidden; 的元素由于占据空间，依然会在渲染树中。

12. 布局计算（Layout/Reflow 回流）

浏览器从渲染树的根节点开始遍历，计算每个节点在屏幕上的精确几何位置、宽度和高度 。这个阶段也叫做回流（Reflow） 。

13. 元素绘制（Paint/Repaint 重绘）

有了几何位置后，浏览器会调用像素绘制指令，将元素的颜色、背景、边框、阴影等外观属性绘制出来，生成绘制列表。这一步叫做重绘（Repaint） 。

14. 图层合成（Compositing）与硬件加速

为了极速响应动画和滚动，现代浏览器会把页面切分成多个图层（Layers） （例如拥有 transform、opacity、will-change 属性的元素）。

GPU 时刻 ：这些图层由 CPU 生成后，被提交给 GPU（显卡） 。GPU 负责将这些图层按照正确的层叠顺序合成为一张位图，并渲染输出到显示器上。
性能飞跃 ：仅改变 transform 动画时，浏览器不需要触发回流和重绘，直接在 GPU 中完成图层合成（Composite），这就是"硬件加速"。

第四阶段：后续生命周期与事件循环

15. 异步资源加载

页面主体出来后，页面中的异步资源（如 <img> 图片、fetch/axios 接口请求、动态字体等）会继续通过网络加载。随着数据的到达，局部视图会被逐步刷新。

16. 动态交互与事件循环（Event Loop）

一旦页面完全展示，用户便可以进行点击、滚动、输入等交互。

用户的每一次操作都会向事件循环（Event Loop）的任务队列中推送一个事件任务。JS 引擎线程执行该回调，若代码修改了 DOM 结构或样式，将再次触发：

$JavaScript修改→Layout(回流)→Paint(重绘)→Composite(合成)→屏幕更新\text{JavaScript修改} \rightarrow \text{Layout(回流)} \rightarrow \text{Paint(重绘)} \rightarrow \text{Composite(合成)} \rightarrow \text{屏幕更新}$ JavaScript修改→Layout(回流)→Paint(重绘)→Composite(合成)→屏幕更新

总结

用户输入 URL 后，浏览器首先解析 URL 并进行 DNS 查询获取服务器 IP，然后通过 TCP 三次握手建立连接。如果是 HTTPS，还会进行 TLS 握手，通过数字证书验证服务器身份并协商对称加密密钥。随后浏览器发送 HTTP 请求，服务器经过 Nginx、应用服务、Redis/MySQL 等处理后返回 HTTP 响应。浏览器收到 HTML 后开始解析，构建 DOM Tree，同时下载并解析 CSS 构建 CSSOM Tree，执行 JavaScript。之后将 DOM 和 CSSOM 合并生成 Render Tree，经过 Layout 计算元素位置和尺寸，再进行 Paint 绘制，最后由 GPU 进行图层合成并显示到屏幕上。页面展示后继续加载图片、接口数据等资源，用户后续操作通过事件循环驱动页面更新。