ブラウザアーキテクチャの進化

プロセスとスレッド

• プロセスは、オペレーティング・システムのリソース割り当ての基本単位です；
• スレッドはオペレーティングシステムのスケジューリングの基本単位です；
• 同じプロセス内のスレッドは、プロセスに割り当てられたメモリリソースを共有できます。プロセス間通信はIPCによって実現されます；

上記の文章は決まり文句であり、以下の説明の方が私にとってはずっと友好的です：

• CPUのスピードが速すぎてレジスタが追いつくのがやっとで、RAMやバスにぶら下がる他のデバイスはまったく手が届かないというのが基本的な事実です。
• 知っておかなければならない事実：プログラムコードの一部を実行するには、CPUを入手した時点で、関連リソースがすでに配置されていなければならず、その後CPUが実行を開始します。ここで、CPU以外のすべてがプログラムの実行環境を構成し、プログラムコンテキストとも呼ばれます。プログラムの実行が終了するか、そのプログラムに割り当てられたCPUの時間を使い切ると、そのプログラムは切り替えられて、次にCPUに幸運が訪れるのを待たなければなりません。プログラムコンテキストは、次回CPUに恵まれたときに実行される環境なので、保存しておかなければなりません。
• CPUから見ると、すべてのタスクは1つずつ順番に実行されているように見えますが、具体的なローテーションの方法は、プログラムAのコンテキストをロードしてからAの実行を開始し、プログラムAのコンテキストを保存してから、次に実行されるプログラムBのプログラムコンテキストを呼び出してからBの実行を開始し、プログラムBのコンテキストを保存します。
• プロセスもスレッドも、粒の大きさは違えど、CPUの作業時間帯を記述したものです。
• IPCは、異なるプロセスが互いに通信するための手段の総称で、Chromiumの最新の用途はmojoです。

シングルプロセス アーキテクチャ

• 2007年当時、市場に出回っていたブラウザはシングルプロセスでした。

• ネットワーク、プラグイン、JavaScriptエンジン、レンダリングエンジンなどです。

• 短所：不安定、スムーズでない、安全でない。

  不安定：

  • プラグイン：初期のブラウザでは、ウェブビデオやウェブゲームなどの強力な機能を実装するためにプラグインが必要でした。しかし、プラグインは最も問題のあるモジュールであり、また、同じプロセスで実行されている他のモジュールも含んでいるため、プラグインが誤ってクラッシュすると、ブラウザ全体がクラッシュしてしまいます。
  • レンダリングエンジン：レンダリングエンジンも不安定で、通常、複雑なJSコードによってレンダリングエンジンがクラッシュすることがあり、プラグインと同様に、レンダリングエンジンのクラッシュがブラウザ全体のクラッシュを引き起こすこともあります。

  流暢ではありません：

  • 1つのスレッド：すべてのページレンダリングエンジン、JSエンジン、プラグインが同じスレッドで実行されています。もしそうだとしたら：無限ループのスクリプトがあり、それが実行されるとスレッド全体が占有され、そのスレッドで実行されている他のモジュールが実行される機会がなくなります。ブラウザ内のすべてのページがそのスレッドで実行されているため、どのページにもタスクを実行するチャンスがなく、ブラウザ全体が応答しなくなり、ラグが発生します。
  • メモリリーク：通常、ブラウザのカーネルは非常に複雑で、複雑なページを実行し、ページを閉じると、メモリが完全に時間の長い使用の問題につながるリサイクルすることはできません、より高いメモリ消費量は、ブラウザが遅くなります。

  安全ではありません：

  • プラグイン：ChromeはC/C++で記述されていますが、プラグインもC/C++やその他のコードで記述することができます。 プラグインを使用すると、オペレーティングシステムのあらゆるリソースにアクセスできます。ページ上でプラグインを実行すると、プラグインがコンピュータを完全に操作できることを意味します。ページ上でプラグインを実行することは、プラグインがあなたのコンピュータを完全に操作できることを意味します。 もし悪意のあるプラグインであれば、ウイルスをリリースしたり、アカウントのパスワードを盗んだり、セキュリティ上の問題を引き起こす可能性があります。
  • ページスクリプト：ページスクリプトは、ブラウザの脆弱性を利用してシステム権限にアクセスするために使用される可能性があります。

