chromium多进程资源加载

目录

1。背景

2。概述

3。WebKit

4.渲染器

5。浏览器

6.Cookies

背景

所有网络通信由主浏览器进程处理。这样做不仅使浏览器进程可以控制每个渲染器的访问网络，而且这样还使我们能保持如Cookies和缓存的数据等对话的数据贯穿所有的进程中。这一点很重要，这是因为，作为一个HTTP/1.1中用户端，一个浏览器不能对一个站点打开过多的连接。

在Windows上，我们目前使用的WinHTTP。在未来，我们计划用自定义HTTP以取代实现这一点。与WinInet相比的（我们有一个传统的实现）：

1.这两款都与所有的Windows版本支持（Win2K和更高版本）。

2.WinHTTP有更好的文档。WinInet中有更困难的API和参差不齐的文档。

3。WinHTTP有一个更清楚的我们所需要的API。WinInet中许多我们需要的函数（例如，SSL状态）没有文档，并且不支持，即使IE浏览器使用它们。

4.WinHTTP能够使我们实现自己的高速缓存。WinInet始终共用IE浏览器缓存。我们需要要控制我们自己的缓存，并且共享IE的缓存可能会导致问题，因为有些站点可能会特定浏览器的网页。

5。WinInet的是更好被IE浏览器使用的帐户进行测试。WinHTTP使用得不是非常多，是为服务器设计的。由服务器发送的非ASCII URL编码和生服务器连持连接上都有问题。我们要为这些问题的解决方法。

概述

我们的多进程应用程序可以被视为在三个树形的层面。在最低层次负责渲染网页的WebKit类库。在此之上是渲染进程（简单来说，每选项卡一个），每一个都包含一WebKit的实例。管理所有的渲染器的是浏览器进程，控制所有网络访问。

WebKit

WebKit的有ResourceLoader对象，它负责数据获取。每个装载器有一个ResourceHandle来执行实际的请求。此对象的头文件在WebKit的代码里面，我们不愿意仔细研究它。幸运的是，它包含一个成员，我们可以定义。我们删除旧的ResourceHandleInternal，的实现，并提供我们自己的，位于WebKit/glue/ resource_handle_win.cc。除了名字，它与Win32没有任何关系。

ResourceHandleInternal实现了虚拟接口ResourceLoaderBridge：：Peer，定义在WebKit/glue/ resource_loader_bridge.h。这是由渲染器的回调接口，用于调度通往WebKit的数据和其他事件。

WebKit内部的ResourceHandleInternal与渲染器交互（启动或取消的请求）通过ResourceLoaderBridge虚拟接口。一个接口实现的方法是是通过调用由渲染器实现的静态函数ResourceLoaderBridge::Create。测试外壳（Test Shell）采用了不同的资源加载器，所以提供了不同的实现，ResourceLoaderBridge的非IPC版本，位于WebKit/tools/test_shell/ simple_resource_loader_bridge。

渲染器

渲染器的ResourceLoaderBridge实现，称为IPCResourceLoaderBridge，位于renderer/ resource_dispatcher。它使用全局ResourceDispatcher单身对象（每个渲染进程一个为）来创建一个唯一的请求ID，然后将请求通过IPC转发到浏览器。从浏览器的响应将引用这个请求ID，然后由资源调度器负责转回ResourceLoaderBridge::Peer对象(在WebKit的内部)。

资源请求和他们之间数据的转换是由common/resource_loader_ipc处理的。渲染器和浏览器都共享这个代码，使转换是同步的。

浏览器

在浏览器内的RenderProcessHost对象接收来自每个渲染器IPC的请求。这些请求转发给它的全局的ResourceDispatcherHost，，用一个指针来指向渲染进程（render process host）（特别是，一个ResourceDispatcherHost::Receiver的实现）和由渲染器所产生的唯一标识请求的请求ID。

每个请求，然后转换成一个URLRequest对象，这反过来又转发到它的内部URLRequestJob，由它实现需要的具体协议。当URLRequest 生成通知时，其ResourceDispatcherHost::Receiver和请求ID被用来发送通知到正确的RenderProcessHost并发送回渲染器。因为被渲染器生成的ID是保留的，它能够与关联所有的响应和由WebKit生成的特定的请求。

Cookies

所有Cookie都由CookieMonster对象处理，在/net/base中。我们不与WinInet分享Cookies。CookieMonster生存在浏览器进程中，处理所有的网络请求，因为Cookies需要在所有标签中是相同的。

页面可以通过document.cookie来请求Cookies。当发生这种情况时，我们从渲染器发送一个同步消息到浏览器请求cookie。当浏览器处理cookie时，WebKit工作的线程就被挂起。当渲染器的I / O线程接收来自浏览器的响应，它取消挂起的线程并传递结果返回给JavaScript引擎。