【Chromium中文文档】多进程资源加载

多进程资源加载（须要更新）

转载请注明出处：https://ahangchen.gitbooks.io/chromium_doc_zh/content/zh//General_Architecture/Multi-process_Resource_Loading.html

全书地址
Chromium中文文档 for https://www.chromium.org/developers/design-documents
持续更新ing，欢迎star
gitbook地址：https://ahangchen.gitbooks.io/chromium_doc_zh/content/zh//
github地址： https://github.com/ahangchen/Chromium_doc_zh

背景知识

全部网络交流都是在主浏览器进程处理的。这样浏览器进程不只能够控制每一个渲染器的网络访问，还能够在进程间维持session状态一致性，像cookie和缓存数据。另外一个重要的缘由是，做为一个HTTP/1.1的用户代理，浏览器总体上在每一个host上不能打开太多链接。

概述

咱们的多进程应用程序能够从三个层面来看。在最底层是WebKit库，用来渲染页面。在它上面是渲染器进程（简单地，每一个标签页对应一个进程），每一个进程包含一个WebKit实例。管理全部渲染器的是浏览器进程，控制全部的网络访问。

Blink（刷新器）

Blink有一个ResourceLoader对象，负责获取数据。每一个加载器有一个WebURLLoader以展示真实的请求。这个实例的头文件在Blink仓库中。

ResourceLoader实现了WebURLLoaderClient接口。这是渲染器使用的回调接口，用以获取数据和其余刷新用的事件。

测试shell使用一个不一样的资源加载器，提供了不一样的实现，即，一个非IPC版本的ResourceLoaderBridge，位于webkit/tools/test_shell/simple_resource_loader_bridge。

渲染器

渲染器对WebURLLoader的实现，成为WebURLLoaderImplementation，位于content/child。它使用全局的ResourceDispatcher单例对象（每一个渲染器内部单例），来建立一个惟一的request ID，经过IPC转发这个request给浏览器。浏览器的响应会引用这个request ID，将其转换后，经过资源分发起返回给RequestPeer对象（WebURLRequestImpl）。

浏览器

浏览器中的RenderProcessHost对象从每一个渲染器接收IPC请求。使用指向渲染进程host的指针（尤为是，ResourceDispatcherHost::Receiver），转发这些请求给全局的ResourceDispatcherHost，而且用渲染器生成的request ID惟一标识这些请求。

而后，每一个请求会被转换成一个URLRequest对象，反过来将其转发给它内部的URLRequestJob（它实现了须要的特殊协议）.当URLRequest生成通知时，它的ResourceDispatcherHost::Receiver和request ID会被用于将通知发送给正确的RenderProcessHost，以将其发回给渲染器。由于渲染器生成的ID被保留，将全部的响应与一个特定的一开始由WebKit生成的请求关联起来成为可能。

Cookies

全部的cookies由咱们的CookieMonster对象处理，位于/net/base中。咱们不会与WinInet共享cookie。这个浏览进程中的CookieMonster处理全部的网络请求，由于全部标签页之间的cookie必须相同。

页面能够经过document.cookie为一个document请求cookie。这种状况下，咱们从渲染器向李兰器发送一个同步消息来请求cookie。当浏览器在处理cookie时，WebKit的工做线程会挂起。当渲染器的I/O线程接受到浏览器的响应时，它会解除这个线程挂起，而后把结果传回给JavaScript引擎。