一文摸透从输入URL到页面渲染的过程

一文摸透从输入 URL 到页面渲染的过程

从输入 URL 到页面渲染需要 Chrome 浏览器的多个进程配合，所以我们先来谈谈现阶段 Chrome 浏览器的多进程架构。

一、 Chrome 架构

目前 Chrome 采用的是多进程的架构模式，可分为主要的五类进程，分别是：浏览器（ Browser ）主进程、 GPU 进程、网络（ NetWork ）进程、多个渲染进程和多个插件进程；

• 浏览器进程 。主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。
• 渲染进程 。核心任务是将 HTML 、 CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下， Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。
• GPU 进程 。其实， Chrome 刚开始发布的时候是没有 GPU 进程的。而 GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、 Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后， Chrome 在其多进程架构上也引入了 GPU 进程。
• 网络进程 。主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。
• 插件进程 。主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响

了解了 Chrome 的多进程架构，就能够从宏观上理解从输入 URL 到页面渲染的过程了，这个过程主要分为 导航阶段 和 渲染阶段 。

二、导航阶段

Ⅰ.浏览器主进程

1.用户输入 URL

• 1、 浏览器进程检查 url ，组装协议，构成完整的 url ，这时候有两种情况：
  • 输入的是搜索内容：地址栏会使用浏览器默认的搜索引擎，来合成新的带搜索关键字的 URL 。
  • 输入的是请求 URL ：地址栏会根据规则，给这段内容加上协议，合成为完整的 URL ；
• 2、 浏览器进程通过进程间通信（ IPC ）把 url 请求发送给网络进程；

Ⅱ.网络进程

2. URL 请求过程

• 3、 网络进程接收到 url 请求后检查本地缓存是否缓存了该请求资源，如果有则将该资源返回给浏览器进程；

这里涉及到浏览器的缓存策略问题，有兴趣的可以上网查阅相关资料。

• 4、准备 IP 地址和端口：进行 DNS 解析时先查找缓存，没有再使用 DNS 服务器解析，查找顺序为：

  • 浏览器缓存；
  • 本机缓存；
  • hosts 文件；
  • 路由器缓存；
  • ISP DNS 缓存；
  • DNS 递归查询（本地 DNS 服务器 -> 权限 DNS 服务器 -> 顶级 DNS 服务器 -> 13 台根 DNS 服务器）

• 5、等待 TCP 队列：浏览器会为每个域名最多维护 6 个 TCP 连接，如果发起一个 HTTP 请求时，这 6 个 TCP 连接都处于忙碌状态，那么这个请求就会处于排队状态；解决方案：

  • 采用域名分片技术：将一个站点的资源放在多个（ CDN ）域名下面。
  • 升级为 HTTP2 ，就没有 6 个 TCP 连接的限制了；

• 6、通过三次握手建立 TCP 连接：

  

  • 第一次： 客户端先向服务器端发送一个同步数据包，报文的 TCP 首部中：标志位： 同步 SYN 为 1 ，表示这是一个请求建立连接的数据包；序号 Seq=x ， x 为所传送数据的第一个字节的序号，随后进入 SYN-SENT 状态；

  标志位值为 1 表示该标志位有效。

  • 第二次： 服务器根据收到数据包的 SYN 标志位判断为建立连接的请求，随后返回一个确认数据包，其中标志位 SYN=1 ， ACK=1 ，序号 seq=y ，确认号 ack=x + 1 表示收到了客户端传输过来的 x 字节数据，并希望下次从 x+1 个字节开始传，并进入 SYN-RCVD 状态；

  这里要区分标志位 ACK 和确认号 ack ；

  • 第三次： 客户端收到后，再给服务器发送一个确认数据包，标志位 ACK=1 ，序号 seq=x+1 ，确认号 ack=y+1 ，随后进入 ESTABLISHED 状态；

  服务器端收到后，也进入 ESTABLISHED 状态，由此成功建立了 TCP 连接，可以开始数据传送；

  • 为什么要第三次挥手？ 避免服务器等待造成 资源浪费 ，具体原因：

  如果没有最后一个数据包确认（第三次握手）， A 先发出一个建立连接的请求数据包，由于网络原因绕远路了。 A 经过设定的超时时间后还未收到 B 的确认数据包。

  于是发出第二个建立连接的请求数据包，这次网路通畅， B 的确认数据包也很快就到达 A 。于是 A 与 B 开始传输数据；

  过了一会 A 第一次发出的建立连接的请求数据包到达了 B ， B 以为是再次建立连接，所以又发出一个确认数据包。由于A已经收到了一个确认数据包，所以会忽略 B 发来的第二个确认数据包，但是 B 发出确认数据包之后就要一直等待 A 的回复，而 A 永远也不会回复。

  由此造成服务器资源浪费，这种情况多了 B 计算机可能就停止响应了。

