浏览器原理 01 # Chrome架构:仅仅打开了1个页面,为什么有4个进程?

简介: 浏览器原理 01 # Chrome架构:仅仅打开了1个页面,为什么有4个进程?

说明

浏览器工作原理与实践专栏学习笔记


进程和线程

什么是并行处理:计算机中的并行处理就是同一时刻处理多个任务

线程是不能单独存在的,它是由进程来启动和管理的。


进程

一个进程就是一个程序的运行实例。

启动一个程序的时候,操作系统会为该程序创建一块内存,用来存放代码、运行中的数据和一个执行任务的主线程,我们把这样的一个运行环境叫进程



20201027183641239.png


线程是依附于进程的,而进程中使用多线程并行处理能提升运算效率。



进程和线程之间的关系


1、进程中的任意一线程执行出错,都会导致整个进程的崩溃。

2、线程之间共享进程中的数据。


2020102718375610.png

3、当一个进程关闭之后,操作系统会回收进程所占用的内存。

4、进程之间的内容相互隔离。




单进程浏览器时代

单进程浏览器是指浏览器的所有功能模块都是运行在同一个进程里。

单进程浏览器的架构如下图所示:

20201027183853395.png


问题:

  • 不稳定
  • 不流畅
  • 不安全



多进程浏览器时代


早期多进程架构

2008 年 Chrome 发布时的进程架构

20201027183917240.png


进程之间是通过 IPC 机制进行通信

进程是相互隔离:解决不稳定的问题。

JavaScript 也是运行在渲染进程中:即使 JavaScript 阻塞了渲染进程,影响到的也只是当前的渲染页面

安全问题:采用多进程架构的额外好处是可以使用安全沙箱



目前多进程架构


20201027183935830.png


最新的 Chrome 浏览器包括:1 个浏览器(Browser)主进程、1 个 GPU 进程、1 个网络(NetWork)进程、多个渲染进程和多个插件进程。


1、浏览器进程。

主要负责界面显示、用户交互、子进程管理,同时提供存储等功能。

2、渲染进程。


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


3、GPU 进程。

   其实,Chrome 刚开始发布的时候是没有 GPU 进程的。而 GPU 的使用初衷是为了实现 3D CSS 的效果,只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制,这使得 GPU 成为浏览器普遍的需求。最后,Chrome 在其多进程架构上也引入了 GPU 进程。


4、网络进程。

   主要负责页面的网络资源加载,之前是作为一个模块运行在浏览器进程里面的,直至最近才独立出来,成为一个单独的进程。


5、插件进程。

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


打开 1 个页面至少需要 1 个网络进程、1 个浏览器进程、1 个 GPU 进程以及 1 个渲染进程,共 4 个;如果打开的页面有运行插件的话,还需要再加上 1 个插件进程。


多进程模型带来了一些问题:


   更高的资源占用

   更复杂的体系架构




未来面向服务的架构


在 2016 年,Chrome 官方团队使用“面向服务的架构”(Services Oriented Architecture,简称 SOA)的思想设计了新的 Chrome 架构。


下面是 Chrome“面向服务的架构”的进程模型图:


20201027183957713.png


资源受限的设备上

20201027184017378.png



总结:

早期浏览器:


不稳定(单独进程)

不流畅(单独进程)

不安全(沙箱)

早期多进程架构:

主进程 渲染进程 插件进程

现代多进程架构:

主进程 渲染进程 插件进程 GPU进程 网络进程

未来:

面向服务架构


问题解答

1、感觉挺好奇的,单进程浏览器开多个页面,渲染线程也只有一个吗?感觉一个页面开一个线程不是更合理吗?

