Evolution of browser process architecture

preface

Have you ever had a plugin crash while using IE6 or IE7 or Firefox, and all of your open pages crashed? 😰
Have you ever opened your browser or some page and kept popping up a lot of malicious Windows that you didn’t want to open, so you had to manually cross them out one by one? 😤
Have you ever had to force the entire browser to shut down when you open a page and for some reason the whole browser freezes and can’t even press the close button? 🤔

If you’ve met any of these situations, we have a lot to talk about today. If you don’t, don’t worry. Today’s lesson will help you expand your horizons so that when you do meet, you won’t be confused.

Today’s topic is evolution of Browser Process Architecture, and you may be wondering what is browser process architecture. Architecture refers to the design of all aspects of a piece of software. How do browsers design their processes to operate and manage them

We’re going to put the various browsers together and talk about how they’ve changed their process architecture over the course of their history. Why this adjustment? What problems have been solved? This article will give you an idea of what the first three questions are and give you a way to think about the rest of your problems.

Okay, now that we’re talking about evolution of process architecture, do you really understand how processes work? What is the relationship with threads? Let’s go through it briefly

Understand processes and threads

When we use the computer, we will open multiple programs to run at the same time, such as open the music program to play songs, open the document program to write records, and open a download program to download movies. But the CPU can only execute one program at a time (multicore aside), so how do we manage to run multiple programs at once?

The answer is progress. Process is a concept in operating system, operating system in the face of processing multiple programs at the same time, the application program abstracts to run as a process. In this way, the operating system can quickly allocate CPU execution time, a valuable resource, to different processes according to certain rules, because switching allocation is so fast that it looks like multiple applications are running at the same time.

But only the process is not enough, often an application as a whole at the time of execution is more child tasks, like an online music program at run time, need to run at the same time network load subroutine load music flow, but also run music BianXie size of data flow procedure, will also run music industry the UI application, etc. Therefore, the operating system divides the concept of thread in the process. With threads, an application can manage its own subtasks simultaneously. To update the concept from here, the CPU can only execute one thread at a time.

Let’s go over the whole thing again. When you run an application, the operating system encapsulates your application as a process to run. Because programs need memory to run, threads are allocated to store program code, data, and file resources. When your process needs to perform subtasks, you can create new threads to perform them.

Here are a few features we need to know:

Threads share process resources. Process is the basic unit of the operating system allocation of resources, so the process needs system resources are given by the operating system, and the thread inside to use resources can only share the resources of the process. These resources include memory space as well as operating system permissions.
When one thread crashes, the entire process crashes. In fact, it is easy to understand that during the process of running a program, if a thread fails, because memory is shared, then if the wrong data is generated, the entire process is likely to end up executing the wrong result. So the operating system just killed it all.
Processes are isolated from each other and communicate via IPC. Although we have always said that a process is an application, sometimes an application may start a child process, and the data between the processes may be isolated and independent. To synchronize certain data contents, this can be done by means of some kind of inter-process communication (IPC). (IPC is a general term for the means that can be used to communicate between different processes, so there is no need to go into details here.)

Early single-process browsers

Earlier browsers, including Internet Explorer 7 and before it, Firefox used a single-process browser architecture, meaning that the entire browser program was run in a single process. There are certainly some differences in the actual process architecture of different types of browsers, but for the sake of illustration, we have simplified the following diagram to illustrate the problems of single-process browsers.

In this process architecture, in addition to running the browser window and downloading resources, the page thread is also responsible for page rendering, JS execution and the running of various plug-ins. It’s a process that we now see as a bit of a dance on a knife’s edge. Running a browser with many pages or even many plugins and features would be extremely unstable, cumbersome and insecure

So let’s see why it’s unstable. Back to the original question, have you ever used Internet Explorer 6, Internet Explorer 7 or Firefox, had a plugin or page crash, and the entire page crash?

If that sounds familiar now, you probably already know the answer. As we talked about earlier, when a thread crashes, the entire process crashes. In single-process browsers, our page rendering engines, plugins, and programs like Internet Explorer with a lot of dynamic link libraries can all fail ❌, so no matter which thread these programs are running in the process, as long as one of them makes a mistake, the whole browser will die. This is what we call unstable.

Now look at the influency. We already know that the CPU can only execute one thread of a process at a time. So when we have a page thread that includes both page rendering and JS execution, as well as various plug-in execution. If we write an infinite loop of tasks in our JAVASCRIPT code, we can imagine that the rest of the browser’s tasks will not be able to execute — it will get stuck. So even if we are not so grumpy, just our JS or plugin needs to run something all the time, when your page is performing animation with JS, the CPU is suddenly robbed by the plugin process to perform other tasks, then your animation effect is not stuck you panic 😫

