In this article, we will discuss the internal working mechanism of Chrome, and analyze how different processes and threads handle various parts of the browser’s functions. At the same time, in-depth study of how each process and thread communicate when displaying the website.
First, let’s take a look at a simple example. Enter url in the browser’s address bar and press Enter. The browser will request data from the server and display the interface.
Start from the browser process
From the first article, we know that all functions outside the tab page are controlled by the browser process, and there is drawing and browsing in the browser process The UI thread of the button and input box of the device, the network thread handles the network stack to obtain data from the network, and stores the thread control file permissions. When the url is entered and the enter key is pressed, the UI thread will process our input.
Handle input in the address bar< br> After the user enters the address bar, the UI thread goes back to judge whether the user’s input is a url or a search item, because the chrome address bar can also be used as a search input box. So the UI thread needs to judge the user’s input and then decide whether to send the user’s input to the search engine or initiate a network request.
Start navigation
When the user Hit the enter key, the UI thread initiates a network request in order to get the content of the webpage, that is, the UI thread informs the network thread to load a certain webpage. At this time, the loading icon on the left side of the browser address bar will be displayed, and the network thread will establish a network link at the same time. In this process, there are processes such as DNS resolution or TLS link establishment.
At this node, the server may return a redirected status to the network thread, such as HTTP301. At this time, the network thread will tell the UI thread: “Your request is redirected”, and then the UI thread It will initiate another network request.
Read response data
If the data returned by the server is HTML, the network thread will send the data directly to the rendering process (browser kernel), but if it is a zip file or other type File, which means this is a download request, and the network thread will send the data to the download manager.
At the same time, this process will also occur browsing If the response domain and returned data match the known malicious site, the network thread will tell the rendering process to display a warning interface. At the same time, to ensure that dangerous cross-domain data is not sent to the rendering process, CORB will also be performed. Detection.
Find the rendering process
When all the checks are completed, the network thread determines that the browser should navigate to the corresponding request site, the network thread tells the UI thread that the data is ready, and then the UI thread finds the rendering process Continue to render the interface.
Since the network request takes hundreds of milliseconds to get a response, the browser applies an optimization strategy to speed up this process. When the UI thread sends a network request to the network thread, the UI thread will Actively try to find or start a rendering process, which is executed in parallel. Using this method, if everything goes well, when the network thread receives the data, the rendering process is already in the standby state. Of course, the prepared rendering process will not be used if the request is redirected.
Submit navigation
When the data is returned and the rendering process is ready, the browser process will submit the navigation to the rendering process through the IPC channel, and at the same time pass the data stream to the rendering process. Once the browser process confirms the submission of the navigation Has occurred in the renderer process, the navigation process is complete, and the document loading phase begins.
At this point, the status of the address bar has been updated, and the routing history of the tab bar has also been updated. Clicking the forward and back buttons will cause the interface to jump in response. In order to facilitate the restoration of the browser interface after the tab page or browser window is closed, the navigation history information of the tab page is stored on the hard disk.
Initial loading is complete
After the navigation bar’s work is completed, the rendering process will continue to load the resource rendering interface. When the rendering process completes the interface rendering, it will process the browser through the IPC channel (this is when The page includes the execution after the onload event in the frame is triggered). At this time, the UI thread in the browser process will stop displaying the loading icon.
Go to another page< br> The simple navigation is complete! But what happens if the user puts a different URL in the address bar again? Well, the browser process will perform the same steps to navigate to different sites. But before it can be done, if they care about the beforeunload event, it needs to check the currently rendered site.
When you are about to leave or close the current interface, the beforeunload event will trigger a “Leave the current interface?” pop-up box. Of course, the pop-up box is controlled by the rendering process, and the browser process will Ask the rendering process if you need to trigger the beforeunload event. ?
If the jump is initiated during the rendering process For example, if the user clicks the link jump button or executes window.location=”https://newsite.com” in js, the rendering process will first detect the beforeunload processing event, and then it will experience the same as the browser process that starts navigation Process. The only difference is that the navigation request is initiated from the rendering process and then to the browser process.
When navigating to a new site that is different from the current interface, a new rendering process will be created to handle the new navigation, and the old rendering process will handle events similar to unload. For the life cycle of the interface, we can check this article. https://developers.google.com/web/updates/2018/07/page-lifecycle-api#overview_of_page_lifecycle_states_and_events
The difference brought by service woker
Due to the newly introduced service worker feature of the browser, some changes have taken place in the navigation process of the interface. A service worker is a way to write a network proxy in the application code, allowing web developers to better control the content of the local cache, as well as control when the interface requests data from the service. When the service worker proxy resource request is obtained from the cache, it will not send the request to the server.
One of the most important points is that the servicer worker is a piece of js code running in the rendering process, so the question is, when a network request comes in, how does the browser process know that there is a service worker thread on this site? ?
When a service worker is registered, the scope of the service worker will be retained as a reference. When a request occurs, the network thread checks the URL according to the scope of the registered service worker. If a service worker is registered for the URL , The UI thread finds the rendering process to execute the service worker code. The service worker can load data from the cache without requesting data from the network. Of course, it can also request new resources from the network when the rules are not met.
To summarize in this article, We studied what happens during the interface request process and how web application code such as response headers and client-side JavaScript interact with the browser. Knowing the steps of the browser to obtain data through the network, you can more easily understand why APIs such as request preloading are used. In the next article, we will delve into how browsers evaluate HTML/CSS/JavaScript to render pages.