Chromium multi-process resource loading

"Welcome reprint, reprint, please indicate the source http://blog.csdn.net/yl02520/article/details/21285745"

The original text from chromium official document Multi-processresource Loading, part of this article from the translation of the original text, but also to some parts of the original text made necessary changes and supplements, but also added some of their own understanding.

Before you read this article, it is recommended that you read another blog post, "Chromium browser's multi-process architecture." Background Knowledge

Chromium uses a multi-process architecture, this article mainly introduces the browser process and the rendering process, because the rendering process is running in the sandbox, there is no direct access to system resources (such as network resources). Webkit/blink in the render process when rendering a Web page, you first need to load the appropriate resource files from the network, such as HTML documents and documents, such as pictures, JS scripts, CSS scripts, and other child resource files. Then the rendering process needs to send these requests through IPC (interprocess communication) to the browser process, which is managed by the browser process and network data transfer.

There are several advantages to doing this: 1. The browser can manage all resource requests uniformly; 2. The browser process can cache already downloaded resource files and cookies, and when a new request arrives, it is extracted directly from the cache if the requested resource is present in the cache, and does not have to be downloaded back from the network, which saves network bandwidth and time to download resources. 3. Since http/1.1, browsers have requested that too many connections be opened for hosts of the same domain name, because if one tab opens too many socket links, it can cause excessive system resource consumption, which may affect other tab pages or other applications running. This is particularly important on resource-constrained mobile platforms. Chromium currently allows the same host to open up to 6 socket links. Overall Architecture

From the figure above, we have the Chromium resource file loading process is roughly divided into three layers, the bottom layer is the webkit/blink layer, it runs in the rendering process of the rendering thread, responsible for parsing the HTML document, javascript/ CSS script parsing execution and the layout of the page and other functions; the middle layer is the module that communicates with the browser process in the rendering process, which is responsible for forwarding the resource request sent by WebKit to the browser process in the main thread of the rendering process; The top level is the browser process, which controls all network connections and communications, The module runs in the IO thread in the browser process. Webkit/blink

All resource files, including HTML documents in Webkit/blink, are obtained through the Resourcefetcher class, and now the latest implementations have made improvements to the previous WebKit resource loading process, see another blog post "webkit/ Blink How to load Web page resources. The Resourcefethcer class provides methods for obtaining different resource files, such as: The Fetchmainresource method gets the frame resource, and the request sent by the method has the highest priority; Fetchimage method gets the picture file ; Fetchscript method gets JavaScript script file resources, and so on. These methods of obtaining resources send requests by creating and invoking Resourceloader. Render Process

The rendering process implements the class Resourceloaderbridge, which we call Ipcresourceloaderbridge, which is in Content/child/resource_ Implemented in dispatcher.cc (chromium later moved the location of the file), which sends network resource requests through the Resourcedispatcher class, there is a Resourcedispatcher object in each rendering process, and all networks sent from WebKit please And, finally, to resourcedispatcher processing, Resourcedispatcher assigns a unique ID number to each request, which distinguishes the other requests and assembles them into an IPC packet Resourcehostmsg_ Requestresource the request message to the main thread, and the main thread is unified and the browser process is IPC. Browser Process

The resourcedispatcherhost of IO threads in the browser process processes the resource request messages that are sent over the rendering process, resourcedispatcherhostimpl::o The Nrequestresource method handles the Resourcehostmsg_requestresource message, and then transforms the data structure of each message request into a URLRequest object chromium the net module. and to the Urlrequestjob class within the net module, which is responsible for the implementation of the specific network protocol. When URLRequest gets the data or notification, Resourcedispatcherhost receives the corresponding message, finds the corresponding renderprocesshost based on the resource request ID number created in the render process, and sends the message to the rendering process. cookies in chromium cookies are stored in the browser process and are shared for all rendering processes, which is why we log on to a Web site in a tab page, When you open a new tab, you don't have to re-enter the password to log in (a new rendering process is used when you manually open a new tab). In the Web page we can access the Web site's cookie value through the javascritpt script Document.cookie, at which point the render process needs to send a synchronized IPC to the browser process, because it is a synchronized IPC, so the render thread in the render process (the main loop of the WebKit) is blocked until Until the data for the browser process returns, and then return the results to the JavaScript engine, allowing JavaScript to continue executing.