好看的文章内容模板-详情页

技术周边

发布日期: 2020-04-04

最近更新: 2020-04-04

浏览器从输入URL到页面展示，中间发生了什么？

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

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

一、总体流程

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

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

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

从输入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 事件或者同意了继续后续流程，那么浏览器便进入下图的状态：

开始加载URL浏览器状态

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

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 的命令是接收服务器返回的响应头的信息。执行命令后，我们看到服务器返回的响应头信息如下：

响应行返回状态码301

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

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

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

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

响应行返回状态码200

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

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

（2）响应数据类型处理

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

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

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

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

返回信息如下图：

含有HTML格式的Content-Type

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

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

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

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

含有stream格式的Content-Type

从返回的响应头信息来看，其 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 渲染引擎流程，如下：

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 规则树，生成渲染树；根据渲染树计算每一个节点的信息，最后根据计算好的信息绘制页面。