以Chrome 为代表的浏览器架构详解

1.前言

理解浏览器工作原理，我们可以先宏观其次微观的角度去学习，了解浏览器大体架构，再从架构中的某一层重点去学习。比如说我们经常讨论到的页面的渲染机制，我们可能就需要去看浏览器渲染进程这方面的知识，那我们发现原来浏览器这么多进程，为啥要设计多进程的呢，单进程多线程满足不了功能么，有什么缺陷么？早期的浏览器确实是单进程的，那现在演进成什么样的架构了，每次架构的改变到底是为什么？所以我们带着问题去学习思考，让我们来揭开这层神秘的面纱。

2.敲黑板，补基础

当当当！前言我们提到单进程多线程等基础知识，我们现在来补一下基础

2.1 CPU与GPU

• CPU是计算机的中央处理器，是计算机的大脑，设计为通用、高效处理串行任务。CPU核心数量一般 4-64 核心，但每个核心的处理任务能力强，缓存大，适合处理逻辑复杂的任务。比如系统调度、软件运行等

• GPU是计算机的图形处理单元，设计为专注多个并行任务，一般核心数量极多，数千数万级别的流处理器，每个核心轻量化，擅于重复计算，适合处理数量大，相对独立的任务。比如处理图像数百万个像素的颜色等。现在随着 AI 的兴起，GPU 也拓展应用到通用计算（AI、大数据等），利用它并行处理任务的特点应用到非图形领域，成为现在这些领域的算力核心

• 在计算机和手机上启动应用的时候，应用会在操作系统的机制作用下在 CPU 和 GPU 上运行

2.2 进程

进程其实就是一个正在运行的程序实例 。当启动一个程序应用时，操作系统会分配一块私有内存供进程使用，进程之间的内容也是相互隔离的。当关闭应用时，进程消失，内存也会被操作系统释放出来。进程可以请求操作系统创建一个新的进程来执行其他的任务，那操作系统会进程分配新的内存。如果两个进程需要通信，就会需用进程间通信IPC来通信。

2.3 线程

线程是运行在进程中的一个任务，运行进程至少需要一个主线程。

2.4 进程与线程的关系

1. 线程是依赖进程进行启动和管理的
2. 进程中的一个线程出错，那么会导致整个进程崩溃
3. 线程之间共享进程中的数据

3.回正题，浏览器架构发展史

3.1 早期单进程时代

在 2008年之前，所用的功能模块（用户页面、渲染引擎、JavaScript 引擎等）都在一个进程里面，那这就是单进程时代的浏览器。

早期单进程浏览器也有它的优点：

1. 简单易维护：架构简单，容易代码维护
2. 资源开销低：因为只有一个进程，那没有进程间的通信，内存占用低

其实最主要的是它的缺点，如此多的功能模块运行在一个进程中，会带来一些问题：

1. 不稳定：任意一个线程出错，都会导致浏览器崩溃。在早期浏览器播放视频都会借助插件，插件是一个不稳定因素，还有在渲染引擎，如果遇到复杂的 js代码也会导致线程出错，从而导致浏览器崩溃
2. 不流畅：许多任务渲染模块、javascript运行和插件都运行在一个线程，例如 js 代码复杂运行时间长，会导致页面渲染不流畅导致整个浏览器卡死崩溃。
3. 不安全：网站上的恶意脚本或者插件可以无限制的获取系统操作权限，操作系统资源

3.2 多进程时代

多进程时代就是来解决单进程浏览器遇到的问题的，如下图所示是 2008年 chrome架构示意图，页面是单独运行在渲染进程中的，插件也是单独的进程，进程之间的通信通过 IPC 进行通信。

多进程架构主要是两大亮点多进程 和安全沙箱机制

1. 多进程解决不稳定问题和不流畅的问题：进程之间是隔离的，所以插件或者页面崩溃影响的只是当前页面或者插件，不会影响整个浏览器崩溃。渲染进程中每个标签页都是一个进程，也是将每个标签页隔离开来，也是同样的其中一个渲染页面崩溃不会导致整个浏览器受到影响。
2. *安全沙箱解决不安全的问题 ：渲染进程和插件进程都运行在沙箱中，沙箱可以看作是操作系统提供的一把锁，程序可以正常运行，但是权限访问受到严格限制，比如 不能在硬盘上随意写入和读取敏感数据，这就意味着即使恶意代码通过网页或者插件执行了，但是也不能突破操作系统的控制限制，这样极大提高了安全性

3.3 多站点隔离时代

