这是一道经典的面试题，文本将深入浅出讲解从输入 URL 到页面展示的完整流程。

本文接下来的介绍都是基于 Chrome 浏览器的。因为 Chrome、微软的 Edge 以及国内的大部分主流浏览器，都是基于 Chromium 二次开发而来；而 Chrome 是 Google 的官方发行版，特性和 Chromium 基本一样，只存在一些产品层面差异；再加上 Chrome 是目前世界上使用率最高的浏览器，所以 Chrome 最具代表性。

一、总体流程

首先，整个过程需要各个进程之间的配合，以 Chrome 为例，下面介绍下它内部 3 个进程的主要职责，即浏览器进程、渲染进程和网络进程。

• 浏览器进程主要负责用户交互、子进程管理和文件储存等功能。
• 网络进程是面向渲染进程和浏览器进程等提供网络下载功能。
• 渲染进程的主要职责是把从网络下载的 HTML、JavaScript、CSS、图片等资源解析为可以显示和交互的页面。因为渲染进程所有的内容都是通过网络获取的，会存在一些恶意代码利用浏览器漏洞对系统进行攻击，所以运行在渲染进程里面的代码是不被信任的。这也是为什么 Chrome 会让渲染进程运行在安全沙箱里，就是为了保证系统的安全。

接下来看整个流程，如下图所示，是「从输入URL到页面展示完整流程示意图」：

从图中可以看出，整个流程包含了许多步骤，其中几个核心的节点用蓝色背景标记出来了。这个过程可以大致描述为如下：

• 首先，浏览器进程接收到用户输入的 URL 请求，浏览器进程便将该 URL 转发给网络进程；
• 然后，在网络进程中发起真正的 URL 请求。
• 接着网络进程接收到了响应头数据，便解析响应头数据，并将数据转发给浏览器进程。
• 浏览器进程接收到网络进程的响应头数据之后，发送「提交导航（CommitNavigation）」消息到渲染进程；
• 渲染进程接收到「提交导航」的消息之后，便开始准备接收 HTML 数据，接收数据的方式是直接和网络进程建立数据管道；
• 最后渲染进程会向浏览器进程「确认提交」，这是告诉浏览器进程：「已经准备好接受和解析页面数据了」；
• 浏览器进程接收到渲染进程「提交文档」的消息之后，便开始移除之前旧的文档，然后更新浏览器进程中的页面状态。

这其中，用户发出 URL 请求到页面开始解析的这个过程，就叫做导航；将 HTML、CSS、JavaScript 变成页面，就叫作渲染。下面我们来详细分析下以上过程。

二、第一阶段：导航

1. 用户输入

当用户在地址栏中输入一个查询关键字时，地址栏会判断输入的关键字是搜索内容，还是请求的 URL。

• 如果是搜索内容，地址栏会使用浏览器默认的搜索引擎，来合成新的带搜索关键字的 URL。
• 如果判断输入内容符合 URL 规则，比如输入的是 www.wenyuanblog.com，那么地址栏会根据规则，把这段内容加上协议，合成为完整的 URL，如 https://www.wenyuanblog.com。

当用户输入关键字并键入回车之后，这意味着当前页面即将要被替换成新的页面，不过在这个流程继续之前，浏览器还给了当前页面一次执行 beforeunload 事件的机会，beforeunload 事件允许页面在退出之前执行一些数据清理操作，还可以询问用户是否要离开当前页面，比如当前页面可能有未提交完成的表单等情况，因此用户可以通过 beforeunload 事件来取消导航，让浏览器不再执行任何后续工作。当前页面没有监听 beforeunload 事件或者同意了继续后续流程，那么浏览器便进入下图的状态：

从图中可以看出，当浏览器刚开始加载一个地址之后，标签页上的图标便进入了加载状态。但此时图中页面显示的依然是之前打开的页面内容，并没立即替换为新的页面。因为需要等待提交文档阶段，页面内容才会被替换。

2. URL 请求过程

接下来，便进入了页面资源请求过程。这时，浏览器进程会通过进程间通信（IPC）把 URL 请求发送至网络进程，网络进程接收到 URL 请求后，会在这里发起真正的 URL 请求流程。那具体流程是怎样的呢？