• 7、构建并发送 HTTP 请求信息；

• 8、服务器端处理请求；

• 9、客户端处理响应，首先检查服务器响应报文的状态码：

  • 如果是 301/302 表示服务器已更换域名需要重定向，这时网络进程会从响应头的 Location 字段里面读取重定向的地址，然后再发起新的 HTTP 或者 HTTPS 请求，跳回第 4 步。
  • 如果是 200 ，就检查 Content-Type 字段，值为 text/html 说明是 HTML 文档，是 application/octet-stream 说明是文件下载；

• 10、 请求结束，当通用首部字段 Conection 不是 Keep-Alive 时，即不为 TCP 长连接时，通过四次挥手断开 TCP 连接：

• 第一次： 客户端（主动断开连接）发送数据包给服务器，其中标志位 FIN=1 ，序号位 seq=u ，并停止发送数据；
• 第二次： 服务器收到数据包后，由于还需传输数据，无法立即关闭连接，先返回一个标志位 ACK=1 ，序号 seq=v ，确认号 ack=u+1 的数据包；
• 第三次： 服务器准备好断开连接后，返回一个数据包，其中标志位 FIN=1 ，标志位 ACK=1 ，序号 seq=w ，确认号 ack=u+1 ；
• 第四次： 客户端收到数据包后，返回一个标志位 ACK=1 ，序号 seq=u+1 ，确认号 ack=w+1 的数据包。

由此通过四次挥手断开 TCP 连接。

详细过程参见： 详解TCP连接的“三次握手”与“四次挥手”(上)

• 为什么要四次挥手？ 由于服务器不能马上断开连接，导致 FIN 释放连接报文与 ACK 确认接收报文需要分两次传输，即第二次和第三次"挥手"；

3.准备渲染进程

• 11、 准备渲染进程：浏览器进程检查当前 url 是否与之前打开了渲染进程的页面的根域名相同，如果相同，则复用原来的进程，如果不同，则开启新的渲染进程；

4.提交文档

• 12、 提交文档：
  • 渲染进程 准备好后， 浏览器 向 渲染进程 发起“ 提交文档 ”的消息， 渲染进程 接收到消息后与 网络进程 建立传输数据的“ 管道 ”
  • 渲染进程 接收完数据后，向浏览器发送“ 确认提交 ”
  • 浏览器进程 接收到确认消息后更新浏览器界面状态： 安全状态 、 地址栏 url 、 前进后退的历史状态 、 更新 web 页面

三、渲染阶段

在渲染阶段通过 渲染流水线 在渲染进程的主线程和合成线程配合下，完成页面的渲染；

Ⅲ.渲染进程

渲染进程中的主线程部分

5.构建 DOM 树

• 13、先将请求回来的数据解压，随后 HTML 解析器将其中的 HTML 字节流 通过 分词器 拆分为一个个 Token ，然后生成节点 Node ，最后解析成浏览器识别的 DOM 树结构。

  可以通过 Chrome 调试 工具 的 Console 选项打开控制台输入 document 查看 DOM 树；

