Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about the working principle of the front-end browser. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Browser architecture

Before we talk about browser architecture, understand two concepts, process and thread.

Process is an execution process of a program and a dynamic concept. It is the basic unit for a program to allocate and manage resources during execution. Thread is the basic unit for CPU scheduling and dispatching. It can share all resources owned by a process with other threads belonging to the same process.

To put it simply, the process can be understood as the executing application, while the thread can be understood as the executor of the code in our application. And their relationship can be imagined, the thread is running in the process, there may be one or more threads in a process, and a thread can only belong to one process.

As we all know, the browser belongs to an application, and one execution of the application can be understood as the computer started a process, after the process started, CPU will allocate the corresponding memory space for the process, when our process gets the memory, we can use threads for resource scheduling, and then complete the function of our application.

In the application, in order to meet the functional needs, the started process will create another new process to deal with other tasks. These new processes have a new independent memory space and can not be inward memory with the original process. If these processes need to communicate with each other, it can be done through the IPC mechanism (Inter Process Communication).

Many applications work in this multi-process way, because processes and processes are independent of each other, and they do not affect each other, that is, when one of the processes dies, it does not affect the execution of the other processes. you just need to restart the suspended process to resume running.

Multi-process Architecture of browser

If we develop a browser, its architecture can be a single-process, multi-threaded application or a multi-process application that uses IPC communication.

Different browsers use different architectures. The following mainly takes Chrome as an example to introduce the multi-process architecture of browsers.

In Chrome, there are four main processes:

Browser process (Browser Process): responsible for the browser's TAB forward, backward, address bar, bookmark bar work and handle some of the browser's invisible underlying operations, such as network requests and file access.

Rendering process (Renderer Process): responsible for display-related work within a Tab, also known as the rendering engine.

Plug-in process (Plugin Process): responsible for controlling the plug-ins used by the web page

GPU process (GPU Process): responsible for handling GPU tasks for the entire application

What is the relationship between these four processes?

First of all, when we want to browse a web page, we will enter URL in the address bar of the browser. At this time, Browser Process will send a request to the URL to obtain the HTML content of the URL, and then send the HTML to Renderer Process,Renderer Process to parse the HTML content. When parsing the resources that need to request the network, they return to Browser Process to load, and notify Browser Process that Plugin Process is required to load plug-in resources and execute plug-in code. After the parsing is completed, Renderer Process calculates the image frames and gives them to GPU Process,GPU Process to convert them into image display screens.

Benefits of a multi-process architecture

Why does Chrome use a multi-process architecture?

First, higher fault tolerance. In today's WEB applications, HTML,JavaScript and CSS are becoming more and more complex. The code running in the rendering engine frequently appears BUG, and some BUG will directly cause the rendering engine to crash. The multi-process architecture makes each rendering engine run in its own process and is not affected by each other, that is to say, when one of the pages crashes and hangs, the other pages can run normally without impact.

Second, higher security and sandboxing (sanboxing). Rendering engines will often encounter unreliable or even malicious code on the network, and they will take advantage of these vulnerabilities to install malicious software on your computer. To solve this problem, browsers restrict different permissions to different processes. And provide it with sandboxie running environment to make it more secure and reliable.

Third, higher response time. In the single-process architecture, various tasks compete with each other for CPU resources, which makes the response speed of the browser slower, while the multi-process architecture just avoids this disadvantage.

Multi-process architecture optimization

As we said earlier, the role of Renderer Process is to be responsible for display-related work within a Tab, which means that a Tab will have a Renderer Process, and the memory of these processes cannot be shared, and the memory of different processes often needs to contain the same content.

Process mode of the browser

To save memory, Chrome provides four process modes (Process Models). Different process modes treat tab processes differently.

Process-per-site-instance (default)-use one process for the same site-instance

Process-per-site-use one process with the same site

Process-per-tab-use one process per tab

Single process-all tab share one process

Here we need to give the definition of site and site-instance.