首先，网络进程会查找本地缓存是否缓存了该资源。如果有缓存资源，那么直接返回资源给浏览器进程；如果在缓存中没有查找到资源，那么直接进入网络请求流程。这请求前的第一步是要进行 DNS 解析，以获取请求域名的服务器 IP 地址。如果请求协议是 HTTPS，那么还需要建立 TLS 连接。

接下来就是利用 IP 地址和服务器建立 TCP 连接。连接建立之后，浏览器端会构建请求行、请求头等信息，并把和该域名相关的 Cookie 等数据附加到请求头中，然后向服务器发送构建的请求信息。

服务器接收到请求信息后，会根据请求信息生成响应数据（包括响应行、响应头和响应体等信息），并发给网络进程。等网络进程接收了响应行和响应头之后，就开始解析响应行和响应头的内容了。

（1）重定向

在接收到服务器返回的响应行和响应头后，网络进程开始解析它们，如果发现返回的状态码是 301 或者 302，那么说明服务器需要浏览器重定向到其他 URL。这时网络进程会从响应头的 Location 字段里面读取重定向的地址，然后再发起新的 HTTP 或者 HTTPS 请求，一切又重头开始了。

比如，我们在终端里输入以下命令：

curl -I http://www.wenyuanblog.com/

curl -I + URL 的命令是接收服务器返回的响应头的信息。执行命令后，我们看到服务器返回的响应头信息如下：

从图中可以看出，服务器会通过重定向的方式把所有 HTTP 请求转换为 HTTPS 请求。也就是说你使用 HTTP 向服务器请求时，服务器会返回一个包含有 301 或者 302 状态码响应头，并把响应头的 Location 字段中填上 HTTPS 的地址，这就是告诉了浏览器要重新导航到新的地址上。

下面我们再使用 HTTPS 协议发起请求，看看服务器的响应头信息是什么样子的。

curl -I https://www.wenyuanblog.com/

我们看到服务器返回如下信息：

从图中可以看出，服务器返回的响应头的状态码是 200，这是告诉浏览器一切正常，可以继续往下处理该请求了。

在导航过程中，如果服务器响应行的状态码包含了 301、302 一类的跳转信息，浏览器会跳转到新的地址继续导航；如果响应行是 200，那么表示浏览器可以继续处理该请求。

（2）响应数据类型处理

在处理了跳转信息之后，我们继续导航流程的分析。URL 请求的数据类型，有时候是一个下载类型，有时候是正常的 HTML 页面，那么浏览器是如何区分它们呢？

答案是 Content-Type。Content-Type 是 HTTP 头中一个非常重要的字段，它告诉浏览器服务器返回的响应体数据是什么类型，然后浏览器会根据 Content-Type 的值来决定如何显示响应体的内容。

这里我们还是以上面的请求结果为例，看看返回的 Content-Type 值是什么。在终端输入以下命令：

curl -I https://www.wenyuanblog.com/

返回信息如下图：

从图中可以看到，响应头中的 Content-type 字段的值是 text/html，这就是告诉浏览器，服务器返回的数据是 HTML 格式。

接下来我们再来利用 curl 来请求一些资源，比如安装包的地址，如下所示：

curl -I https://www.wenyuanblog.com/download/wechat.apk

请求后返回的响应头信息如下：

从返回的响应头信息来看，其 Content-Type 的值是 application/octet-stream，显示数据是字节流类型的，通常情况下，浏览器会按照下载类型来处理该请求。

需要注意的是，如果服务器配置 Content-Type 不正确，比如将 text/html 类型配置成 application/octet-stream 类型，那么浏览器可能会曲解文件内容，比如会将一个本来是用来展示的页面，变成了一个下载文件。

所以，不同 Content-Type 的后续处理流程也截然不同。如果 Content-Type 字段的值被浏览器判断为下载类型，那么该请求会被提交给浏览器的下载管理器，同时该 URL 请求的导航流程就此结束。但如果是 HTML，那么浏览器则会继续进行导航流程。由于 Chrome 的页面渲染是运行在渲染进程中的，所以接下来就需要准备渲染进程了。

3. 准备渲染进程

默认情况下，Chrome 会为每个页面分配一个渲染进程，也就是说，每打开一个新页面就会配套创建一个新的渲染进程。但是，也有一些例外，在某些情况下，浏览器会让多个页面直接运行在同一个渲染进程中。

