多進程資源加載
全書地址
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引擎。