Site refers to the same registered domain name (e.g. google.com, bbc.co.uk) and scheme (e.g. https://)). For example, a.baidu.com and b.baidu.com can be understood as the same site (note that it should be distinguished from Same-origin policy here, and the same origin policy also involves subdomain names and ports).

Site-instance refers to a set of connected pages from the same site. Here the definition of connected is how can obtain references to each other in script code understands this passage. Meet the following two situations and the new page and the old page open belong to the same site defined above, so they belong to the same site-instance

In this way, users click on a new page that opens.

A new page opened by JS code (such as window.open)

After understanding the concept, the following four process patterns are explained

The first is Single process, as the name implies, single-process mode, where all tab use the same process. Then there is Process-per-tab, which, as the name implies, creates a new process for each tab opened. For Process-per-site, when you open the a.baidu.com page, on the page that opens the b.baidu.com, the tab of these two pages uses the same process because the site of the two pages is the same, so if one of the tab crashes and the other tab crashes.

Process-per-site-instance is the most important because this is the default mode used by Chrome, which is the mode used by almost all users. When you open a tab to access a.baidu.com, and then open a tab to access b.baidu.com, the two tab will use two processes. If you open the b.baidu.com page in a.baidu.com through JS code, the two tab will use the same process.

Default mode selection

So why do browsers use Process-per-site-instance as the default process mode?

Process-per-site-instance is compatible with performance and ease of use, so it is a more moderate and general model.

Compared with Process-per-tab, being able to open many fewer processes means less memory footprint.

Compared with Process-per-site, it can better isolate unrelated tab under the same domain name and is more secure.

What happened during navigation?

Earlier, we talked about the multi-process architecture of the browser, the various benefits of the multi-process architecture, and how Chrome optimizes the multi-process architecture. Let's learn more about how processes and threads render our website pages from the simple scenario of users browsing the web.

Web page loading process

As we mentioned earlier, most of the work outside tab is done by the browser process Browser Process, and Browser Process is divided into different worker threads according to the different work:

UI thread: controls the buttons and input boxes on the browser

Network thread: processing web requests and getting data from the internet

Storage thread: controls access to files, etc.

Step 1: process input

When we press enter in the browser's address bar, UI thread will determine whether the input is a search keyword (search query) or URL. If it is a search keyword, jump to the default search engine corresponding to search URL. If the input is URL, start requesting URL.

Step 2: start navigation

After pressing enter, UI thread sends the keyword search corresponding URL or input URL to the network thread Network thread, at this time, the UI thread shows the icon in front of the Tab as loading state, and then the network process carries out a series of operations such as DNS addressing and establishing TLS connection to make resource requests. If it receives the 301redirect response from the server, it will tell the UI thread to redirect and then it will initiate a new network request again.

Step 3: read the response

After receiving the response from the server, network thread begins to parse the HTTP response message, and then determines the media type (MIME Type) of the response subject according to the Content-Type field in the response header. If the media type is a HTML file, the response data is handed over to the rendering process (renderer process) for the next step. If it is a zip file or other files, the relevant data will be transferred to the download manager.

At the same time, the browser performs a Safe Browsing security check, and if the domain name or request content matches to a known malicious site, network thread displays a warning page. In addition, network threads do CORB (Cross Origin Read Blocking) checks to determine that sensitive cross-site data is not sent to the rendering process.

Step 4: find the rendering process

After various checks, network thread is sure that the browser can navigate to the requested web page, network thread will inform UI thread that the data is ready, and UI thread will find a renderer process to render the web page.

In order for the browser to optimize the step of finding the rendering process, considering that it takes time for the network request to get the response, at the beginning of the second step, the browser has looked up and started a rendering process in advance. If all goes well in the intermediate step, when network thread receives the data, the rendering process will be ready, but if there is a redirection, the prepared rendering process may not be available. A rendering process will be restarted at this time.

Step 5: submit the navigation

At this point, the data and rendering process are ready, and Browser Process sends an IPC message to Renderer Process to confirm the navigation. At this point, the browser process sends the prepared data to the rendering process. After the rendering process receives the data, it sends an IPC message to the browser process, telling the browser process that the navigation has been submitted and the page begins to load.

At this time, the navigation bar will be updated, the security indicator will be updated (the small lock in front of the address), and the access history list (history tab) will be updated, that is, you can switch the page forward and backward.

Step 6: initialize and load complete

When the navigation submission is completed, the rendering process starts to load the resources and render the page (described below). When the page rendering is completed (the page and the internal iframe trigger the onload event), an IPC message is sent to the browser process, informing the browser process. At this time, UI thread will stop displaying the loading icon in the tab.

Principle of web page rendering

After the navigation process is completed, the browser process gives the data to the rendering process, which is responsible for everything within the tab. The core purpose is to convert the HTML/CSS/JS code into web pages that users can interact with. So how does the rendering process work?

In the rendering process, the containing threads are:

One main thread (main thread)

Multiple worker threads (work thread)

A synthesizer thread (compositor thread)

Multiple rasterized threads (raster thread)

Different threads have different job responsibilities.

Build DOM

When the rendering process receives the navigation confirmation and starts to accept data from the browser process, the main thread parses the data and converts it into a DOM (Document Object Model) object.

DOM is the data structure and API for WEB developers to interact with web pages through JavaScript.

Resource subload

In the process of building DOM, resources such as images, CSS and JavaScript scripts are parsed, which need to be obtained from the network or cache. If the main thread encounters these resources in the process of building DOM, it initiates a request to obtain them one by one. In order to improve efficiency, the browser will also run a preload scan (preload scanner) program if there are img, link and other tags in the HTML. The preload scanner passes these requests to Browser Process's network thread for resource download.

Download and execute JavaScript

In the process of building DOM, if you encounter

These are the working principles of the front-end browser shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.