標籤:des style blog http java 使用
原文:Multi-process Resource Loading
背景
瀏覽器主進程及browser process處理所有的網路通訊。原因有三點:
- Browser process可以控制每一個renderer進程的網路訪問
- Browser process可以在進程間管理session狀態,保持其一致性
- Browser process可以針對每個host管理最大連結數
概述
作為一個多進程應用,Chrome分為三層。最底層的是webkit庫,它主要負責頁面渲染工作。之上是渲染進程Renderer Process(簡單來說,就是一個tab一個渲染進程)。每一個渲染進程包含一個WebKit執行個體。而管理這些渲染進程的則是最上層的Browser Process。這一層控制者所有的網路訪問。
WebKit
WebKit中負責拉取資料的對象是ResourceLoader。每一個loader均對應一個ResourceHandle。後者用於執行網路請求。ResourceHandle的標頭檔在WebKit代碼裡。我們無意於fork它。幸運的是,ResourceHandle有一個被稱為d的成員(ResourceHandleInternal)。我們移除了原有實現,替換成我們的實現。實現代碼在webkit/glue/resource_handle_win.cc。儘管名字中帶有win標識,但它與Win32沒有一毛錢的關係。
ResourceHandleInternal實現純虛介面ResourceLoaderBridge::Peer。該介面類定義位於webkit/glue/resource_loader_bridge.h檔案中。Renderer使用該callback介面向WebKit發送資料及其它事件(什麼其它事件呢??)。
WebKit中的ResourceHandleInternal通過ResourceLoaderBridge純虛介面與WebKit對話。該介面的一個實現參見ResourceLoaderBridge::Create。Create方法由Renderer實現。而Shell則使用不同的資源載入器,所以,也提供一種不同的實現方案。
Renderer
ResourceLoaderBridge在Renderer中的實現為IPCResourceLoaderBridge。該類位於renderer/resource_dispatcher。它使用一個全域的單例對象ResourceDispatcher(每個Render Process對應一個)產生一個唯一的請求ID,然後把請求轉寄給Browser(通過IPC方式)。響應資料則由Browser根據請求ID回送給ResourceLoaderBridge:Peer對象。
請求與資料間的對話由common/resource_loader_ipc完成。
Browser
RenderProcessHost對象(原作者也是個懶蟲,圖中居然沒有)接收來自Renderer的IPC請求。它把請求轉寄給全域對象ResourceDispatcherHost。ResourceDispatcherHost保留RenderProcessHost的指標地址,通過地址來引用render process host。ResourceDispatcherHost根據請求ID來唯一標識一個請求。
Browser將每一個請求轉化為URLRequest對象。URLRequest會把請求交給其內部類URLRequestJob。URLRequestJob與具體協議有關(又是個幹活的哦)。當URLRequest有通知時,它的ResourceDispatcherHost::Receiver和請求ID則用於發送通知給正確的RenderProcessHost。RenderProcessHost負責把通知發送給Renderer。
Cookies
(說到網路,Cookies是不得不談的,它方便又惡毒。)所有的Cookies均由CookieMonster(居然叫monster)處理。該類位於/net/base目錄下。我們不在WinInet(?)中共用cookies。cookie monster生存於browser進程中,處理所有的網路請求。
如果一個文檔需要請求cookies,Pages可以通過調用document.cookie來為它請求cookies。當該調用發生時,我們從Renderer發出一個同步訊息給Browser,達到請求cookies的目的。當Browser處理cookie時,WebKit會掛起。當Renderer的I/O收到來自Browser的響應時,Renderer取消WebKit掛起,把結果回送給JavaScript引擎。