【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引擎。