初期のChromeアーキテクチャ

• 2008年Chromeリリース当時のマルチプロセスアーキテクチャ
• 単一プロセスのアーキテクチャと比較した場合の変更点は？
  • メインのブラウザープロセスを分離。
  • レンダリングプロセスの分離。
  • セキュリティサンドボックス。
  • セキュリティ サンドボックス。
  • IPC によるプロセス間通信。
• どのような問題に取り組まれたのですか？

  • 不安定性、流動性、安全性の問題は、かなり解決されました。

    不安定性：シングルプロセスのアーキテクチャでは、プラグインやレンダリングエンジンが不安定性の主な原因です。しかし、マルチプロセスアーキテクチャでは、これらはすべて独自のプロセスで実行されるため、たとえクラッシュしてもブラウザや他のページに影響を与えません。

    滑らかさの欠如：シングルプロセス・アーキテクチャでは、すべてのページのレンダリングエンジン、JSエンジン、プラグインが同じスレッドで実行されるため、1つのページのJSが長時間実行されると、他のページが遅延します。しかし、マルチプロセスアーキテクチャでは、各ページが独自のレンダリングプロセスを持ち、プラグインもプロセスとして独立しているため、あるページのJSが長時間実行されても、他のページがラグることはありません。ページが閉じられると、レンダリングプロセス全体も閉じられ、そのプロセスが占有していたメモリはシステムによって回収されるため、ブラウザページのメモリリークの問題も簡単に解決できます。

    安全性：マルチプロセスアーキテクチャを使用する付加的な利点は、プロセスを操作の最小単位とする安全なサンドボックスを使用できることです。サンドボックスは、オペレーティング・システムがプロセスをロックしていると考えることができます。 サンドボックス内のプログラムは実行できますが、ハードドライブにデータを書き込んだり、機密性の高い場所のデータを読み取ったりすることはできません。これにより、悪意のあるプログラムがレンダリングプロセスやプラグインプロセスの内部で実行されたとしても、悪意のあるプログラムがサンドボックスを突破してシステム特権を得ることはできません。

現在のChromeマルチプロセッシングアーキテクチャ

• 現在のChromeマルチプロセスアーキテクチャ
• 以前のChromeマルチプロセッシング・アーキテクチャから何が変わったのですか？

  • GPUプロセスの追加：Chromeは最初GPUプロセスなしでリリースされ、当初は3D CSSエフェクトに使用されましたが、その後ウェブページやChromeのUIインターフェイスが描画にGPUを使用するようになり、GPUがブラウザの一般的な要件になりました。最後に、ChromeはマルチプロセスアーキテクチャにGPUプロセスを導入しました。

  • ウェブは、メインのブラウザプロセスとは別のウェブプロセスになりました。

プロセスの責任

• ブラウザのプロセス
  • アドレスバー、ブックマークバー、進む・戻るボタンなどの各セクションを担当；
  • インターフェイスの表示、ユーザーとの対話、サブプロセスの管理、ファイルアクセスなどの機能；
• レンダリングプロセス

  • 中心的なタスクは、HTML、CSS、JavaScriptをユーザーが操作できるウェブページに変換することです。このプロセスでは、レイアウトエンジンのBlinkとJavaScriptのV8エンジンの両方が実行されます；

  • デフォルトでは、Chromeはタブごとにプロセスモデル作成します。

    Googleは常にChromeを1タブ1プロセスモデルとして宣伝していますが、これは便宜上です。実際には、Chromeは宣伝されているよりもはるかに多くのプロセスモデルをサポートしており、Chromeは以下のプロセスモデルをサポートしています：

    • プロセス-パー-サイトインスタンス：ウェブサイトを開くと、そのウェブサイトからリンクされている同じドメインのウェブサイトが1つのプロセスに属します。これはChromeのデフォルトモデルです。
    • Process-per-site：同じドメインのウェブサイトは1つのプロセスに属します。例えば、 www.google.com と www.google.com/bookmarks は1つのドメインに属し、それらの間に関係があるかどうかに関係なく、それらはすべて1つのプロセスの一部としてカウントされます。コマンドライン --process-per-site で開きます。
    • Process-per-tab：スクリプト関連ページのグループが同じプロセスに属します。起動するには --process-per-tab を使ってください。
    • シングルプロセス：伝統的なブラウザモードで、マルチプロセスはなく、マルチスレッドのみです。

  • セキュリティ上の理由から、レンダリング プロセスは安全なサンドボックス内で実行されます；

