The authors introduce

Topqiang (Lingshi), a proprietary nail front-end member, deeply uses low code platform to build the background management system with the highest business complexity in my career. Currently, I am responsible for the collaborative product development of proprietary nail.

background

Chrome is probably the most popular browser for front-end engineers today. However, most students may not know its internal operation mechanism, as well as the optimization of the browser in these years to support the huge business volume of the Internet world and give the majority of netizens an ultimate experience of online surfing. This article will not write about the underlying implementation, but rather will describe the browser’s technical evolution to understand its background and the reasons behind the problems encountered in developing and using browser applications.

  • Why are modern browsers relatively stable, while older browsers crash so easily?
  • Why is it that modern Web applications are more fluid and can be made into hybrid applications comparable to native ones, while early Web pages tend to get stuck?
  • Why were plugins and security problems so common on the Web before 2009?

Those of you who have been on the Internet since 2007 should have played QQ Space, Baidu Post Bar or School network (Renren), etc. At that time, PC browsers need to wait for a long time to open the page, and mobile phones are slow to open the page, which makes the body feel stronger. This was partly due to the fact that mobile networks were 2g and PC networks were limited broadband. Network factors, hardware configuration, and so on are not going to be discussed today, but the main topic is the evolution of the browser’s own technology architecture.

Single-process browser

Before we get into single-process browsers, we need to understand what a process is, what is a thread? I’m not going to bother you with this but after you get to know processes and threads for yourself, we’re going to look at the architecture of the single-process browser.

A single-process browser is one in which all the functionality of the browser runs in the same process, including the web, plug-ins, JavaScript runtime environments, rendering engines, and pages. In fact, around 2007, most browsers on the market were single-process. The architecture of the single-process browser is shown below:

Having so much functionality running in a single process is a major factor in making single-process browsers unstable, fluid, and insecure. I will analyze the reasons for these problems one by one.

unstable

Early browser videos and games needed plug-ins to implement powerful features such as Flash players, but plug-ins were the most problematic module and ran in the browser process, so the accidental crash of one plug-in caused the entire browser to crash. 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.

Not smooth

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. This piece of content to continue to go deeper into the page event loop. 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

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.

Multiprocess browser

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.

I mentioned that Chrome uses multiple renderer processes. In the simplest case, you can imagine that each TAB has its own renderer process. Suppose you have three tabs open, each run by a separate renderer process. If one TAB becomes unresponsive, then you can close the unresponsive TAB and continue to use the other TAB’s services, and if all tabs are running on a process, when one TAB becomes unresponsive, all tabs are unresponsive.

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.

What processes exist

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:

I took a screenshot from Chrome/94. You can see that the latest Chrome browsers include: 1 GPU process, 1 V8 proxy parsing tool (V8 code interpreter), 1 NetWork process, 1 browser main process, multiple plug-in processes (I have too many plug-ins), multiple renderers and alternate renderers. Let’s take a look at each of these processes one by one.

  • Process of GPU. Chrome had no 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.
  • V8 Proxy Parsing Tool (V8 Code Interpreter) Google’s open source high-performance JavaScript and WebAssembly engine, written in C, implements ECMAScript and WebAssembly and can be run independently or embedded into any C application, such as Chrome and Node.js.
  • The 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.
  • Browser process. It is mainly responsible for interface display, user interaction, sub-process management, and storage.
  • Extensions (plug-in processes). 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.
  • 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.
    • GUI rendering thread: Responsible for rendering the page, layout and drawing, redrawing and rewinding the page, this thread executes, mutually exclusive with the JS engine thread to prevent unexpected rendering results
    • JS engine thread: Responsible for parsing and executing javascript scripts, has only one JS engine thread (single thread) and is mutually exclusive with GUI rendering threads to prevent unexpected rendering results
    • Event trigger thread: It is used to control the event loop (mouse click, setTimeout, Ajax, etc.). When dealing with some code that cannot be executed immediately, the corresponding task will be added to the end of the event queue when it can be triggered. The event loop mechanism will loop through the head of the event queue when the JS engine thread is idle. The function is pushed onto the execution stack and executed immediately
    • Timing trigger thread: the thread where setInterval and setTimeout are located and the timing task is not timed by the JS engine, but by the timing trigger thread. After the timing is complete, the callback event is put into the event queue
    • Asynchronous HTTP request thread: The browser has a separate thread that handles AJAX requests and puts callback events, if any, into an event queue when the request completes.

Rendering process allocation

When the browser render process partition, there will be another dimension, that is, according to the site dimension partition:

Site isolation is a recently introduced feature in Chrome that runs a separate renderer process for each cross-site IFrame. We’ve been talking about one renderer process per TAB model, which allows cross-site iframes to run in a single renderer process and share memory space between different sites. It seems ok to run a.com and b.com in the same renderer process. The same origin policy is the core security model of network. It ensures that one site cannot access another site’s data without consent. Bypassing this policy is the primary goal of security attacks. Process isolation is the most effective way to separate sites. With Meltdown and Spectre, it becomes more obvious that we need to use processes to isolate sites. Since Chrome 67, site isolation has been enabled by default on the desktop, with a separate renderer process for each cross-site IFrame in the TAB.

Enabling site isolation is a multi-year engineering effort. Site isolation is not as simple as assigning different renderer processes; It fundamentally changes the way iframes communicate with each other. Opening DevTools on a page where iframe is running on a different process means devTools must perform behind-the-scenes work to make it look seamless. Even running simple Ctrl+F to find words in a page means searching in different renderer processes. You can see why browser engineers call Site Isolation’s release a major milestone.

But it is not always the same site in the same render process, different tabs are not necessarily in the same render process. The exact process allocation logic depends on the Chromium process-Models, and Chrome’s default is process-per-site-instance. Process-per-site-instance: when you open a TAB to access a.baidu.com and another TAB to access B.baidu.com, the two tabs will use two processes. If b.baidu.com is opened through the JavaScript code of the A.baidu.com page, the two tabs will use the same process. As shown in the example below, the processId of the two tabs is the same.

In addition, there are also three processing models [process-per-site, process-per-tab, Single Process], which can be viewed in the chromium official introduction.

Defects existing at the present stage

There are two sides to every coin. While the service-oriented multi-process architecture model improves browser stability, smoothness, and security, 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.

In order to better balance all aspects of the appeal, let’s take a look at Chrome to save more memory, do the servitization.

Chrome is undergoing architectural changes to run every part of the browser application as a service, which can be easily split into different processes or aggregated into one. The general idea is that when Chrome is running on powerful hardware, it might split each service into different processes to provide greater stability, but on resource-constrained devices, Chrome will consolidate the service into a single process to save on memory footprint. Prior to this change, a similar approach was used to merge processes to reduce memory usage on platforms such as Android.

Of course, the above mentioned is not the whole cause of the problem. The development of browser architecture in recent years is not only the development of network protocol, base station, chip, CPU, bandwidth carrying capacity and other scientific and technological fields, which can make PC/ mobile Internet experience better application services to our life. We can feel the convenience of digital life.

Reference documentation

  • Developers.google.com/web/updates…
  • www.chromium.org/developers/…
  • Working Principle and Practice of Browser by Li Bing