As a front-end developer, I have always been interested in how browsers work. But there is always no time to learn, if you do not start will never have time, this sentence I think is the truth 😄. So I decided to get serious and start studying. For the browser working principle of learning is mainly a summary of learning geek time teacher Li Bing’s column class, interested can go to buy learning ah. Browser related content and knowledge is still quite a lot, so will be divided into many articles to learn records.
This time is to summarize the browser multi – process architecture related knowledge.
Opening a Chrome TAB requires at least those processes
Click on the options -> More Tools -> Task Manager menu in the upper right corner of chrome to open the Chrome Task Manager window, as shown below:
Before understanding the browser’s multi-process architecture first need to understand the “knowledge of process and thread”, this will help us better understand the following content, about process thread can refer to summary this article before, or more detailed: processes and threads, concurrent, parallel and serial, the difference between the synchronous and asynchronous, blocking and non-blocking
Let’s take a look at the evolution of the browser
The evolution of browsers
Single-process browser era
Single-process browser means that all the functional modules of the browser run in the same process. These modules include the network, plug-ins, JavaScript runtime environment, rendering engine and pages. Until 2007, all browsers were single-process. The architecture of the single-process browser is shown below:
unstable
- Early browsers needed plug-ins to implement powerful functions such as Web video and Web games, but plug-ins were the most problematic module and also ran in the browser process, so the accidental crash of one plug-in would cause the crash of the entire browser.
- The render engine module is also unstable, and often some complex JavaScript code can cause the render engine module to crash. Just like plug-ins, a crash of the rendering engine can crash the entire browser.
Not smooth
Single-threaded means that all page rendering modules, JavaScript execution environments, and plug-ins run on the same thread, but only one module can execute at a time if the JavaScript execution environment executes the following script
function freeze() {
while (1) {
console.log("freeze");
}
}
freeze();
Copy the codeBecause the script is an infinite loop, when it is executed, it monopolizes the entire thread, so that other modules running in the thread do not have a chance to be executed. Because all the pages in the browser are running in that thread, none of those pages have a chance to perform tasks, which can cause the entire browser to become unresponsive and stutter.
In addition to the scripts or plug-ins mentioned above that can make single-process browsers slow down, memory leaks on pages are also a major cause of single-process slowdowns. Usually the browser kernel is very complex, running a complex page and then closing the page, there will be a situation of memory can not be fully reclaimed, which leads to the problem is that the longer the use time, the higher the memory footprint, the slower the browser will become.
unsafe
- One is the plug-in, it can use C/C++ and other code written, through the plug-in can obtain any resources of the operating system, when you run a plug-in in the page also means that the plug-in can fully operate your computer. If it’s a malicious plug-in, it can release a virus, steal your passwords and raise security issues.
- One is page scripts, which can exploit vulnerabilities in the browser to gain access to the system. These scripts can also gain access to the system and do malicious things to your computer, causing security problems as well
Early multi-process architecture
Chrome pages run in a separate rendering process, and plugins run in a separate plug-in process, which communicates with each other through an IPC mechanism
How is instability resolved
Processes are isolated from each other, so when a page or plug-in crashes, it only affects the current page or plug-in process, not the browser or other pages
How to solve the problem of not flowing
JavaScript also runs in the renderer process, so even if JavaScript blocks the renderer process, it only affects the current rendering page, not the browser and other pages, whose scripts run in their own renderer process. So when we run the script in Chrome, the only thing that doesn’t respond is the current page.
How to solve the problem of insecurity
An added benefit of the multi-process architecture is the use of a secure sandbox, which you can think of as a lock placed on the process by the operating system. Programs in the sandbox can run, but they cannot write any data to your hard drive or read any data from sensitive locations, such as your documents and desktop. Chrome locks the plugin and renderer processes in a sandbox, so that even if a malicious program is executed in the renderer or renderer process, the malicious program cannot break through the sandbox to obtain system permissions.
Together, you can see the benefits and necessity of a multi-process architecture
Current multi-process architecture
The latest Chrome includes one main Browser process, one GPU process, one NetWork process, multiple rendering processes, and multiple plug-in processes.
Describe each of these processes separately
The browser process is responsible for interface display, user interaction, sub-process management, and storage.
The rendering process, whose core task is to turn HTML, CSS, and JavaScript into pages that users can interact with, runs both the Blink and JavaScript engine V8 typography engines. By default, Chrome creates a rendering process for each Tab Tab. For security reasons, renderers are run in sandbox mode.
GPU process The GPU was originally used to achieve the effect of 3D CSS. However, it was used to draw web pages and Chrome UI interfaces, making IT a common requirement for browsers. Finally, Chrome works on its multi-process architecture.
The web process, which is responsible for loading web resources on a page, used to run as a module in the browser process until recently, when it became a separate process.
The plug-in process is mainly responsible for running plug-ins. Plug-ins are prone to crash. Therefore, the plug-in process must be isolated to ensure that the plug-in process crash does not affect the browser and web page.
Now you can answer the question at the beginning of this article: why are there four processes when only one page is open? Because opening a page requires at least one network process, one browser process, one GPU process and one rendering process, a total of four. If the page you open has a plug-in running, you need to add one more plug-in process.
There are also problems with the multi-process model
- Higher resource usage because each process contains a copy of the common infrastructure (such as the JavaScript runtime environment) means that the browser consumes more memory resources.
- More complex architectures browsers have high coupling between modules, poor scalability and other problems, resulting in the current architecture has been difficult to adapt to new requirements.
The future of service-oriented architecture
In order to solve these problems, in 2016, the Chrome official team designed a new Chrome Architecture using the idea of “Services Oriented Architecture” (SOA). In other words, the overall Chrome architecture will move toward the “service-oriented architecture” of modern operating systems, where the various modules will be reorganized into separate services, each of which can run in a separate process. Access to services must use defined interfaces and communicate via IPC to build a more cohesive, loosely-coupled system that is easy to maintain and expand, better meeting Chrome’s goals of simplicity, stability, speed, and security.
Chrome eventually reconstructs UI, database, files, devices, and network modules into basic services, similar to operating system underlying services. Here is a diagram of Chrome’s “Service-oriented Architecture” process model
Chrome also offers a flexible architecture that allows basic services to run in multi-process mode on powerful devices, but on resource-constrained devices (see figure below), Chrome can consolidate many services into a single process to save memory footprint.
Tips
- Even with today’s multi-process architecture, I occasionally encounter a situation where a single page freezes and eventually crashes, causing all pages to crash. What is the reason?
Chrome's default strategy is one render process per TAB. However, if a new page is opened from a page and belongs to the same site as the current page, the new page will reuse the parent page's rendering process. Officially, this default policy is called process-per-site-instance. To put it bluntly, if several pages match the same site, they will be assigned to a rendering process. So, in this case, if a page crashes, it will cause pages on the same site to crash at the same time because they are using the same rendering process. Why let them run in a process? Because within A rendering process, they share the JS execution environment, meaning that page A can execute scripts directly from page B. Because it is the same site, so there is this demand.Copy the code- Does a single-process browser open multiple pages and only have one render thread? Doesn’t it make more sense to open one thread per page?
Due to the lag, domestic browsers began to try to support page multi-threading, that is, let part of the page run in a separate thread, running in a separate thread, which means that each thread has a separate JavaScript execution environment, and Cookie environment, at this time the problem comes: For example, the page of site A logs in to A website, saves some Cookie data to disk, and then saves part of Session data in the current thread environment. Because the Session does not need to be saved to disk, the Session will only be saved in the current thread environment. At this time, open the page of another site A. Assuming that the page is in another thread, it first reads the Cookie information on the hard disk. However, because the Session information is stored in another thread, it cannot be read directly, so it needs to realize A Session synchronization problem. Because IE does not have the source code, so the implementation is very air crash, domestic browser took a long time to solve this problem. The Session problem is fixed, but the problem of suspended animation still exists, because the process uses a window that is attached to the browser's main window, so they share a message loop, which we'll talk about in more detail later, which means if that window freezes. It can also cause the entire browser to freeze. Another trick made by domestic browsers is to make the page into a separate popover. If the page is stuck, the popover is hidden. Why does a page fake death in Chrome not affect the main window? This is because Chrome outputs the actual image, and the browser then pastes the image to its own window. In Chrome's rendering process, there is no rendering window, only the image output, if stuck, at most the image will not be updated.Copy the code- If two pages are open, how many processes are there? Is it 1 web process, 1 browser process, 1 GPU process, and 2 renderers in total?
This is usually five, but there are many other cases: 1: Iframes run in a separate process if there is one on the page! 2: If there is a plugin in the page, the plugin also needs to start a separate process! 4. If two pages belong to the same site, and page B is opened from page A, they share a common rendering process, which can be viewed through Chrome's task manager.Copy the code- How do you locate the cause of a page crash in your browser?
To locate the page crash page, we should first understand the factors that may cause the page crash, according to my actual statistics, there are mainly the following three convenient factors: First of all, the main factor is that some third-party plug-ins inject the browser or page process, blocking some normal operation of the web page and causing the page or browser crash, such as some anti-virus software, or guardian software, or some traffic hijacking software. The second factor is plugins, which are prone to crash, but usually only affect their own processes, although our previous statistics show that there is a small probability of page crashes, but the overall data is fine. On the other hand, the use of plug-ins has been declining, so plug-ins are not a big problem. The third factor is browser bugs such as the rendering engine, JavaScript engine, etc., but statistically the number of crashes caused by this type of factor is also decreasing, and the factors that cause the problem are changing as the browser is updated. So it is very difficult to give a page crash cause directly, and it is also very difficult to track the crash cause directly from the JS level. To mention one method I used before, that is to use JS to count whether a page crashes. Such statistics are not 100% ready, but you can roughly judge whether a page crashes through the data, and then find some typical user environments to conduct field investigations.Copy the code- Why couldn’t single-process browsers use security sandboxes at the time?
If a process uses the security sandbox, its permissions on the operating system are limited. For example, the process cannot read or write files in certain locations that are required by the main browser process. Therefore, the security sandbox cannot be applied to the main browser process.Copy the code