作者回复: 之前回答的有点笼统,下面是我整理过后的回答:
首先这个问题提的很好,我们从IE6开始讲起,IE6时代,浏览器是单进程的,所有页面也都是运行在一个主线程中的,当时IE6就是这样设计,而且此时的IE6是单标签,也就是说一个页面一个窗口。
这时候,国内有很多国产浏览器,都是基于IE6来二次开发的,而IE6原生架构就是所有页面跑在单线程里面的,意味着,所有的页面都共享着同一套JavaScript运行环境,同样,对于存储Cookie也都是在一个线程里面操作的。
而且这些国产浏览器由于需要,都采用多标签的形式,所以其中的一个标签页面的卡顿都会影响到整个浏览器。
基于卡顿的原因,国内浏览器就开始尝试支持页面多线程,也就是让部分页面运行在单独的线程之中,运行在单独的线程之中,意味着每个线程拥有单独的JavaScript执行环境,和Cookie环境,这时候问题就来了:
比如A站点页面登陆一个网站,保存了一些Cookie数据到磁盘上,再在当前线程环境中保存部分Session数据,由于Session是不需要保存到硬盘上的,所以Session只会保存在当前的线程环境中。这时候再打开另外一个A站点的页面,假设这个页面在另外一个线程中里面,那么它首先读取硬盘上的Cookie信息,但是,由于Session信息是保存在另外一个线程里面的,无法直接读取,这样就要实现一个Session同步的问题,由于IE并没有源代码,所以实现起来非常空难,国内浏览器花了好长一点时间才解决这个问题的。
Session问题解决了,但是假死的问题依然有,因为进程内使用了一个窗口,这个窗口是依附到浏览器主窗口之上的,所以他们公用一套消息循环机制,消息循环我们后面会详细地讲,这也就意味这一个窗口如果卡死了。也会导致整个浏览器的卡死。
国产浏览器又出了一招,就是把页面做成一个单独的弹窗,如果这个页面卡死了,就把这个弹窗给隐藏掉。
这里还要提一下为什么Chrome中的一个页面假死不会影响到主窗口呢?
这是因为chrome输出的实际上图片,然后浏览器端把图片贴到自己的窗口上去,在Chrome的渲染进程内,并没有一个渲染窗口,输出的只是图片,如果卡住了,顶多图片不更新了。
国产浏览器这一套技术花了四五年时间,等这套技术差不多成熟时,Chrome发布了 :(



2、老师好,我有个疑问,Chrome排版引擎现在是blink,这一点从哪里可以看到呢?我在76版本Chrome的navigator属性值里只看到了AppleWebkit,不理解这是为什么?

作者回复: 你说的是UserAgent,又称为UA,UA是浏览器的身份证,通常,在发送HTTP请求时,UA会附带在HTTP的请求头中user-agent字段中,这样服务器就会知道浏览器的基础信息,然后服务器会根据不同的UA返回不同的页面内容,比如手机上返回手机的样式,PC就返回PC的样式。
你也可以在浏览器的控制台中输入:
navigator.userAgent
来查看当前浏览器的UA信息。
FireFox中的打印的信息是:
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0"
Chrome中打印的信息是:
"Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Mobile Safari/537.36"
安卓系统中的Chrome浏览器:
"Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Mobile Safari/537.36"
我们知道了服务器会根据不同的UA来针性的设计不同页面,所以当出了一款新浏览器时,他如果使用自己独一无二的UA,那么之前的很多服务器还需要针对他来做页面适配,这显然是不可能的,比如Chrome发布时他会在他的UA中使用“Mozilla” ,“AppleWebKit”,等关键字段,用来表示他同时支持Mozilla和AppleWebKit,然后再在最后加上他自己的标示,如Chrome/xxx。
这就解释了为什么你查看的信息中含有WebKit字样。



3、请问老师,如果打开了 2个页面,会有几个进程呢?是 1 个网络进程、1 个浏览器进程、1 个 GPU 进程以及 2个渲染进程,共 5个吗?这些进程是可以在浏览器开发者中被实际观察到的吗?

作者回复: 通常情况下会是五个,但是有很多其他情况:
1:如果页面里有iframe的话,iframe也会运行在单独的进程中!
2:如果页面里有插件,同样插件也需要开启一个单独的进程!
3:如果你装了扩展的话,扩展也会占用进程
4:如果2个页面属于同一站点的话,并且从a页面中打开的b页面,那么他们会公用一个渲染进程
这些进程都可以通过chrome的任务管理器来查看。




相关实践学习
部署Stable Diffusion玩转AI绘画(GPU云服务器)
本实验通过在ECS上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。
目录
相关文章
|
22天前
|
存储 缓存 网络协议
计算机网络常见面试题(二):浏览器中输入URL返回页面过程、HTTP协议特点,GET、POST的区别,Cookie与Session
计算机网络常见面试题(二):浏览器中输入URL返回页面过程、HTTP协议特点、状态码、报文格式,GET、POST的区别,DNS的解析过程、数字证书、Cookie与Session,对称加密和非对称加密
|
24天前
|
域名解析 缓存 网络协议
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
|
5月前
|
前端开发 安全 UED
【项目实战】从终端到浏览器:实现 ANSI 字体在前端页面的彩色展示
在学习和工作中,我们经常需要使用日志来记录程序的运行状态和调试信息。而为了更好地区分不同的日志等级,我们可以使用不同的颜色来呈现,使其更加醒目和易于阅读。 在下图运行结果中,我们使用了 colorlog 库来实现彩色日志输出。通过定义不同日志等级对应的颜色,我们可以在控制台中以彩色的方式显示日志信息。例如,DEBUG 级别的日志使用白色,INFO 级别的日志使用绿色,WARNING 级别的日志使用黄色,ERROR 级别的日志使用红色,CRITICAL 级别的日志使用蓝色。
|
5月前
|
Web App开发 XML 开发框架
技术心得记录:在IE浏览器中的奇怪页面表现
技术心得记录:在IE浏览器中的奇怪页面表现
56 0
|
6月前
|
安全
【进程通信】信号的捕捉原理&&用户态与内核态的区别
【进程通信】信号的捕捉原理&&用户态与内核态的区别
|
2月前
|
算法 调度 UED
操作系统中的进程管理:原理与实践
在数字世界的心脏跳动着无数进程,它们如同细胞一般构成了操作系统的生命体。本文将深入探讨进程管理的奥秘,从进程的诞生到成长,再到最终的消亡,揭示操作系统如何协调这些看似杂乱无章却又井然有序的活动。通过浅显易懂的语言和直观的比喻,我们将一起探索进程调度的策略、同步机制的重要性以及死锁问题的解决之道。准备好跟随我们的脚步,一起走进操作系统的微观世界,解锁进程管理的秘密吧!
67 6
|
3月前
|
网络协议 前端开发 JavaScript
浏览器加载网页的幕后之旅:从URL到页面展示详解
【8月更文挑战第31天】当在浏览器地址栏输入URL并回车后,一系列复杂过程随即启动,包括DNS解析、TCP连接建立、HTTP请求发送、服务器请求处理及响应返回,最后是浏览器页面渲染。这一流程涉及网络通信、服务器处理和客户端渲染等多个环节。通过示例代码,本文详细解释了每个步骤,帮助读者深入理解Web应用程序的工作机制,从而在开发过程中作出更优决策。
65 5
|
3月前
|
Linux API C语言
Linux源码阅读笔记02-进程原理及系统调用
Linux源码阅读笔记02-进程原理及系统调用
|
3月前
|
Android开发 iOS开发 C#
Xamarin.Forms:从零开始的快速入门指南——打造你的首个跨平台移动应用,轻松学会用C#和XAML构建iOS与Android通用界面的每一个步骤
【8月更文挑战第31天】Xamarin.Forms 是一个强大的框架,让开发者通过单一共享代码库构建跨平台移动应用,支持 iOS、Android 和 Windows。使用 C# 和 XAML,它简化了多平台开发流程并保持一致的用户体验。本指南通过创建一个简单的 “HelloXamarin” 应用演示了 Xamarin.Forms 的基本功能和工作原理。
90 0
|
4月前
|
Web App开发 JavaScript 前端开发
Chrome插件实现问题之最新的 Chrome 浏览器架构有什么新的改变吗
Chrome插件实现问题之最新的 Chrome 浏览器架构有什么新的改变吗
下一篇
无影云桌面