Finally, to address the issue of insecurity, we use another feature we just mentioned — threads sharing process resources. Anyone who has used anti-virus software and various security guards on Windows is probably familiar with the term “malware”. Plug-ins are designed to easily extend browser features, such as Adobe Flash Player, the most common plug-in, which used to be a necessity for almost everyone. When the browser and plug-in programs run on the same page, because the process memory is shared, the plug-in gets access to the browser’s running data and has the same system rights as the browser. So when your system is infected with a malicious plug-in, the plug-in can record the password you entered into the web page, pop up various Windows, open multiple web pages and so on while the browser is running. Now you know where all those unintentionally opened pages that you manually crossed out one by one came from, and you know one possible reason why your QQ id was stolen in the first place.

This was the problem with the early single-process browsers, which were unstable, fluid, and insecure. And all this is due to the problem of putting everything together like kneading dough, with confused responsibilities, arbitrary authority, and the risk of “one person setting fire to the family”.

Evolution to a multi-process architecture

It may be due to the simple functions and features of early web pages, which do not need very rich features (such as: Canvas, WebGL, Webworker, etc.), at that time, generally speaking, a single process is enough. There was a time when front-end development was not so complicated, and pages were written directly from the back end. The importance and complexity of the front end is growing now that there is a position for a front-end development engineer and a more systematic and comprehensive front-end development workflow. In addition to the single process browser itself some problems, in the face of the change of The Times, the rise of the front-end, if the browser still stay in situ is certainly not feasible, cannot support the development of new technology, let alone the single process itself brings problems also need to be solved.

Multi-process browsers, of course, break up the various types of browser tasks and put them into different processes. One key security technology used here is Sandox.

A Sandbox can be thought of as a process with limited permissions, a slightly more restrictive definition

Sandbox technology restricts the use of system resources by programs according to security policies, so as to prevent them from damaging the system. Its effectiveness depends on the effectiveness of the security policies used

That is to say, the sandbox limits the permissions according to your security policy, it can prevent malicious damage to the system, provides a certain level of security, which is also part of the solution to the “insecure” problem we mentioned above. The implementation of the sandbox varies from operating system to operating system. After all, the process is provided by the operating system. That’s not our point.

Let’s take a look at how Chrome, Internet Explorer, and Firefox have evolved into a multi-process architecture.

Chrome’s multi-process architecture

Google Chrome, which was first released in 2008, appears to be a relative newcomer to older browsers like Internet Explorer. But this upstart isn’t just an abrupt move to grab browser market share, as Chrome’s multi-process architecture has been evident since the beginning.

In Chrome’s multi-process architecture, there are several processes

Browser main process. The main process of the entire browser, several other processes are the child process of this process, by it to manage and deploy; And the whole window of the browser that you see, the address entry bar, the bookmarks bar, all of that stuff is displayed;
Render process. In general, one render process per Tab Tab page (see Site Isolation strategy for unusual cases); Each rendering process runs the Blink layout engine, V8 JavaScript execution engine, etc., serving a separate Tab page; Running in a sandbox cannot access system resources.
Plug-in process. A plug-in exists in a single process and runs in a sandbox with limited permissions for security.
Network process. Initiate a network access request.
Process of GPU. Handle GPU rendering tasks.

As you can see, Chrome’s multi-process design greatly reduces the execution burden of a single process by breaking up the various tasks that used to be lumped together according to different responsibilities. (In fact, the original Chrome process design actually does not have a separate network process and GPU process, are placed in the browser main process)

When you open a browser, the default is to start the browser main process, showing the entire browser window and address bar and a series of basic UI interface. The main process then starts the other child processes. When you ship a plugin to run, you assign a process to the plugin; if not, you don’t assign it. When you open a Tab, a rendering process is created based on the Tab, which is used to render the page within the Tab and execute the script. Of course, if your pages are using WebGL or CSS3 animations that require a GPU to render, Chrome also provides a unified CPU process to maintain these rendering tasks. If your HTML pages or JS scripts need to be downloaded from the server to be used by the renderer process, we have a separate web process to handle these tasks related to network interaction. Thus, a basic multi-process architecture is presented.

Here are a few things to note:

All other processes are started and managed by the main browser process, and data communication between processes is conducted via IPC.
There may be more than one renderer and plug-in process, depending on the number of pages and plug-ins to render.

Have you solved the problem

So does this solve the problem we had with the single-process browser? Of course it was.

First we look at the problem of unstable, instability is due to the error caused by the plugin or rendering engine, plug-in or page rendering work is now alone in separate threads running, if a plug-in went wrong, the most is that plug-in can’t use, other page browsing and other plug-ins will be run as usual. If one of the renderers fails, it will only render that page unviewable, and other pages will not be affected, let alone crash the entire browser. Remember when a page “crashed” and you closed the Tab and opened it again? Or maybe your browser told you that your Flash plugin crashed, and you tried to view some video sites, but the web was fine, and when you restarted the browser, Flash came back up again. 🤓