• 3D CSSレンダリングを担当；
• ネットワークプロセス
  • はページのネットワークリソースの読み込みを担当します；
  • 最近までブラウザプロセス内のモジュールとして動作していましたが、独立した別プロセスとなりました；
• プラグインのプロセス
  • プラグインの動作を担当します；
  • プラグインはクラッシュしやすいため、プラグインプロセスのクラッシュがブラウザやページに影響しないように、プラグインプロセスによって分離する必要があります；

Chromeが1ページを開くのに何個のプロセスを開いていますか？

• 単一のレンダリングプロセス；
• ウェブプロセス；
• Chromeは、パワフルなデバイス上で複数のオーディオプロセスを実行します；
• リソースに制約のあるデバイスでは、Chromeは複数のプロセスで基本サービスを実行します；
• 1 GPUプロセス；
• N個のプラグイン・プロセスがあり、N >= 0；

長所と短所

• 利点
  • 不安定性、流動性、安全性の問題を大幅に解決：マルチプロセッシングアーキテクチャは、マルチプロセッシングモードとサンドボックスモードにより、ブラウザの安定性、流動性、安全性を向上させます。
• デメリット
  • リソースの使用量が多い：各レンダリングプロセスに共通のインフラストラクチャのコピーが含まれるため、ブラウザのメモリリソースの消費量が多くなります。
  • より複雑なアーキテクチャ：Chromeの開発チームは、当初からコードとアーキテクチャを過剰にエンジニアリングしないよう意識的に努めてきました。

Chrome サービス指向アーキテクチャ

複雑なアーキテクチャに起因するモジュール間の結合度の高さやスケーラビリティの低さという問題を解決するため、2016年、Chrome公式チームは「サービス指向アーキテクチャ」の考え方を用いた新しいChromeアーキテクチャを設計しました。これは、Chromeの全体的なアーキテクチャを、最新のオペレーティングシステムで使用されているサービス指向アーキテクチャに向けて進化させ、Chromeの目標であるシンプルさ、安定性、スピード、セキュリティをよりよく実現する、よりまとまりのある、結合の少ない、メンテナンスが容易で拡張しやすいシステムを構築することを意味しています。

• マルチプロセス・アーキテクチャにおける各レベルの依存関係

  フレームワーク層： 1. BlinkとV8はフレームワーク層に属します。2.例えば、BlinkはWebプラットフォームのレンダリングエンジンです。コード構造の観点から、"Blink "は一般的に"//third_party/blink/"ディレクトリのコードを意味します。プロジェクトの観点からは、「Blink」は通常、ウェブプラットフォームの機能を実装するプロジェクトを意味します。これらのWeb機能を実装するコードは、"//third_party/blink/"、"//content/renderer/"、"//content/browser/"などにあります。3.Blinkは、//third_party/blink/の機能をBlinkパブリックAPIを通じてPlatformレイヤーに公開します。

  Platform  
   1. その中のコンテンツは、Windows、Linux、Mac OS X、Androidを含む複数のオペレーティングシステム用の特定の実装を持つフレームワークレイヤーを提供し、その上に完全なブラウザアプリケーションを構築することができる。
   2. Content コンテンツ公開APIを通じて、フレームワーク層の機能を上位層のアプリケーションに公開する。
  

  アプリケーション層：

   Chrome / Android WebView / Chrome OSなど、コンテンツ層に基づいて実装された様々なアプリケーションは、エンベッダーと総称される。
  

