深入理解现代浏览器 阅读笔记之一

前言

很早之前就被@Uni)哥推荐了去看这篇Inside look at modern web browser，但是由于个人原因一直没有去看。终于等到暑假有一些时间来提升提升自己了，便马上开始学习这篇传世经典。

关于深入理解现代浏览器

这是由Mariko Kosaka于2018.9.5~2018.9.21在谷歌开发者博客发表的一系列共四篇博客。这四篇博客自底向上、由浅入深地介绍了以chrome为例的现代浏览器的基本运作原理。辅以可爱幽默的插画，这几篇博客至今都被许多前端工程师认为是学习浏览器基础知识的不二之选。

我的读书笔记

为了更好的阅读体验，本篇读书笔记我将分享我对于Inside look at modern web browser的第一部分的读书笔记。

计算机的核心是CPU和GPU

这一篇Mariko Kosaka从计算机的CPU、GPU的概念切入，先是介绍了一下这俩家伙主要是干啥的。

...A CPU core, pictured here as an office worker, can handle many different tasks one by one as they come in. ...

...Unlike CPU, GPU is good at handling simple tasks but across multiple cores at the same time. ...

而我们的操作系统主要是运行于由CPU、GPU等设备组成的硬件上，我们的应用程序又是运行于操作系统上的。用图片来描述的话大概就是这个样子。

而我们的浏览器就是作为一个应用程序运行在我们电脑上的。

在进程和线程上执行程序

我们在电脑上运行程序时，操作系统会创建进程，可以理解为进程是程序的一次执行。进程会根据需要被分配到所需的各种资源（CPU、内存等）。在一个进程内，还有可以有很多线程。这些线程不能直接从操作系统获取所需资源，但是同进程下的所有线程可以共享该进程的资源。进程就像一个池塘，而线程就像池塘里的🐟。

不同线程可以很轻松地通过共享的资源来通信，就像同一片池塘的鱼可以很轻松地相互沟通一样（虽然我不同鱼语，但是应该可以吧）。但是对于两块不同的池塘（进程）来说，可能需要一些外力才行。两个不同的进程可以通过IPC（Inter Process Communication）来进行通信。

关于进程和线程的概念在操作系统这门课程中已经讨论得非常多了，这里就不展开说了。

浏览器的架构

那么浏览器作为一个应用程序，自然也逃不出上述的抽象模型。但是也有所实际上一个应用程序在运行的时候会有很多不同的架构方案。

方案1

只采用一个进程，不同的任务安排给不同的线程去干。

方案2

采用多个进程，各个进程负责不同的任务，相互之间通过IPC通信。

两个方案各有优劣。方案一的优点是模型简单，比较适合用于小应用。缺点也很明显，如果程序出了什么问题需要重启进程时，整个应用的其他部分都会被波及。方案二的优点就刚好解决了方案一的缺点，如果某一个进程出了问题变得无响应了，重启该进程就好，其他的进程还是各干各的。缺点也很容易想到，就是模型变得复杂了。

那么浏览器是哪一种方案呢

作者在原文中提出

The important thing to note here is that these different architectures are implementation details. There is no standard specification on how one might build a web browser. One browser’s approach may be completely different from another.

不同的架构只是实现的细节不一样，没有一个标准来规定浏览器到底应该使用哪种方案，每个浏览器的实现方式可能都相去甚远。那么为了使浏览器能够更好地、更加稳定地为用户提供服务，chrome选择的是多进程的架构，也就是方案2。

更具体来说，chrome的架构最上层是浏览器的主进程（Browser Process），负责统筹管理浏览器的其他部分。往下走有负责GPU的GPU进程（GPU Process）、负责渲染页面的渲染器进程（Renderer Process）、负责浏览器的插件的插件进程（Plugin Process）等等。渲染器进程有很多，在可能的情况下，chrome会尽量为每一个tab标签页分配一个进程，以确保一个标签页卡死的时候不会影响到其他标签页的正常运行。

