注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

写着玩

Bob

 
 
 

日志

 
 
 
 

Multi-process Resource Loading  

2010-01-10 21:13:56|  分类: Chrome |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

Background

All network communication is handled by the main browser process. This is done not only so that the browser process can control each renderer's access to the network, but also so that we can maintain consistent session state across processes like cookies and cached data. It is also important because as a HTTP/1.1 user-agent, the browser as a whole should not open too many connections per host.

On Windows, we currently use WinHTTP. In the future, we plan to replace this with a custom HTTP implementation.  Compared to WinInet (which we have a legacy implementation for):

  1. Both come with all Windows versions we plan to support (Win2K and later).
  2. WinHTTP is better documented. WinInet has a more difficult API and spotty documentation.
  3. WinHTTP has a cleaner API with the support we need. A number of WinInet functions that are necessary for us (for example, for SSL state) are undocumented and unsupported, even though IE uses them.
  4. WinHTTP allows us to implement our own cache. WinInet always shares a cache with IE. We would like to control our own caching, and also sharing a cache with IE can cause problems since some sites may serve browser-specific pages.
  5. WinInet is better battle tested on account of being used by IE. WinHTTP is not used very much, and was designed for server use. It has problems with non-ASCII URL encodings sent by the server and keepalive connections. We have to provide workarounds for these issues.

Overview

Our multi-process application can be viewed in three layers. At the lowest layer is the WebKit library which renders pages. Above that are the renderer process (simplistically, one-per-tab), each of which contains one WebKit instance. Managing all the renderers is the browser process, which controls all network accesses.

Multi-process Resource Loading - yolcy - 写着玩

WebKit

WebKit has a de style="color: rgb(0, 96, 0); "<ResourceLoaderde< object which is responsible for fetching data. Each loader has a de style="color: rgb(0, 96, 0); "<ResourceHandlede< for performing the actual requests. The header file for this object is inside the WebKit code, and we are unwilling to fork it. Fortunately, it contains a de style="color: rgb(0, 96, 0); "<dde< member which we can define. We remove the old implementation of de style="color: rgb(0, 96, 0); "<ResourceHandleInternalde< and provide our own, located in de style="color: rgb(0, 96, 0); "<webkit/glue/resource_handle_win.ccde<. Despite the name, it has nothing to do with Win32.

de style="color: rgb(0, 96, 0); "<ResourceHandleInternalde< implements the virtual interface de style="color: rgb(0, 96, 0); "<ResourceLoaderBridge::Peerde<, defined in de style="color: rgb(0, 96, 0); "<webkit/glue/resource_loader_bridge.hde<. This is the callback interface used by the renderer to dispatch data and other events to WebKit.

de style="color: rgb(0, 96, 0); "<ResourceHandleInternalde< inside WebKit talks to the renderer (to initiate or cancel requests) via the de style="color: rgb(0, 96, 0); "<ResourceLoaderBridgede< virtual interface. An implementation of this interface is retrieved by calling the static function de style="color: rgb(0, 96, 0); "<ResourceLoaderBridge::Createde<, which the renderer implements. The test shell uses a different resource loader, so provides a different implementation, non-IPC version of de style="color: rgb(0, 96, 0); "<ResourceLoaderBridgede<, located in de style="color: rgb(0, 96, 0); "<webkit/tools/test_shell/simple_resource_loader_bridgede<.

Renderer

The renderer's implementation of de style="color: rgb(0, 96, 0); "<ResourceLoaderBridgede<, called de style="color: rgb(0, 96, 0); "<IPCResourceLoaderBridgede<, is located in de style="color: rgb(0, 96, 0); "<renderer/resource_dispatcherde<. It uses the global de style="color: rgb(0, 96, 0); "<ResourceDispatcherde< singleton object (one for each renderer process) to create a unique request ID and forward the request to the browser via IPC. Responses from the browser will reference this request ID, which can then be converted back to the de style="color: rgb(0, 96, 0); "<ResourceLoaderBridge::Peerde< object (inside WebKit) by the resource dispatcher.

The conversion between resource requests and their data is all handled by de style="color: rgb(0, 96, 0); "<common/resource_loader_ipcde<. The renderer and the browser both share this code so that the conversions are in sync.

Browser

The de style="color: rgb(0, 96, 0); "<RenderProcessHostde< objects inside the browser receive the IPC requests from each renderer. It forwards these requests to the global de style="color: rgb(0, 96, 0); "<ResourceDispatcherHostde<, using a pointer to the render process host (specifically, an implementation of de style="color: rgb(0, 96, 0); "<ResourceDispatcherHost::Receiverde<) and the request ID generated by the renderer to uniquely identify the request.

Each request is then converted into a de style="color: rgb(0, 96, 0); "<URLRequestde< object, which in turn forwards it to it's internal de style="color: rgb(0, 96, 0); "<URLRequestJobde< that implements the specific protocol desired. When the de style="color: rgb(0, 96, 0); "<URLRequestde< generates notifications, its de style="color: rgb(0, 96, 0); "<ResourceDispatcherHost::Receiverde< and request ID are used to send the notification to the correct de style="color: rgb(0, 96, 0); "<RenderProcessHostde< for sending back to the renderer. Since the ID generated by the renderer is preserved, it is able to correlate all responses with a specific request first generated by WebKit.

Cookies

All cookies are handled by our de style="color: rgb(0, 96, 0); "<CookieMonsterde< object in de style="color: rgb(0, 96, 0); "</net/basede<. We do not share cookies with WinInet. The cookie monster lives in the browser process which handles all network requests because cookies need to be the same across all tabs.

Pages can request cookies for a document via de style="color: rgb(0, 96, 0); "<document.cookiede<. When this occurs, we send a synchronous message from the renderer to the browser requesting the cookie. While the browser is processing the cookie, the thread that WebKit works on is suspended. When the renderer's I/O thread receives the response from the browser, it un-suspends the thread and passes the result back to the JavaScript engine.

  评论这张
 
阅读(374)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017