• サービス指向アーキテクチャにおける各レベルの依存関係

  • Chromeは最終的に、プラットフォームの一部であったUI、ファイル、デバイス、ネットワーク、その他のモジュールを、基本的なオペレーティングシステムのサービスと同様の基本サービスにリファクタリングしました。マルチプロセスアーキテクチャとは対照的に、フレームワークとプラットフォームの依存関係は完全に逆転しています！
  • Chromeは現在、古いアーキテクチャからサービスアーキテクチャへの移行期にあります。例えば、私のローカルのChromeのバージョンはv83で、Network & Audioはブラウザのプロセスとは別のプロセスになっています。

サービス指向アーキテクチャを実装するには？

• 新しいIPCシステム→モジョを使用；
• UI、ファイル、デバイス、ネットワークなどの基本モジュールを個別のサービスに再編成し、それぞれが個別のプロセスで実行できるようにします；
• 定義されたインターフェイスを使用してサービスにアクセスし、Mojoを介して通信します；

Mojoとは?

• Mojoは、インターフェースごとに独立したメッセージパイプラインを作成する新しいIPCシステムで、異なるインターフェースのIPCが独立していることを保証します。メッセージパイプラインはインターフェースに対応し、このメッセージパイプラインは対応するインターフェースによって記述されたメッセージのみを送信することができます；
• メッセージパイプラインはエンドポイントのペアで構成され、それぞれが受信メッセージのキューを持ち、一方のエンドポイントでメッセージを書き込むと、そのメッセージがもう一方のエンドポイントにキューイングされるため、メッセージキューは双方向です；
• 古いIPCシステムは、2つのプロセス間の大きな名前付きパイプに基づいており、そのパイプを介してすべてのIPCメッセージがFIFO順序で渡されました；
• モジョは旧IPCシステムよりも24～34%高速で、コンテキスト・スイッチの回数が1/3少ない;Mojo Performance

モジョとの通信方法は？

• インターフェイスとコンパイルルールを定義します；

• リモート側でメッセージパイプラインを作成し、メッセージを送信し、受信者をブラウザプロセスに送信します；

• レシーバー側でインターフェースを実装します；

  例: Mojoを使用して、レンダリングプロセスからブラウザプロセスにメッセージを送信し、レンダリングプロセスにランダムな整数を返します。

  • インターフェイスを定義する新しい.mojomファイルを作成します；
  • 新しい BUILD.gn ファイルを作成し、C++/Java バインディングなど、異なる言語用のバインディングを生成するためのコンパイルルールを定義します；
  • メッセージパイプラインを作成し、リモート側でメッセージを送信します；
  • レシーバー側でインターフェイスを実装します；
  • レシーバー側でインターフェースを実装します；

サービスとは？

• サービスは、1つまたは複数の関連する機能または動作を実装するスタンドアロンのコードベースで、通常はブラウザプロセスによってプロキシされるMojoインターフェイス接続を介してのみ外部コードと対話します。
• 各サービスは、ブラウザがサービスインスタンスを管理するために使用できるマスターMojoインターフェースを定義し、実装します。

サービスの定義

• インターフェイスを定義する新しい.mojomファイルを作成します；
• 新しい BUILD.gn ファイルを作成し、C++ バインディングや Java バインディングなど、異なる言語のバインディングを生成するためのコンパイルルールを定義します；
• 定義されたインターフェイスを実装します；
• リンクサービスを別のプロセスとして実行できるようにします；
• サービスを開始します；

services お照会先

通常、基本サービスは//servicesディレクトリで定義され、モジュール固有のサービスはモジュールのservicesディレクトリ、例えば//chrome/servicesで定義されます。

利点

• 安定性、スムーズさ、安全性がさらに向上しました；

• 実験的な機能の実行：サービス指向アーキテクチャは、再利用可能で分離されたコンポーネントを生成します。このコンポーネントを組み合わせることで、Chrome チームや他のメンバーは、Chrome を変更せずに新しい機能を試すことができます。

• 柔軟で弾力性のあるアーキテクチャ：高性能なデバイスでは、基本サービスをマルチプロセスで実行し、リソースに制約のあるデバイスでは、基本サービスをブラウザプロセスに統合することでメモリを節約します；

  • リソースに制約のあるデバイス
  • リソースに制約のある設備

• モジョ＆サービス英語入門
• クロームサービスモデル
• モジョ
• プロセスモデル
• インサイドブラウザパート1
• クロム設計原則
• モジョとのコミュニケーション