浏览器工作原理-一一网

chrome架构：仅仅打开一个页面，为什么有四个进程？

单进程浏览器时代

早期的浏览器的所有功能模块都是运行在同一个进程中，这些模块包含了网络，插件，JS运行环境，渲染引擎和页面等。如此就导致了单线程浏览器不稳定，不流畅和不安全等问题。

早期多进程架构

目前的多进程架构

最新的浏览器包含：1个浏览器主进程，1个GPU进程，1个网络进程，多个渲染进程和多个插件进程。

浏览器进程：主要负责界面显示，用户交互，子进程管理，同时提供存储等功能。

渲染进程：核心任务是将HTML, CSS和JS转换为用户可以与之交互的网页，排版引擎Blink和JS引擎V8都是运行在该进程中，默认情况下，chrome会为每个tab标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。

GPU进程：GPU的使用初衷是为了实现3D CSS的效果，随后网页，chrome的UI界面都选择采用GPU来绘制，所以chrome在其多进程架构上引入了GPU进程。

网络进程：主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程中，后来成为一个单独的进程。

插件进程：主要负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。

虽然多进程模式提升了浏览器的稳定性。流畅性和安全性。但也带来了一些问题：

更高的资源占用：每个进程都会包含公共基础结构的副本（如JS运行环境），这就意味着浏览器会消耗更多的内存资源。

更复杂的体系结构：浏览器各模块之间的耦合性高，扩展性差等问题导致现在的架构已经很难适应新的需求了。

未来面向服务的架构

为了解决以上的问题，2016年chrome团队使用面向服务的架构（SOA）的思想设计了新的chrome架构。也就是说 Chrome 整体架构会朝向现代操作系统所采用的“面向服务的架构” 方向发展，原来的各种模块会被重构成独立的服务（Service），每个服务（Service）都可以在独立的进程中运行，访问服务（Service）必须使用定义好的接口，通过 IPC 来通信，从而构建一个更内聚、松耦合、易于维护和扩展的系统，更好实现 Chrome 简单、稳定、高速、安全的目标。

Chrome 最终要把 UI、数据库、文件、设备、网络等模块重构为基础服务，类似操作系统底层服务，下面是 Chrome“面向服务的架构”的进程模型图：

同时 Chrome 还提供灵活的弹性架构，在强大性能设备上会以多进程的方式运行基础服务，但是如果在资源受限的设备上（如下图），Chrome 会将很多服务整合到一个进程中，从而节省内存占用。

HTTP请求：为什么很多站点第二次打开迅速？

HTTP 是一种允许浏览器向服务器获取资源的协议，是 Web 的基础，通常由浏览器发起请求，用来获取不同类型的文件，例如 HTML 文件、CSS 文件、JavaScript 文件、图片、视频等。

浏览器端发起 HTTP 请求流程：

1. 构建请求：首先，浏览器构建请求行信息（ GET /index.html HTTP1.1），构建好后，浏览器准备发起网络请求。

2. 查找缓存：在真正发起网络请求之前，浏览器会先在浏览器缓存中查询是否有要请求的文件。其中，浏览器缓存是一种在本地保存资源副本，以供下次请求时直接使用的技术。当浏览器发现请求的资源已经在浏览器缓存中存有副本，它会拦截请求，返回该资源的副本，并直接结束请求，而不会再去源服务器重新下载。

3. 准备 IP 地址和端口：第一步浏览器会请求 DNS 返回域名对应的 IP。当然浏览器还提供了 DNS 数据缓存服务，如果某个域名已经解析过了，那么浏览器会缓存解析的结果，以供下次查询时直接使用，这样也会减少一次网络请求。拿到 IP 之后就需要获取端口号了，通常情况下，如果 URL 没有特别指明端口号，那么 HTTP 协议默认是 80 端口。

4. 等待 TCP 队列：http/1.1 一个tcp同时只能处理一个请求，浏览器会为每个域名维护6个tcp连接，如果在同一个域名下同时有 10 个请求发生，那么其中 4 个请求会进入排队等待状态，直至进行中的请求完成。每个tcp连接是可以复用的，也就是处理完一个请求之后，不断开这个tcp连接，可以用来处理下个http请求。但是在http2.0的时候采取多路复用的原则，可以并行请求资源，浏览器只会为每个域名维护一个tcp连接。

5. 建立 TCP 连接：在 HTTP 工作开始之前，浏览器通过 TCP 三次握手与服务器建立连接。

