diff options
Diffstat (limited to 'files/ja/mozilla/firefox/multiprocess_firefox/目的/index.html')
| -rw-r--r-- | files/ja/mozilla/firefox/multiprocess_firefox/目的/index.html | 44 |
1 files changed, 44 insertions, 0 deletions
diff --git a/files/ja/mozilla/firefox/multiprocess_firefox/目的/index.html b/files/ja/mozilla/firefox/multiprocess_firefox/目的/index.html new file mode 100644 index 0000000000..b9635595c4 --- /dev/null +++ b/files/ja/mozilla/firefox/multiprocess_firefox/目的/index.html @@ -0,0 +1,44 @@ +--- +title: マルチプロセス化を行う理由 +slug: Mozilla/Firefox/Multiprocess_Firefox/目的 +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Motivation +--- +<p>Firefoxがコンテンツを別のプロセスで動作するようにするには、３つの目的があります。:それは、パフォーマンス、セキュリティ、安定性です</p> + +<h2 id="パフォーマンス">パフォーマンス</h2> + +<p>Mozilla は過去2年間、ブラウザの応答性の向上に注力してきました。その目的は<a href="/docs/Glossary/Jank">プチフリ</a>、つまり大きなページをロードしているときやタイピング中、もしくはスクロール中にブラウザがフリーズしたように見える状況を減らすことにありました。近年、応答性はスループットよりも重要になりつつあります。応答性の向上に関する様々な改良は、<a href="https://wiki.mozilla.org/Performance/Snappy">Snappy project</a> の一部として達成されました。主な点を挙げると以下の通りになります：</p> + +<ul> + <li>メインスレッドがユーザへの応答を続けられるようにするために、時間のかかる処理の別スレッドへの移行すること</li> + <li>入出力によってメインスレッドがブロックされるのさけるため、入出力を別スレッドで非同期に行うこと</li> + <li>インクリメンタルGC に代表される時間のかかる処理を細かく分割し、イベントループ中で処理を行うように変更すること</li> +</ul> + +<p>すぐにできる改良の多くは成されており、残った問題は修正が難しい物ばかりでした。例えば JavaScript の実行やメインスレッドで行われるレイアウト処理などです。これらはイベントループをブロックするのですが、別のプロセスへ分離するには難しい処理でもあります。これらの処理は DOM のようなデータにアクセスする必要がありますが、これらのデータはスレッドセーフではないからです。他の選択肢として、イベントループを JavaScript の処理の中に入れる事も検討しましたが、Firefox の他の部分（アドオンではありません）によって難しい事がわかりました。</p> + +<p>Web コンテンツを別のプロセスに分離する事は、良い代替策でした。スレッドを利用するアプローチと同様、Firefox は JavaScript やレイアウト処理がコンテントプロセスで行われている間に イベントループを実行できる上に、DOM やコンテンツデータにアクセスしない UI のコードをスレッドセーフにしなくても済みます。その反面、Firefox の UI プロセスは明示的にメッセージパッシングを行わないとコンテンツデータにアクセスできなくなります。</p> + +<p>このトレードオフはいくつかの理由から許容できると考えています：</p> + +<ul> + <li>すべての Firefox のコードがよくコンテンツ DOM にアクセスするわけではない</li> + <li>Firefox OS と共有されているコードはすでにメッセージパッシングを利用するものになっていること</li> + <li>マルチプロセスモデルでのメッセージパッシングを利用したコンテントアクセスはその失敗が明白であるのに対し、適切なロックなしに行われたコンテンツアクセスに起因するスレッドのバグは発見が難しくデバッグも困難であるため</li> +</ul> + +<h2 id="セキュリティ">セキュリティ</h2> + +<p>Firefox に攻撃可能なバグがあった場合、それを利用してユーザのコンピュータを乗っ取ることが可能です。この問題の解決策として最も強力なものは、<a href="http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29">サンドボックス化</a>です。 技術的にはサンドボックス化にマルチプロセス化は必要ありません。しかしシングルプロセスの Firefox 上でサンドボックス化を行っても、あまり有用ではありません。サンドボックスはあくまでプロセスが、通常のプロセスがしないような振る舞いをするのを阻止するための機能です。アドオンがインストールされている場合が典型的ですが、Firefox の通常プロセスはネットワーク通信やファイルへのアクセスを行います。そのため、シングルプロセスの Firefox では制限をうまく掛けることが難しくなっています。</p> + +<p>マルチプロセス化したFirefoxでのコンテンツプロセスは、サンドボックス化されます。通常、コンテンツプロセスはファイルシステムに直接アクセスすることはありません。そのような場合はメインプロセスに対してファイルアクセスリクエストを送ります。メインプロセスは、そのリクエストが妥当なものかを検証できるため、コンテンツプロセスに対するサンドボックスの制限は極めて厳しいものなります。その結果として、Firefox にセキュリティホールを作ることが難しくなると期待されます。</p> + +<h2 id="安定性">安定性</h2> + +<p>Web ページ中で実行されるプログラムがクラッシュした場合、ブラウザ全体が停止してしまします。マルチプロセス化することによって、停止するのはクラッシュしたプログラムの動作するコンテントプロセスのみとなります。</p> + +<div class="note"> +<p>このページの内容の多くは、Bill McCloskey のブログポストの内容を含んでいます。詳しくはこちらをご覧ください： <a href="http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/">http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/</a></p> +</div> + +<p> </p> |