多站点隔离架构是"每标签一个进程"改成"每站点一个进程"，意思是即使是同一个标签页，但是标签内嵌的 iframe 指向不同的站点，也会分配不同的渲染进程。

等等...这是为啥呢？不同的站点是协议 和主域名 不同，不去关心子域名 和端口 。而浏览器的同源策略，是源不同就会有一定的安全保护机制呢。浏览器不是有同源策略么，先大概了解一下浏览器的同源策略

如果两个 URL 的协议 、端口 （如果有指定的话）和主机都相同的话，则这两个 URL 是同源的

那对于不同源的情况下限制了什么？

• 限制DOM 访问 ：禁止不同源的页面之间使用 JS 操作对方的 DOM
  • 比如：test.com 页面通过iframe 嵌入了 login.com 某个登录页面，如果没有同源策略，那么 可以 使用JS 操作 登录页面的DOM 获取登录信息
• 限制数据访问 ：不同源的情况下使用XMLHttpRequest 或 fetch向请求服务器端发起的跨域请求，不能读取跨域请求的响应数据
  • http://localhost:3000 向 api.com 发送请求，服务器端是接收到请求，状态可能也是 200，但是浏览器端对于不同源的跨域请求会主动拦截，JS 是读取不到的，这样可以防止恶意请求向服务端请求数据，获取重要信息。
• 限制Cookie、LocalStorage 和 IndexedDB 访问 ：禁止不同源读取对方的 Cookie、LocalStorage 和 IndexedDB 数据。
  • 浏览器会保存源的登录凭证Cookie，如果没有同源策略，会获取到你的登录凭证伪造登录身份，登录网站等

同源策略是浏览器安全的重要基石，不同的站点还是需要分配新的渲染进程最主要的原因是 2007 年底，被发现 CPU 级别的漏洞Spectre 和Meltdown，让我们意识到必须用进程来隔离

多站点隔离的工作原理

浏览器会根据 URL 的站点动态地分配不同的渲染进程，并严格执行同源策略

解决的问题和存在的问题

• 解决问题 1：安全性达到了新高度，解决因为 CPU 级别的漏洞带来的风险，即使恶意代码从进程内部读取内存，也只能获取当前站点的数据，不会获取其他站点的数据，不同的站点使用进程来进行隔离
• 解决问题 2：加固 web的安全模型，操作系统的进程隔离和浏览器的同源策略完美契合，为 web安全提供了组底层的保障
• 存在的问题 1： 资源消耗急剧增加，如果一页面内嵌几十上百个不同站点的网站，就需要动态分配不同的渲染进程去处理，内存会达到前所未有的水平
• 存在的问题 2：进程间通信复杂性爆炸增长，页面内不同站点的 iframe通过 IPC与浏览器其他进程和渲染进程进行通信，IPC 的通信消息数量和复杂度指数级增长，对于架构设计也是巨大的挑战

3.4 面向服务架构

对于多站点隔离架构的存在的问题，去重新设计架构也是刻不容缓的事情，从 2016 年开始，架构已经开始逐步向面向服务架构一步一步去设计优化，现在的 chrome版本是 140，服务化已非常成熟，Device Service, Audio Service等都已就位，是支撑Project Fugu（让Web应用具备原生应用能力）的底层基石。下面是简单的服务架构图：

核心特点

原来的各种模块会被重构成服务，服务又可以在单独的进程中去运行，访问服务需要使用定义好的接口 ，通过Mojo框架的 IPC 进行通信，并且可以灵活地决定是运行在浏览器主进程中，还是拆分为独立的操作系统进程。Chrome 服务化示意图，其中显示了将不同服务移至多个进程和单个浏览器进程的操作

解决的问题和面临的挑战

• 解决的问题1：模块化与灵活性，服务可以按需组合和配置。在低功耗设备上，服务可以合并到浏览器进程中以节省内存；在高性能设备或需要更高稳定性的场景下，服务（如网络服务）可以拆分为独立进程，其崩溃和恢复不会影响浏览器UI。

• 解决的问题2：可维护性增强，代码高度解耦，团队可以独立开发和测试各自的服务。

• 存在的问题 1：架构复杂，对开和调试的门槛很高

• 存在的问题 2：IPC 通信无处不在，即使是浏览器内部通信也会变成进程间通信，带来性能上的延迟

4.总结

浏览器从一个简单的 HTML 查看器演变成一个堪比操作系统的复杂的平台，每一次的重新架构设计都是为了解决当前最紧急的问题，在每一次迭代变化中都有我们开发工程师学习的点，跟进步伐，每天学习一丢丢！