其中主要的进程以及对应的功能如下

实际上在chrome运行的过程中还有许多其他进程例如Extension process和utility processes。如果你想看看不同浏览器进程在你的电脑上的资源占用情况可以点击chrome右上角的三个点菜单的更多工具里找到任务管理器来查看。

chrome在多进程架构上的受益

标签页多进程的受益

就像上面说到的，在资源条件允许的情况下，chrome会尽可能为每个tab分配一个渲染器进程，确保一个进程崩溃的同时不会影响到别的进程负责的标签页，如下图所示。

浏览器不同部分多进程的受益

通过将浏览器的各个部分分隔到各个进程去执行也有好处，浏览器变得更加安全以及沙箱化。最主要的原因是操作系统对于不同进程的私有资源等有着严格的限制。这样一来，浏览器可以将不同的功能沙盒化分割到不同进程，相互独立地运行。举个例子，浏览器可以限制进程随意读取文件的能力。

也许还能优化优化

由于进程拥有各自的自由内存空间，他们通常有着一些相同的基础组件（例如v8引擎）的拷贝。这意味着如果能将一些页面放在同一个进程的不同线程中去处理的话，可以节省那些相同部分的拷贝的内存占用。所以为了节省内存，chrome给定了其最多能同时运行的进程的数量，这个数量的限制是根据设备的内存与CPU算力决定的。当chrome按照原本的一个tab一个进程的方式运行得非常吃力得时候，就会将多个来自相同站点的tab合并到一个进程中。

节省更多的内存——Chrome的服务化

Mariko Kosaka指出，chrome正在（当时正在）经历一次架构改革，将浏览器的各个组成部分以服务的方式去运行以便能够更好地将浏览器划分到各个进程又或者是集成到一个进程中。

大体的想法是，当Chrome在一个算力充沛的硬件上时，它就可以申请到很多教程，并将不同的服务分配到不同的进程中。效果就像上面我们讨论的那样，以一种非常稳定的方式运行。当Chrome运行在一个资源相对有所限制的设备上时，chrome将各个服务合并到一个进程中，以此减少运行时的内存开销。

站点隔离

站点隔离指的是chrome会为页面中的来自不同站点的iframe分配不同的渲染器进程。在上述的一tab一进程的模型是允许页面中的跨站iframe在同一个渲染器进程渲染的，也就是说两个不同的网站共享着一个进程的内存资源。然而浏览器的同源策略可绝不允许这种事情的发生，作为WEB中最核心的安全模型，浏览器的同源策略不允许一个网站在未将对方同意的情况下访问到别的网站的资源。越过同源策略一直是安全攻击的主要目标，而进程隔离是最有效的方法就是通过进程隔离的方法，因为这是操作系统层面的隔离方法。就算我们在应用层面下再多功夫，熔断时也可能会造成隔离失效。

为了实现站点隔离可是一个大工程。站点隔离可不像上面说的将不同页面分配到不同进程那么简单。他从最基本的层面改变了不同iframe之间的交互方式。打开一个有着在不同进程运行的iframe的页面的devtool意味着devtools需要实现一些远不止如此的工作来让他看起来与一般的页面没什么不同。甚至就连在页面中使用ctrl+f搜索都需要跨进程来搜索。这正是浏览器工程师们将站点隔离的发布作为重大里程碑的原因。

小结

读书笔记本该精简一些，可是感觉每一句话都那么重要，所以基本上就是全文翻译了。由于没有找到一个看上去没那么机翻味的中文版本，所以是啃的生肉，辅以一些机翻文章。所以上述的文字都是我基于我目前的所学所知来讲述的，如果有不准确或者压根不正确的地方，还请在讨论区指正QWQ。

相关文献：

Inside look at modern web browser (part 1) - Chrome Developers
深入现代浏览器（一） - 知乎 (zhihu.com)