Understanding the multi-process architecture of Chrome browser
Posted May 27, 2020 • 6 min read
The reason to introduce the multi-process architecture of the Chrome browser is because this is the basis for understanding the behavior of the browser and the first article in this column. I hope you can lay a good foundation
Before we continue, let's briefly talk about the two basic concepts throughout this article-threads and processes
Thread vs process
Multiple threads can process tasks in parallel, but threads cannot exist alone, they are started and managed by processes.
What is a process? A process is a running instance of a program. The detailed explanation is that when a program is started, the operating system creates a memory for the program, which is used to store code, data running in it, and a main thread to perform tasks. We call such a running environment a process.
In summary, the relationship between processes and threads has the following four characteristics.
- Any thread in the process that executes an error will cause the entire process to crash
- Share data in the process between threads.
- When a process is closed, the operating system will reclaim the memory occupied by the process. When a process exits, the operating system will reclaim all the resources requested by the process; even if any of the threads cause a memory leak due to improper operation, when the process exits, the memory will be correctly reclaimed.
- The content between processes is isolated from each other. Process isolation is a technology to protect processes in the operating system from interfering with each other. Each process can only access the data it owns, which avoids the situation where process A writes data to process B. It is precisely because the data between processes is strictly isolated, so if a process crashes or hangs, it will not affect other processes. If data communication is required between processes, then the mechanism for inter-process communication(IPC) needs to be used.
Single process browser
In fact, as early as 2007, browsers on the market were single-process. That is to say
So many function modules running in a process will definitely cause the browser to be unstable, unsmooth and insecure. Below we will analyze the reasons for these problems.
Early browsers needed plug-ins to implement various powerful functions such as Web videos, Web games, etc. But plug-ins are the most prone to problems, and they are also running in the browser process, so an accidental crash of a plug-in will cause The entire browser crashed.
Problem 2:Not smooth
Only one module can execute at a time. If there is an infinite loop script running in a single-process browser page, it will monopolize the entire thread, so that other modules running in the thread have no chance to be executed. Because all the pages in the browser are running in this thread, these pages have no chance to perform tasks, which will cause the entire browser to lose response.
Here, the reason can still be explained from two aspects of plug-ins and page scripts.
The plug-in can be written in code such as C/C ++. Through the plug-in, you can get any resources of the operating system. When you run a plug-in on the page, it means that the plug-in can fully operate your computer. If it is a malicious plug-in, it can release viruses, steal your account passwords, and cause security problems.
As for page scripts, it can obtain system permissions through browser vulnerabilities. These scripts can also do malicious things to your computer after obtaining system permissions, which can also cause security problems.
These are the shortcomings of the browser at the time, unstable, not smooth, and unsafe. Let's take a look at the modern multi-process browser
The latest Chrome browsers currently include:1 browser(Browser) main process, 1 GPU process, 1 network(NetWork) process, multiple rendering processes and multiple plug-in processes.
Let's analyze the functions of these processes one by one.
- Browser process. Mainly responsible for interface display, user interaction, sub-process management, and provides storage and other functions.
- GPU process. In fact, when Chrome was first released, there was no GPU process. The original intention of using GPU is to achieve the effect of 3D CSS, but then the web page and Chrome UI interface have chosen to use GPU to draw, which makes GPU a common demand of browsers. Finally, Chrome also introduced GPU processes on its multi-process architecture.
- Network process. It is mainly responsible for loading the network resources of the page. Previously, it was run as a module in the browser process. Until recently, it became independent and became a separate process.
- Plug-in process. It is mainly responsible for the operation of the plug-in. Because the plug-in is easy to crash, it needs to be isolated by the plug-in process to ensure that the plug-in process will not affect the browser and the page.
However, everything has two sides. Although the multi-process architecture improves the stability, fluency and security of the browser, it also brings some problems:
- More complex system architecture. The problems of high coupling and poor scalability between browser modules will make it difficult for the current architecture to adapt to new requirements.
For the above two issues, the Chrome team has been looking for a flexible solution that can solve the problem of high resource consumption and complex system architecture.
Browse Context Group
As mentioned above, in some cases, the browser will allow multiple Tab pages to run directly in the same rendering process. So what are the specific situations?
If another new tab b is opened from one tab a, and a and b belong to the same site, then b reuses the rendering process of a. The official called this default strategy process-per-site-instance.
We define "same site" as the root domain name(such as juejin.im) plus the protocol(such as https://or http://), and also includes all subdomains and different ports under the root domain name, all satisfying Conditional tabs are on the same site.
Suppose, now I open any new article from the tab of Nuggets( https://juejin.im/timeline) )( https://juejin .im/post/5ec233 ... ) tab page, because these two tab pages belong to the same site(same protocol, same root domain name), so they will share the same A rendering process. You can see the screenshot of the Chrome task manager below, they share the 11732 rendering process:
However, if we open these two tabs separately, for example, first open the Nuggets tab, and then open the article tab, then we can see that these two tabs use two different rendering processes.
Since both are the same site, why open the B tab from the A tab, will use the same rendering process, and open the two tabs separately, and will use different rendering processes?
Links between tabs
Use tags to establish a connection with new tags, this way we are most familiar with, such as the following jump links
In this way, the link jumped to their window.opener will point to the source tab, so we can say that the two tabs are connected.
new_window = window.open(" https://juejin.im/post/5ec23371f265da7bda41555e" )
In this way, new \ _window can be used to control the new tab in the current tab, and window.opener can also be used to control the current tab in the new tab. So we can also say that if the B tab is opened from the A tab through window.open, then the A and B tabs are also connected.
In fact, the new tabs opened through the above two methods, no matter whether the two tabs belong to the same site, they can establish a connection through opener, so there is a connection between them. In the WhatWG specification, this type of tabs with interconnected relationships is called a browsing context group.
Chrome will assign tags belonging to the same site in the browsing context group to the same rendering process. This is because if a group of tabs are in the same browsing context group and belong to the same site, they may need to Execute the script in the other party's tab. Therefore, they must run in the same rendering process.