https://www.chromium.org/developers/design-documents/multi-process-architecture

Chromiumの高レベルアーキテクチャ

問題点

クラッシュしたりハングしたりしないレンダリングエンジンをつくるのはすごく難しい。完全に安全なものもつくるのが難しい。

２００６年ごろのブラウザは、過去のシングルユーザ、マルチタスクOSみたいなものだった。おかしなアプリがOSをダウンさせたように、おかしなウェブページがブラウザをダウンさせた。１つのブラウザやプラグインのバグがブラウザ全体をダウンさせ全タブがダウンした。

現代のOSはもっと堅牢になるようプロセスを分けていてその間は壁で仕切られている。１つのアプリケーションのクラッシュが他のアプリケーションに害を及ぼさない。そしてユーザごとの制限されたデータを持ち他のユーザから制限される。

アーキテクチャ全体図

レンダリングエンジンのバグから守るために、ブラウザのタブに個別のプロセスを割り当てる。レンダリングエンジンにはアクセス制限も課す。これでOSのような保護を得られる。 メインプロセスはブラウザプロセスあるいはブラウザと呼ばれ、UIを走らせタブを管理しプラグインプロセスを管理する。個々のタブのプロセスはレンダープロセスあるいはレンダラーと呼ばれる。レンダラーはBlinkオープンソースレイアウトエンジンが使われる。

レンダープロセスの管理

それぞれのレンダープロセスはグローバルオブジェクトRenderProcessをもち、これが親ブラウザプロセスとの通信を行ったり、グローバル状態を管理する。ブラウザはこれと対となるRenderProcessHostを各レンダープロセスに対してもち、レンダラとの通信やブラウザ状態管理をする。通信はChromium IPC Systemをつかって行われる。

ビューの管理

レンダープロセスは１個以上のRenderViewをもち、それらはタブの内容になる。対してRenderProcessHostはRenderViewHostをもつ。

コンポーネントとインターフェース

レンダープロセスでは：

• RenderProcessとRenderProcessHostがIPCのやり取りをする。
• RenderViewはRenderProcessHostと通信する（RenderProcessを通じて）。

ブラウザプロセスでは：

• Browserオブジェクトがトップレベルのブラウザウインドウを表す。
• RenderViewHostはRenderViewとの通信をカプセル化する。
• RenderWidgetHostがRenderWidgetの入力や描画をカプセル化する。

レンダープロセスの共有

新しいタブが開かれたとき、ブラウザはプロセスを作成し１つのRenderViewを作成するよう指示する。

時にはレンダープロセスをタブ間で共有することが望ましい場合もある。Javascriptのwindow.open()で開かれ同期通信する場合や、プロセスが多すぎる場合や、開かれるドメインのが既に開かれていた場合など。

クラッシュの監視と行儀の悪いレンダラ

IPC接続はプロセスハンドルを監視していて、これがシグナル化した時はレンダープロセスがクラッシュしたということでタブは悲しいのタブになる。

レンダラのサンドボックス化

サンドボックスによってレンダラのアクセスを制限する。例えばネットワークアクセスはブラウザを通してのみ行う。ファイルアクセスはOSの機能を通じて行う。 それに加えてレンダラはユーザからはみえないDesktopで実行される。これは浸食されたレンダラが新規ウインドウを開いたり、キーストロークをキャプチャするのを防ぐ。