比如我从本站博客的首页里面打开了另外一个页面 —— 友情链接，我们看下图的 Chrome 的任务管理器截图：

从图中可以看出，打开的这三个页面都是运行在同一个渲染进程中，进程 ID 是 16336。

那什么情况下多个页面会同时运行在一个渲染进程中呢？

简单说来，就是同一站点（same-site）。具体地讲，我们将「同一站点」定义为根域名（例如，wenyuanblog.com）加上协议（例如，https:// 或者 http://），还包含了该根域名下的所有子域名和不同的端口，比如下面这三个：

https://www.wenyuanblog.com
https://www.wenyuanblog.com:8080
https://cceditor.wenyuanblog.com

它们都是属于同一站点，因为它们的协议都是 HTTPS，而且根域名也都是 wenyuanblog.com。

Chrome 的默认策略是，每个标签对应一个渲染进程。但如果从一个页面打开了另一个新页面，而新页面和当前页面属于同一站点的话，那么新页面会复用父页面的渲染进程。官方把这个默认策略叫 process-per-site-instance。

总结来说，打开一个新页面采用的渲染进程策略就是：

• 通常情况下，打开新的页面都会使用单独的渲染进程；
• 如果从 A 页面打开 B 页面，且 A 和 B 都属于同一站点的话，那么 B 页面复用 A 页面的渲染进程；如果是其他情况，浏览器进程则会为 B 创建一个新的渲染进程。

但也有一种特殊情况：即使在同一下域名内新开的页面都是新开一个渲染进程，有一种说法是因为在 <a> 标签里面使用了 rel=”noopener noreferrer” 这个属性。使用 noopener noreferrer 就是告诉浏览器，新打开的子窗口不需要访问父窗口的任何内容，这是为了防止一些钓鱼网站窃取父窗口的信息。浏览器在打开新页面时，解析到含有 noopener noreferrer 时，就知道他们不需要共享页面内容，所以这时候浏览器就会让新链接在一个新页面中打开了。

渲染进程准备好之后，还不能立即进入文档解析状态，因为此时的文档数据还在网络进程中，并没有提交给渲染进程，所以下一步就进入了提交文档阶段。

4. 提交文档

所谓提交文档，就是指浏览器进程将网络进程接收到的 HTML 数据提交给渲染进程，具体流程是这样的：

• 当浏览器进程接收到网络进程的响应头数据之后，便向渲染进程发起「提交文档」的消息；
• 渲染进程接收到「提交文档」的消息后，会和网络进程建立传输数据的「管道」；
• 等文档数据传输完成之后，渲染进程会返回「确认提交」的消息给浏览器进程；
• 浏览器进程在收到「确认提交」的消息后，会更新浏览器界面状态，包括了安全状态、地址栏的 URL、前进后退的历史状态，并更新 Web 页面。

因此，在浏览器的地址栏里面输入了一个地址后，之前的页面不会立马消失，只有当一个完整的导航流程「走」完了以后，才会更新页面。

此时的 web 页面是空白页，且标签图标上仍有加载动画，因为接下来还要进入渲染阶段。

三、第二阶段：渲染

一旦文档被提交，即渲染进程拿到 HTML 数据后，便开始页面解析和子资源加载了。这个过程就是将 HTML、CSS 和 JavaScript 变成最终的页面。

有一张很经典的 webkit 渲染引擎流程，如下：

从图中我们可以看出，渲染过程可以分为以下五个步骤：

• 根据 HTML 解析出 DOM 树
• 根据 CSS 解析生成 CSS 规则树
• 结合 DOM 树和 CSS 规则树，生成渲染树
• 根据渲染树计算每一个节点的信息
• 根据计算好的信息绘制页面

1. 根据 HTML 解析 DOM 树

因为浏览器无法直接理解和使用 HTML，所以需要将 HTML 转换为浏览器能够理解的结构 —— DOM 树。

• DOM 树解析的过程是一个深度优先遍历。即先构建当前节点的所有子节点，再构建下一个兄弟节点。
• 在读取 HTML 文档，构建 DOM 树的过程中，若遇到 script 标签，则 DOM 树的构建会暂停，直至脚本执行完毕。

2. 根据 CSS 解析生成 CSS 规则树

