多进程资源加载
来源:互联网 发布:商店软件下载 编辑:程序博客网 时间:2024/05/17 22:14
转自http://nickandmiles.blog.163.com/blog/static/2342212320104319059717/
多进程资源加载
http://www.chromium.org.sixxs.org/developers/design-documents/multi-process-resource-loading
目录
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引擎。
- 多进程资源加载
- chromium多进程资源加载
- Chromium的多进程资源加载
- [Chromium中文文档]多进程资源加载
- 理解WebKit和Chromium: Chromium的多进程资源加载机制
- cocos2dx多套资源加载
- 进程资源
- 进程资源
- 加载资源
- 加载资源
- 资源加载
- 进程加载
- 多进程竞争资源----哲学家就餐问题
- 多界面 资源异步加载收尾总结
- 查看进程资源
- 查看进程资源
- 进程资源限制
- 取消进程释放资源
- 类的继承
- linux进程切换,进程上下文,thread_union数据结构(task_union V0.11)
- Ubuntu下浏览器Java插件安装及启用
- I/O重定向 详解及例子!
- 关于信息技术,提几个观点,不做具体解释,不知道有没有相同观点的人
- 多进程资源加载
- Linux内核编译
- 黑马程序员-------命运的开始我会努力!!java基础-------
- spring注解的运用
- Chromium如何显示网页
- Win7 & VS2013 编译 WebKit 总结
- 2014.01.10
- 设计模式(1)—— MVC
- Handler: Service中使用Toast