And then it’s not flowing. In the case that the page, plug-in and browser each have their own threads, the execution of the plug-in is not smooth will only affect the plug-in itself, whether the page rendering or JS execution, not smooth that is just a page. In the era of single-process browsers, we’re talking about gridlock that’s caused by any page or any plug-in, resulting in gridlock throughout the browser window, all pages, and all plug-ins. The multi-process approach eliminates this “share in danger” model. 🤣

Finally, insecurity. Multi-process security issues mainly rely on two aspects: 1. Renderer process and plug-in process run in sandbox environment; 2. 2. Data of isolated processes is not shared. Splitting into multiple threads allows us to sandbox each individual page and each individual plug-in, stripping the renderer of file system permissions, network access, etc. Plug-in processes also don’t have full control over a page or access and modify the browser’s main process data, and plug-ins themselves are severely limited in what they can do. What if they need some kind of operation, such as a network request or file access? IPC tells the browser’s main process, which decides whether or not to give you permissions and which permissions to give you. Remember when you open a map site in Chrome and the browser asks you “Do you allow sites to access your location?” or “Do you allow sites to use cameras?” 😇

Let’s do a little experiment

Now you can open Chrome Settings => more tools => Task Manager to see which processes are running in Chrome.

In this case, I just opened Chrome and opened two tabs, one for Baidu and one for Google. You can see here that the task manager shows which processes our browser is running, including the process name, memory usage, CPU usage, network and process ID (you can actually right-click the header to list more references). Similar to what we just said, we have to have a main browser process anyway, and then we have a GPU process that renders some graphics-related stuff, and then we have a Network Network process, and then the other two tabs are the two rendering processes. At this point I want to simulate what happens when a rendering process crashes. Click on the Baidu TAB and click on the end process in the lower right corner. You are not also like me, appeared the following page.

You should also notice that the entire browser is still running stably, the Google page is fine, and only the Baidu page has crashed. If you have a plugin running in your browser, you can also try closing the plugin process.

Does this test answer the question “Did you have to force the entire browser to shut down when you opened a page and for some reason the entire browser froze? Did that enlighten you?

Site Isolation

One more thing that definitely needs to be talked about with Chrome’s multi-process architecture is the Site Isolation strategy. We talked about a TAB page and a render process, but in reality it would be a waste of process resources if every TAB page were a render process. Another particular problem is that if there is only one TAB and one render process, if there is one TAB and one iframe refers to another page, then the pages of two different websites will be rendered and executed in the same process. In this way, Tab process isolation does not isolate the site. And because of the known CPU-level vulnerabilities Spectre and Meltdown, which allow applications to access data that is not part of the current process, Chrome will also have to adjust its per-tab, per-renderer policy for security reasons.

The adjustment strategy here is the site isolation strategy. Site isolation means that content in the same domain is rendered in the same rendering process. In the case of a Tab page where an iframe is introduced into other pages, the Tab itself is definitely a renderer, but in the case of an internal iframe, if the iframe is in the same domain as the Tab page, the renderer is shared, otherwise the iframe is given a separate renderer. For example, in the image below, the pages of a.com, b.com and C.com all have a separate rendering process. If you replace b.com with some other page from a.com, they will use the same rendering process.

In fact, the most important function of site isolation is the requirement for security, and the second is to save a little memory.

Here provide a test for all the web site features: csreis. Making. IO/tests/cross… . Open it in Chrome, open the task Manager that we opened in our experiment above, click on the test site button, and watch what happens. (Note: if you belong to the same process, only the information line representing the page does not have the process ID). 😎

Here actually isolation strategy is also applicable to the site from a page open in a new Tab page, for example, I first page open for recruitment website www.igetget.com/join/work click on the upper right corner of the “we” know, this time will open a new Tab, and then to see, in the “task manager” You will notice that the new Tab page does not have a process ID. When you click on the process, it will select the two Tab lines, which means they are using the same process. (Note that our newly opened Tab belongs to the same domain as the original page.)

IE multi – process architecture

The process architecture of Internet Explorer has become multi-process since Internet Explorer 8. The diagram below shows the process architecture of IE8. Doesn’t that seem a little confusing? Let’s get this straight.

Before saying IE multithreading, we need to briefly understand the DLL this thing, DLL called dynamic link library, can be seen as some specific functions to achieve the code library, in Windows programming to call some Windows system functions, you can directly call some DLL libraries to provide us with the corresponding functions.

There are two main types of IE processes:

Framework process.
The Tab.