6. 发送 HTTP 请求：一旦建立了 TCP 连接，浏览器就可以和服务器进行通信了。而 HTTP 中的数据正是在这个通信过程中传输的。

首先浏览器会向服务器发送请求行，它包括了请求方法、请求 URI（Uniform Resource Identifier）和 HTTP 版本协议。发送请求行，就是告诉服务器浏览器需要什么资源，最常用的请求方法是 Get。比如，直接在浏览器地址栏键入极客时间的域名（time.geekbang.org），这就是告诉服务器要 Get 它的首页资源。另外一个常用的请求方法是 POST，它用于发送一些数据给服务器，比如登录一个网站，就需要通过 POST 方法把用户信息发送给服务器。如果使用 POST 方法，那么浏览器还要准备数据给服务器，这里准备的数据是通过请求体来发送。在浏览器发送请求行命令之后，还要以请求头形式发送其他一些信息，比如包含了浏览器所使用的操作系统、浏览器内核等信息，以及当前请求的域名信息、浏览器端的 Cookie 信息等等。

服务器端处理 HTTP 请求流程：

**1. 返回请求：
**

首先服务器会返回响应行，包括协议版本和状态码。随后，正如浏览器会随同请求发送请求头一样，服务器也会随同响应向浏览器发送响应头。响应头包含了服务器自身的一些信息，比如服务器生成返回数据的时间、返回的数据类型（JSON、HTML、流媒体等类型），以及服务器要在客户端保存的 Cookie 等信息。发送完响应头后，服务器就可以继续发送响应体的数据，通常，响应体就包含了 HTML 的实际内容。

**2. 断开连接：**通常情况下，一旦服务器向客户端返回了请求数据，它就要关闭 TCP 连接。不过如果浏览器或者服务器在其头信息中加入了： Connection:Keep-Alive，那么 TCP 连接在发送后将仍然保持打开状态，这样浏览器就可以继续通过同一个 TCP 连接发送请求。保持 TCP 连接可以省去下次请求时需要建立连接的时间，提升资源加载速度。

**3. 重定向：**到这里似乎请求流程快结束了，不过还有一种情况，比如当你在浏览器中打开 geekbang.org 后，你会发现最终打开的页面地址是 www.geekbang.org。这两个 URL 之所以不一样，是因为涉及到了一个重定向操作。

从图中可以看到，响应行返回的状态码是 301，状态 301 就是告诉浏览器，我需要重定向到另外一个网址，而需要重定向的网址正是包含在响应头的 Location 字段中，接下来，浏览器获取 Location 字段中的地址，并使用该地址重新导航，这就是一个完整重定向的执行流程。

为什么很多站点第二次打开速度会很快？

如果第二次页面打开很快，主要原因是第一次加载页面过程中，缓存了一些耗时的数据。那么，哪些数据会被缓存呢？从上面介绍的核心请求路径可以发现，DNS 缓存和页面资源缓存这两块数据是会被浏览器缓存的。其中，DNS 缓存比较简单，它主要就是在浏览器本地把对应的 IP 和域名关联起来。下面是浏览器资源缓存处理的过程：

登录状态是如何保持的？

用户打开登录页面，在登录框里填入用户名和密码，点击确定按钮。点击按钮会触发页面脚本生成用户登录信息，然后调用 POST 方法提交用户登录信息给服务器。

服务器接收到浏览器提交的信息之后，查询后台，验证用户登录信息是否正确，如果正确的话，会生成一段表示用户身份的字符串，并把该字符串写到响应头的 Set-Cookie 字段里，如Set-Cookie: UID=3431uad，然后把响应头发送给浏览器。

浏览器在接收到服务器的响应头后，开始解析响应头，如果遇到响应头里含有 Set-Cookie 字段的情况，浏览器就会把这个字段信息保存到本地。比如把UID=3431uad保持到本地。

当用户再次访问时，浏览器会发起 HTTP 请求，但在发起请求之前，浏览器会读取之前保存的 Cookie 数据，并把数据写进请求头里的 Cookie 字段里，Cookie: UID=3431uad，然后浏览器再将请求头发送给服务器。

服务器在收到 HTTP 请求头数据之后，就会查找请求头里面的“Cookie”字段信息，当查找到包含UID=3431uad的信息时，服务器查询后台，并判断该用户是已登录状态，然后生成含有该用户信息的页面数据，并把生成的数据发送给浏览器。

浏览器在接收到该含有当前用户的页面数据后，就可以正确展示用户登录的状态信息了。

导航流程：从输入URL到页面展示，这中间发生了什么？

