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

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

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

一、总体流程

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

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

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

从输入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浏览器状态

开始加载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

响应行返回状态码301

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

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

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

我们看到服务器返回如下信息:
响应行返回状态码200

响应行返回状态码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

含有HTML格式的Content-Type

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

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

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

请求后返回的响应头信息如下:
含有stream格式的Content-Type

含有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渲染引擎流程

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,组装协议,构成完整的 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版)》
极客时间


博文对你有帮助吗?如果有的话,想不想送我一本书呢?
  目录