The framework process is represented by the red area at the top of the diagram. It is basically a UI process. The bottom layer uses browseui.dll, a DLL library, to build the user interface, including toolbars, menus and other things. Frame process can create multiple Tab process, the communication between Tab process and frame process is using ALPC (advanced local call) mechanism, this mechanism is commonly used in the Windows kernel, interested in you can go to understand.

The Tab process is used to render pages, execute JS code (JScript and VBscript, at least not standard Ecmascript for IE8), and execute an IE plug-in. The Tab process calls the shdocVw.dll library for history, the MSHTML. DLL library for HTML parsing, DOM generation and manipulation, and JScript scripts. Winlnet.dll for networking and caching, and a more secure urlmon.dll library for downloading resources wrapped in a layer. You may be wondering if **Tab process means one process per Tab page? ** Actually not, considering the overhead of creating a process, creating a new Tab process on Windows also requires loading a bunch of dynamic link libraries. The number of Tab processes in IE8 is limited by a certain policy. When the Tab process reaches the maximum, the newly opened web page will be reused by the previous Tab process. (Also: this policy exists in the TabProcGrowth key in the Windows registry. You can Google this configuration information to see how changing it changes the Tab process’s usage policy.)

Firefox’s multi-process architecture

The early Days of Firefox were single-process, and when they realized that putting all Tab page HTML rendering and JavaScript execution, as well as the browser window UI, into a single process was a bad idea, they made changes to the process architecture. Mozilla then launched a project called Electrolysis (also known as E10S) to gradually transfer process architectures to multiple processes in 2016. As a result, nine iterations of Firefox, from Firefox 48 to 56, gradually improved the multi-process architecture.

For the browser main process, GPU process, extension process, I believe you have a good understanding. No more nonsense.

Focus on the Tab process, which is similar to Chrome’s rendering process in that it renders pages and executes Javascript code. However, for Firefox Tab process, it can be seen that Firefox Tab process and IE Tab process have a similar point is: there are multiple Tab processes, but not necessarily a page a Tab process, a Tab process may be responsible for multiple pages rendering. Chrome, by contrast, operates on a per-page, per-render process, plus a site isolation strategy. As you can imagine, Chrome generally requires more memory, because unlike Firefox and Internet Explorer, which limit the maximum number of processes used to render a page, the site isolation policy is only optimized. I have attached a memory consumption comparison chart below for you to see for yourself.

conclusion

For early single process browser, the page rendering, JS, plug-in run, run the main program and browsers are placed in a single process, for the browser application can’t better security features, and it is easy to collapse collapse, even normal operation also can appear some questions is not smooth. Chrome was originally released with a multi-process architecture, IE was twetweed from IE8, and Firefox started the Electrolysis project. Gradually move Firefox to multi-process architecture around 2016.

In the process of migration, each browser has a similar point is that each browser will be the main process of the browser, that is, the process used to run the browser window separated into a separate process to run, on this basis to create each page rendering rendering process and other sub-processes, and unified management. The multi-process architecture of IE8 is relatively simple, and strongly depends on various dynamic link libraries of Windows system. Chrome it more generous to each page rendering process, at the same time also use ready to optimize the site isolation strategy, to also be more generous to each plug-in plug-in process has a separate process, this program isolated from the process level of influence each other to a small extent, by assigning the only problem is too generous Memory usage also goes up; Firefox in the multi-process architecture design, to run a special plug-in process, used to render the page Tab process and IE8 Tab process has a similar point is that there is a maximum limit to the Tab process.

Chrome’s latest process architecture is also moving toward SOA, or service-oriented architecture. The way to achieve this is to abstract the network, device, UI, media and other programs into services, unified into the basic service layer, for the browser main process, plug-in process and renderer process to call. It saves resources and has better scalability, reducing the problem of high coupling in the existing multi-process architecture. You can know this by yourself, and the references given at the end of the article are also involved.

I believe that you have at least a little knowledge of the browser process architecture, I hope to have some help for your daily development or the use of the browser.

The resources

Internet Explorer Wikipedia: en.wikipedia.org/wiki/Intern…
Internet Exploere Architecture: docs.microsoft.com/en-us/previ…
Modern Multi – Process Browser Architecture: helgeklein.com/blog/2019/0…
Inside look at mordern web browser (part 1) : developers.google.com/web/updates…
Multi – process Architecture: dev.chromium.org/developers/…
The Multiprocess Firefox: developer.mozilla.org/en-US/docs/…
Multi – Process Firefox: everything you need to know: (www.ghacks.net/2016/07/22/)… [www.ghacks.net/2016/07/22/]…
Geek Time: How Browsers Work — Chrome architecture: Why 4 processes when only 1 page is open?
Servicification: www.chromium.org/servicifica…
The Meltdown/Spectre: developers.google.com/web/updates…