这个过程是将 CSS 文本转换为浏览器能够理解的结构 —— CSS 规则树（styleSheets）。

• 解析 CSS 规则树时 js 执行将暂停，直至 CSS 规则树就绪。
• 浏览器在 CSS 规则树生成之前不会进行渲染。

3. 结合 DOM 树和 CSS 规则树，生成渲染树

• DOM 树和 CSS 规则树全部准备好了以后，浏览器才会开始构建渲染树。
• 精简 CSS 并可以加快 CSS 规则树的构建，从而加快页面相应速度。

4. 根据渲染树计算每一个节点的信息（布局）

• 布局：通过渲染树中渲染对象的信息，计算出每一个渲染对象的位置和尺寸
• 回流：在布局完成后，发现了某个部分发生了变化影响了布局，那就需要倒回去重新渲染。

5. 根据计算好的信息绘制页面

• 绘制阶段，系统会遍历呈现树，并调用呈现器的「paint」方法，将呈现器的内容显示在屏幕上。
• 重绘：某个元素的背景颜色，文字颜色等，不影响元素周围或内部布局的属性，将只会引起浏览器的重绘。
• 回流：某个元素的尺寸发生了变化，则需重新计算渲染树，重新渲染。

查阅了很多资料，以上五个步骤是广为流传的描述，但现代浏览器开发团队一直在优化和重构，因此细节部分肯定会有所变动。比如有人提及「渲染树是 2016 年之前的概念了，现在的代码经过重构，衍生出了 LayoutTree，它的职能类似于渲染树，不过和之前的渲染树还是有一些差别的。」我本身不是做浏览器底层开发的，所以这块内容就不深挖了。感兴趣的可以研究下浏览器的源码。

等渲染阶段结束，页面生成完成，渲染进程就会发送一个消息给浏览器进程，浏览器接收到消息后，再停止标签图标上的加载动画。

四、面试官问

回到本文最开始，如果面试官问：「从输入 URL 到页面展示，这中间发生了什么？」，该怎么回答呢？

• 用户输入 url 并回车
• 浏览器进程检查 url，组装协议，构成完整的 url
• 浏览器进程通过进程间通信（IPC）把 url 转发给网络进程
• 网络进程接收到 url 请求后检查本地缓存是否缓存了该请求资源，如果有则将该资源返回给浏览器进程
• 如果没有，网络进程向 web 服务器发起 http 请求（网络请求），请求流程如下：
  • 进行DNS解析，获取服务器ip地址、端口
  • 利用 ip 地址和服务器建立 tcp 连接
  • 构建请求头信息
  • 发送请求头信息
  • 服务器响应后，网络进程接收响应头和响应信息，并解析响应内容
• 网络进程解析响应流程；
  • 检查状态码，如果是 301/302，则需要重定向，从 Location 自动中读取地址，重新进行上一步；如果是 200，则继续处理请求。
  • 200响应处理：
    检查响应类型 Content-Type，如果是字节流类型，则将该请求提交给下载管理器，该导航流程结束，不再进行；如果是 html 则通知浏览器进程准备渲染进程准备进行渲染。
• 准备渲染进程
  • 浏览器进程检查当前 url 是否和之前打开的渲染进程根域名是否相同，如果相同，则复用原来的进程，如果不同，则开启新的渲染进程。
• 传输数据、更新状态
  • 渲染进程准备好后，浏览器向渲染进程发起「提交文档」的消息，渲染进程接收到消息和网络进程建立传输数据的「管道」；
  • 渲染进程接收完数据后，向浏览器发送「确认提交」；
  • 浏览器进程接收到确认消息后更新浏览器界面状态：安全、地址栏 url、前进后退的历史状态、更新 web 页面，此时的 web 页面是空白页。
• 渲染进程对文档进行页面解析和子资源加载，生成最终页面
  • HTML：根据 HTML 解析出 DOM 树；
    CSS：根据 CSS 解析生成 CSS 规则树；
  • 结合 DOM 树和 CSS 规则树，生成渲染树；根据渲染树计算每一个节点的信息，最后根据计算好的信息绘制页面。

参考
极客时间
《图解HTTP》
《精通CSS 高级Web标准解决方案（第3版）》
《JavaScript高级程序设计（第3版）》