首先，浏览器进程接收到用户输入的 URL 请求，浏览器进程便将该 URL 转发给网络进程。

然后，在网络进程中发起真正的 URL 请求。

接着网络进程接收到了响应头数据，便解析响应头数据，并将数据转发给浏览器进程。

浏览器进程接收到网络进程的响应头数据之后，发送“提交导航 (CommitNavigation)”消息到渲染进程；

渲染进程接收到“提交导航”的消息之后，便开始准备接收 HTML 数据，接收数据的方式是直接和网络进程建立数据管道；

最后渲染进程会向浏览器进程“确认提交”，这是告诉浏览器进程：“已经准备好接受和解析页面数据了”。

浏览器进程接收到渲染进程“提交文档”的消息之后，便开始移除之前旧的文档，然后更新浏览器进程中的页面状态。

从输入 URL 到页面展示

**1. 用户输入：**当用户在地址栏中输入一个查询关键字时，地址栏会判断输入的关键字是搜索内容，还是请求的 URL。如果是搜索内容，地址栏会使用浏览器默认的搜索引擎，来合成新的带搜索关键字的 URL。如果判断输入内容符合 URL 规则，比如输入的是 time.geekbang.org，那么地址栏会根据规则，把这段内容加上协议，合成为完整的 URL，如 time.geekbang.org。

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

**2. URL 请求过程：**浏览器进程会通过进程间通信（IPC）把 URL 请求发送至网络进程，网络进程接收到 URL 请求后，会在这里发起真正的 URL 请求流程。首先，网络进程会查找本地缓存是否缓存了该资源。如果有缓存资源，那么直接返回资源给浏览器进程；如果在缓存中没有查找到资源，那么直接进入网络请求流程。这请求前的第一步是要进行 DNS 解析，以获取请求域名的服务器 IP 地址。如果请求协议是 HTTPS，那么还需要建立 TLS 连接。

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

服务器接收到请求信息后，会根据请求信息生成响应数据（包括响应行、响应头和响应体等信息），并发给网络进程。等网络进程接收了响应行和响应头之后，就开始解析响应头的内容了。在接收到服务器返回的响应头后，网络进程开始解析响应头，如果发现返回的状态码是 301 或者 302，那么说明服务器需要浏览器重定向到其他 URL。这时网络进程会从响应头的 Location 字段里面读取重定向的地址，然后再发起新的 HTTP 或者 HTTPS 请求，一切又重头开始了。

URL 请求的数据类型，有时候是一个下载类型，有时候是正常的 HTML 页面，那么浏览器是如何区分它们呢？答案是 Content-Type。Content-Type 是 HTTP 头中一个非常重要的字段，它告诉浏览器服务器返回的响应体数据是什么类型，然后浏览器会根据 Content-Type 的值来决定如何显示响应体的内容。如果 Content-Type 字段的值被浏览器判断为下载类型，那么该请求会被提交给浏览器的下载管理器，同时该 URL 请求的导航流程就此结束。但如果是 HTML，那么浏览器则会继续进行导航流程。

**3. 准备渲染进程：**Chrome 的默认策略是，每个标签对应一个渲染进程。但如果从一个页面打开了另一个新页面，而新页面和当前页面属于同一站点（根域名（例如，geekbang.org）和协议（例如，https:// 或者 http://）相同）的话，那么新页面会复用父页面的渲染进程。官方把这个默认策略叫 process-per-site-instance。

**4. 提交文档：**所谓提交文档，就是指浏览器进程将网络进程接收到的 HTML 数据提交给渲染进程，具体流程是这样的：首先当浏览器进程接收到网络进程的响应头数据之后，便向渲染进程发起“提交文档”的消息；渲染进程接收到“提交文档”的消息后，会和网络进程建立传输数据的“管道”；等文档数据传输完成之后，渲染进程会返回“确认提交”的消息给浏览器进程；浏览器进程在收到“确认提交”的消息后，会更新浏览器界面状态，包括了安全状态、地址栏的 URL、前进后退的历史状态，并更新 Web 页面。

**5. 渲染阶段：**一旦文档被提交，渲染进程便开始页面解析和子资源加载了，一旦页面生成完成，渲染进程会发送一个消息给浏览器进程，浏览器接收到消息后，会停止标签图标上的加载动画。至此，一个完整的页面就生成了。

渲染流程：HTML、CSS和JavaScript是如何变成页面的

按照渲染的时间顺序，流水线可分为如下几个子阶段：构建DOM树、样式计算、布局阶段、分层、绘制、分块、光栅化和合成。