渲染引擎还有一个 安全检查模块 叫 XSSAuditor ，是用来 检测词法安全 的。在分词器解析出来 Token 之后，它会检测这些模块是否安全，比如 是否引用了外部脚本 ， 是否符合 CSP 规范 ， 是否存在跨站点请求 等。如果出现不符合规范的内容， XSSAuditor 会对该脚本或者下载任务 进行拦截 。

首次解析 HTML 时 渲染进程 会开启一个 预解析线程 ，遇到 HTML 文档中内嵌的 JavaScript 和 CSS 外部引用就会同步提前下载这些文件，下载时间以最后下载完的文件为准。

6.构建 CSSOM

• 14、 CSS 解析器将 CSS 转换为浏览器能识别的 styleSheets 也就是 CSSOM ：可以通过控制台输入 document.styleSheets 查看；

  这里要考虑一下阻塞的问题，由于 JavaScript 有修改 CSS 和 HTML 的能力，所以，需要先等到 CSS 文件下载完成并生成 CSSOM ，然后再执行 JavaScript 脚本，最后再继续构建 DOM 。由于这种阻塞，导致了 解析白屏 ；

可以通过浏览器调试工具的 Network 面板中的 DOMContentLoaded 查看最后生成 DOM 树所需的时间；

7.样式计算

• 15、 转换样式表中的属性值，使其标准化。比如将 em 转换为 px ， color 转换为 rgb ；
• 16、 计算 DOM 树中每个节点的具体样式，这里遵循 CSS 的继承和层叠规则；可以通过 Chrome 调试工具的 Elements 选项的 Computed 查看某一标签的最终样式；

8.布局阶段

• 17、创建布局树，遍历 DOM 树中的所有节点，去掉所有隐藏的节点（比如 head ，添加了 display:none 的节点），只在布局树中保留可见的节点。

• 18、计算布局树中节点的坐标位置（较复杂，这里不展开）；

9.分层

• 19、 对布局树进行分层，并生成分层树（ Layer Tree ），可以通过 Chrome 调试工具的 Layer 选项查看。分层树中每一个节点都直接或间接的属于一个图层（如果一个节点没有对应的层，那么这个节点就从属于父节点的图层）

10.图层绘制

• 20、 为每个图层生成绘制列表（即绘制指令），并将其提交到合成线程。以上操作都是在渲染进程中的主线程中进行的，提交到合成线程后就不阻塞主线程了；

渲染进程中的合成线程部分

11.切分图块

21、合成线程将图层切分成大小固定的图块（ 256x256 或者 512x512 ）然后 优先绘制 靠近视口的图块，这样就可以大大加速页面的显示速度；

Ⅳ. GPU 进程

12.栅格化操作

• 22、 在 光栅化线程池 中将 图块 转换成 位图 ，通常这个过程都会使用 GPU 来加速生成，使用 GPU 生成位图的过程叫 快速栅格化 ，或者 GPU 栅格化，生成的位图被保存在 GPU 内存中。

Ⅴ.浏览器主进程

13.合成与显示

• 23、 合成：一旦所有图块都被光栅化， 合成线程 就会将它们合成为一张图片，并生成一个绘制图块的命令——“ DrawQuad ”，然后将该命令提交给浏览器进程。

注意了：合成的过程是在渲染进程的 合成线程 中完成的，不会影响到渲染进程的 主线程 执行；

• 24、 显示：浏览器进程里面有一个叫 viz 的组件，用来接收合成线程发过来的 DrawQuad 命令，然后根据 DrawQuad 命令，将其页面内容绘制到内存中，最后再将内存显示在屏幕上。

到这里，经过这一系列的阶段，编写好的 HTML 、 CSS 、 JavaScript 等文件，经过浏览器就会显示出漂亮的页面了。

参考资料： 浏览器工作原理与实践