preface

Learning resources from Geek Time – Teacher Li Bing “Browser working principle and Practice”. Next, let’s check in every day

  • Day 01 Chrome architecture: Why 4 processes with only 1 page open?

What will you learn from reading this article?

This article looks at the evolution of the browser from the perspective of Chrome’s process architecture.

  1. Early browser
    • Instability (single process)
    • Not flowing (single process)
    • Unsafe (sandbox)
  2. Early multi-process architecture
  • Main process, renderer process, plug-in process
  1. Modern multi-process architecture
  • Main process, renderer, plug-in process, GPU process, network process
  1. In the future
  • Service-oriented Architecture

Processes and threads

Before I talk about processes and threads, I need to explain what parallel processing is, because understanding the relationship between processes and threads is a lot easier once you understand the concept of parallel processing.

What is parallel processing

Parallel processing in computers is processing multiple tasks at the same time. For example, we want to evaluate the values of the following three expressions and display the results.

A = 1+2
B = 20/5
C = 7*8
Copy the code

When writing code, we can break this process down into four tasks:

  • Task 1 is to calculate A=1+2;
  • Task 2 is to calculate B=20/5;
  • Task 3 is to calculate C=7*8;
  • Task 4 is to display the result of the final calculation.

Normally a program can be processed using a single thread, that is, each of the four tasks is executed in four steps in sequence.

What happens if you use multiple threads? The first step is to use three threads to execute the first three tasks simultaneously. Second, perform the fourth display task.

By comparison, you can see that it takes four steps to execute with a single thread, compared to two steps with multiple threads. Therefore, using parallel processing can greatly improve performance.

Threads vs. processes

Multithreading 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. When a program is started, the operating system creates a block of memory for the program, which is used to store code, running data and a main thread to perform tasks. We call such a running environment a process.

To give you a better idea of how this calculation works, take a look at the following comparison:

As can be seen from the figure, threads are attached to processes, and multi-threaded parallel processing in processes can improve computing efficiency.

In summary, the relationship between processes and threads has the following four characteristics.

  1. The failure of any thread in the process will cause the entire process to crash.

We can simulate the following scenario:

A = 1+2
B = 20/0
C = 7*8
Copy the code

When calculating the value of B, I changed the denominator of the expression to 0. When the thread executes B = 20/0, the thread will fail to execute because the denominator is 0, which will cause the whole process to crash. Of course, the results of the execution of the other two threads are also lost.

  1. Threads share data in a process.

As shown in the figure below, threads can read and write to the process’s common data.

As can be seen from the figure above, thread 1, thread 2, and thread 3 write the results of their execution to A, B, and C, respectively. Then thread 2 continues to read data from A, B, and C to display the results of their execution.

  1. When a process is shut down, the operating system reclaims the memory occupied by the process.

When a process exits, the operating system reclaims all the resources applied for by the process. Even if any of these threads leak memory due to improper operation, the memory will be properly reclaimed when the process exits. For example, the previous Internet Explorer browser supported a lot of plugins, and these plugins were prone to memory leaks, which meant that as long as the browser was open, memory usage could increase, but when the browser process was closed, all of this memory would be reclaimed by the system.

  1. The contents of the processes are isolated from each other.

Process isolation is A technique to protect each process from interfering with each other in the operating system. Each process can access only the data it owns, preventing process A from writing data to process B. Because data between processes is strictly isolated, a crash or hang of one process does not affect other processes. If there is a need for data communication between processes, then a mechanism for interprocess communication (IPC) is needed.

Single-process browser era

Now that we know about processes and threads, let’s take a look at the architecture of the single-process browser. As the name suggests, a single-process browser means that all the functional modules of the browser run in the same process, including 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:

With so many functional modules running in a single process, the result is a single-process browserUnstable, fluid and insecureIs a major factor in.

I will analyze the reasons for these problems one by one.

Problem 1: Instability

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.

In addition to plug-ins, 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.

Problem 2: Not flowing

As you can see from the “single-process browser architecture diagram” above, all render modules, JavaScript execution environments, and plug-ins for all pages run in the same thread, which means that only one module can be executed at a time.

For example, the following script for an infinite loop:

function freeze() {
  while (1) {
    console.log("freeze");
  }
}
freeze();
Copy the code

What do you think would happen if you ran this script on a single-process browser page?

Because 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. I’ll go further into the page event loop in a later module.

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.

Problem 3: Unsafe

Again, this can be explained in terms of plug-ins and page scripts.

Plug-ins can be written using C/C++ code, through plug-ins 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.

As for page scripts, they can gain access to the system through a vulnerability in the browser, and they can also do malicious things to your computer, which can also cause security problems.

These were the characteristics of browsers at the time. They were unstable, not smooth, and not secure. It’s a terrible history, and maybe you haven’t, but you can imagine this: When you’re opening multiple pages in your browser, and one page crashes or becomes unresponsive, the entire browser crashes or becomes unresponsive, and your email to your boss disappears with it?

Multi-process browser era

Early multi-process architecture

You can start by looking at the process architecture of Chrome when it was released in 2008.As you can see, 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 (dotted line).

Let’s see how we can solve the instability problem. 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 and other pages, which perfectly solves the problem that a page or plug-in crash can cause the entire browser to crash, which is unstable.

Let’s take a look at how the problem is solved. Also, JavaScript 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 are running in their own renderer process. So when we run the script in Chrome, the only thing that doesn’t respond is the current page.