构建DOM树

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

DOM和HTML内容几乎是一样的，但是和HTML不同的是，DOM是保存在内存中的树状结构，可以通过JavaScript来查询或修改其内容。

如何通过JavaScript来修改DOM的内容？在控制台中输入：

document.getElementsByTagName(“p”)[0].innerText = “black”

执行了这段修改第一个<p>标签的JavaScript代码后，DOM的第一个p节点的内容就被修改，同时页面中的内容也被修改了。

样式计算

样式计算的目的是为了计算出DOM节点中每个元素的具体样式，这个阶段大体可分为三步来完成。

1. 把CSS转换为浏览器能够理解的结构。

CSS样式来源主要有三种：

通过link引用的外部CSS文件
<style>标记内的 CSS
元素的style属性内嵌的CSS
和HTML文件一样，浏览器也是无法直接理解这些纯文本的CSS样式，所以当渲染引擎接收到CSS文本时，会执行一个转换操作，将CSS文本转换为浏览器可以理解的结构——styleSheets。

2. 转换样式表中的属性值，使其标准化。

CSS文本中有很多属性值，如2em、blue、bold，这些类型数值不容易被渲染引擎理解，所以需要将所有值转换为渲染引擎容易理解的、标准化的计算值，这个过程就是属性值标准化。

那标准化后的属性值是什么样子的？

3. 计算出DOM树中每个节点的具体样式

首先是CSS继承。CSS继承就是每个DOM节点都包含有父节点的样式。

从图中可以看出，所有子节点都继承了父节点样式。比如body节点的font-size属性是20，那body节点下面的所有节点的font-size都等于20。

样式计算过程中的第二个规则是样式层叠。层叠是CSS的一个基本特征，它是一个定义了如何合并来自多个源的属性值的算法。它在CSS处于核心地位，CSS的全称“层叠样式表”正是强调了这一点。

布局阶段

现在，我们有DOM树和DOM树中元素的样式，但这还不足以显示页面，因为我们还不知道DOM元素的几何位置信息。那么接下来就需要计算出DOM树中可见元素的几何位置，我们把这个计算过程叫做布局。

Chrome在布局阶段需要完成两个任务：创建布局树和布局计算。

1. 创建布局树

为了构建布局树，浏览器大体上完成了下面这些工作

遍历DOM树中的所有可见节点，并把这些节点加到布局中；
而不可见的节点会被布局树忽略掉，如head标签下面的全部内容，再比如body.p.span这个元素，因为它的属性包含 dispaly:none，所以这个元素也没有被包进布局树。

2. 布局计算

在执行布局操作的时候，会把布局运算的结果重新写回布局树中，所以布局树既是输入内容也是输出内容，这是布局阶段一个不合理的地方，因为在布局阶段并没有清晰地将输入内容和输出内容区分开来。针对这个问题，Chrome团队正在重构布局代码，下一代布局系统叫LayoutNG，试图更清晰地分离输入和输出，从而让新设计的布局算法更加简单。

分层

因为页面中有很多复杂的效果，如一些复杂的3D变换、页面滚动，或者使用z-indexing做z轴排序等，为了更加方便地实现这些效果，渲染引擎还需要为特定的节点生成专用的图层，并生成一棵对应的图层树（LayerTree）。

通常情况下，并不是布局树的每个节点都包含一个图层，如果一个节点没有对应的层，那么这个节点就从属于父节点的图层。如上图中的span标签没有专属图层，那么它们就从属于它们的父节点图层。但不管怎样，最终每一个节点都会直接或者间接地从属于一个层。

那么需要满足什么条件，渲染引擎才会为特定的节点创建新的层呢？**第一点，拥有层叠上下文属性的元素会被提升为单独的一层，明确定位属性的元素、定义透明属性的元素、使用CSS滤镜的元素等，都拥有层叠上下文属性。**第二点，需要剪裁（clip）的地方也会被创建为图层。

图层绘制

在完成图层树的构建之后，渲染引擎会对图层树中的每个图层进行绘制。渲染引擎会把一个图层的绘制拆分成很多小的绘制指令，然后再把这些指令按照顺序组成一个待绘制列表。绘制列表中的指令其实非常简单，就是让其执行一个简单的绘制操作，比如绘制粉色矩形或者黑色的线等。而绘制一个元素通常需要好几条绘制指令，因为每个元素的背景、前景、边框都需要单独的指令去绘制。所以在图层绘制阶段，输出的内容就是这些待绘制列表。