http://dev.chromium.org/developers/design-documents/multi-process-resource-loading

 
ここの情報は古い

背景

すべてのネットワーク通信はメインのブラウザプロセスでハンドルされる。レンダラのアクセス制限目的とセッションデータやキャッシュの一貫性を保つため。HTTP/1.1で多くの接続を張りたく無いのもある。

全体像

マルチプロセス構造は以下のような３つの層で考えられる。最下層はBlinkエンジンでレンダリングを行う。その上はレンダラプロセスで１つのBlinkインスタンスを持つ。これら２つを管理するのがブラウザプロセスでこれがネットワークアクセスを管理する。

Blink

BlinkはResouceLoaderオブジェクトを持ち、データ取得の責任を持つ。それぞれのローダはリクエストごとのWebURLLoaderを持つ。

ResourceLoaderはWebURLLoaderClientインタフェースを実装、これはコールバックインターフェースで、レンダラがBlinkにデータをディスパッチする。

レンダラ

レンダラのWebURLLoader実装であるWebURLLoaderImplはcontent/child/に置かれる。プロセスで１つだけもつResourceDispatcherを使い一意のリクエストIDを作成し、リクエストをIPCでブラウザに転送する。ブラウザからの返答はこのリクエストIDを参照していて、リソースディスパッチャーによってRequestPeerオブジェクト（WebURLRequestImpl）に戻される。

ブラウザ

ブラウザ内のRenderProcessHostオブジェクトはレンダラからIPCリクエストを受けとり、グローバルなResourceDispatcherHostへ転送する。using a pointer to the render process host (specifically, an implementation of ResourceDispatcherHost::Receiver) and the request ID generated by the renderer to uniquely identify the request.

それぞれのリクエストはURLRequestオブジェクトに変換され、内部のURLRequestJobへ転送され、プロトコルごとの処理が行われる。URLRequestが通知を生成したとき、それのResourceDispatcherHost::Receiver と request IDによってRenderProcessHostが見つけされて、レンダラーに送り返される。レンダラによって生成されたIDは保存されているので、すべてのレスポンスを特定のリクエスト（最初はBlinkで生成された）と関連付けることができる。

クッキー

すべてのクッキーは/net/base内のCookieMonsterオブジェクトでハンドルされる。クッキーは他のブラウザのネットワークスタック（WinINETやNecko）と共有されない。クッキーモンスターはブラウザプロセス内にあり、すべてのネットワークリクエストをハンドルする。なぜならクッキーはすべてのタブ間で同じでないとならないから。

ページはドキュメントに対してdocument.cookieでクッキーを要求できる。これが起こったとき、レンダラからブラウザへのクッキーをリクエストする同期メッセージが送られる。ブラウザがクッキーを処理している間、Blinkのスレッドは待機させられる。レンダラのIOスレッドがレスポンスを受け取ったとき、待機が終了し、受け取った結果をJavaScriptエンジンに渡す。