The solution to the memory leak is even easier, because when a page is closed, the entire rendering process is closed, and the memory occupied by the process is then reclaimed by the system, which can easily solve the memory leak problem of the browser page.

Finally, let’s look at how the above two security problems are solved. 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.

Well, after analyzing the early Days of Chrome, you’ve seen the need for a multi-process architecture.

Current multi-process architecture

But Chrome is moving forward, and there are a lot of new changes to the current architecture. Let’s take a look at the latest Chrome process architecture, which you can refer to below:

As can be seen from the figure, the latest Chrome Browser includes: one main Browser process, one GPU process, one NetWork process, multiple rendering processes and multiple plug-in processes.

Let’s take a look at each of these processes one by one.

  • Browser process. It is mainly responsible for interface display, user interaction, sub-process management, and storage.
  • Render process. The core task is to turn HTML, CSS, and JavaScript into web pages that users can interact with. Both the typography engine Blink and JavaScript engine V8 run in this process. By default, Chrome creates a rendering process for each Tab Tab. For security reasons, renderers are run in sandbox mode.
  • Process of GPU. In fact, Chrome didn’t have a GPU process when it was first released. The original intention of using GPU was to achieve 3D CSS effect, but later the UI interface of web page and Chrome were drawn on GPU, which made GPU become a common requirement of browser. Finally, Chrome has introduced GPU processes on top of its multi-process architecture.
  • Network process. It is responsible for loading web resources on the page. It used to run as a module in the browser process until recently, when it became a separate process.
  • Plug-in process. It is mainly responsible for the running of plug-ins. Plug-ins are prone to crash. Therefore, plug-ins need to be isolated through the plug-in process to ensure that the plug-in process crash does not affect the browser and page.

At this point, you should now be able to answer the question at the beginning of this article: Why are there four processes with only one page 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.

However, every coin has two sides. While the multi-process model improves the stability, smoothness, and security of the browser, it also inevitably introduces some problems:

  • Higher resource usage. Because each process contains a copy of the common infrastructure (such as the JavaScript runtime environment), this means that the browser consumes more memory resources.
  • More complex architectures. Problems such as high coupling between browser modules and poor scalability lead to the current architecture has been difficult to adapt to new requirements.

For both of these issues, the Chrome team has been looking for an elastic solution that can address both high resource usage and complex architecture issues.

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. If you are interested in service-oriented architecture, you can do some research on the Internet.

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 is currently in the process of transitioning from the old architecture to a service-oriented one, which will be a long and iterative process.

Chrome is gradually building Chrome Foundation Service, which can be considered the “base” system services layer of the OPERATING system if you think of Chrome as a “portable OPERATING system.”

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.

On under-resourced devices, merge the service into the browser process.

Selection of answering questions

Same-site

Typically, one page uses one process, but there is a case called “same-site.” Specifically, we define “same-site” as the root domain (for example, geekbang.org) plus the protocol (for example, https:// or http://), It also contains all subdomain names and different ports under the root domain, such as the following three:

  • time.geekbang.org
  • www.geekbang.org
  • www.geekbang.org:8080

Both belong to the same site, because their protocol is HTTPS and the root domain name is geekbang.org. You may know the same origin policy, but there are some differences between the same site and the same origin policy, and here you need to understand that they are not the same thing.

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.

The id of the browser is UserAgent

UserAgent, also called UA, is the ID card of the browser. Usually, when sending HTTP requests, UA is attached to the User-Agent field in the HTTP request header, so that the server can know the basic information of the browser, and then the server will return different page contents according to different UA. For example, if the phone returns the phone style, the PC will return the PC style.

You can also view the UA information of the current browser by typing navigator. UserAgent in the browser console.

The message printed in FireFox reads: “Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; The rv: 68.0) Gecko / 20100101 Firefox / 68.0”

The message printed in Chrome reads: “Mozilla/5.0 (Linux; The Android 6.0. Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Mobile Safari/537.36”

Chrome on Android: “Mozilla/5.0 (Linux; The Android 5.0. Sm-g900p Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Mobile Safari/537.36”

We know that the server will be different according to different design of UA to needle page, so when the new browser, if he used his unique UA, then the need for him to do many of the server before the page adapter, this is clearly impossible, such as Chrome released he will use in his UA “Mozilla”, “AppleWebKit” and other key fields to indicate that he supports both Mozilla and AppleWebKit, and then adds his own logo at the end, such as Chrome/ XXX.

Locate the page crash problem

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. Mention a method used by the author before, that is to use JS to count whether the page crashes. Such statistics are not 100% prepared, but we can roughly judge whether the page crashes through the data, and then find some typical user environments to conduct field investigations.

At least four processes

The four processes mentioned in this article are required, but usually there are more processes, such as extension process, proxy process, iframe process, as well as some functions such as compression, video, audio, etc., depending on the computer environment, page environment of each person!

  1. If there is an iframe in the page, the iframe also runs in a separate process!
  2. If there is a plug-in in the page, the plug-in also needs to start a separate process!
  3. If you install an extension, the extension will also hog the process
  4. If two pages belong to the same site, and page B is opened from page A, they share a rendering process
  5. Chrome also has some helper processes that don’t show up in task Manager. For example, the pre-render process has an extra render process, which is enabled in advance and used directly when the render process is needed, thus saving the time to create the process!