轉(zhuǎn)載請(qǐng)注明出處：
https://ahangchen.gitbooks.io/chromium_doc_zh/content/zh/General_Architecture/Process_Models.html
全書(shū)地址
Chromium中文文檔 for https://www.chromium.org/developers/design-documents
持續(xù)更新ing，歡迎star
gitbook地址：https://ahangchen.gitbooks.io/chromium_doc_zh/content/zh//
github地址： https://github.com/ahangchen/Chromium_doc_zh
這個(gè)文檔描述了Chromium支持的不同線程模型，包括它的渲染器進(jìn)程，以及現(xiàn)有模型實(shí)現(xiàn)的問(wèn)題。
概述
網(wǎng)頁(yè)內(nèi)容已經(jīng)發(fā)展到包含大量在瀏覽器內(nèi)運(yùn)行的活躍代碼的地步，使得許多網(wǎng)站更像應(yīng)用程序而非文檔。這種變革改變了瀏覽器的角色，從一個(gè)簡(jiǎn)單的文檔渲染器變成一個(gè)操作系統(tǒng)。Chromium構(gòu)建得像一個(gè)操作系統(tǒng)那樣，使用多進(jìn)程隔離每個(gè)網(wǎng)站和瀏覽器自身，以一種安全而魯棒的方式運(yùn)行這些程序。這提高了魯棒性，因?yàn)槊總€(gè)進(jìn)程運(yùn)行在自己的地址空間里，由操作系統(tǒng)調(diào)度，即使崩潰也不會(huì)互相影響。用戶也可以在Chromium的任務(wù)管理器里查看每個(gè)進(jìn)程的資源使用情況。
Web瀏覽器有許多方法可以分割成不同的操作系統(tǒng)進(jìn)程，最佳的架構(gòu)的選擇取決于許多因素，包括穩(wěn)定性，資源使用，對(duì)實(shí)際情況的觀察。Chromium支持四種不同的進(jìn)程模型，允許開(kāi)發(fā)者實(shí)驗(yàn)，也有最適合大部分用戶的默認(rèn)模式。
支持的模型
Chromium支持四種不同的模型，它們影響瀏覽器分配頁(yè)面給渲染進(jìn)程的行為。默認(rèn)情況下，Chromium為用戶訪問(wèn)的每個(gè)網(wǎng)站使用一個(gè)獨(dú)立的操作系統(tǒng)進(jìn)程。然而，用戶可以在啟動(dòng)Chromium時(shí)指定命令行選項(xiàng)，以選擇其他的架構(gòu)：全網(wǎng)站單進(jìn)程，每組相連標(biāo)簽頁(yè)一個(gè)進(jìn)程，或者每個(gè)東西都放在一個(gè)單獨(dú)的進(jìn)程中。這些模型的區(qū)別在于他們是否影響內(nèi)容的源，是否影響標(biāo)簽頁(yè)間的關(guān)系，或者兩者都會(huì)影響。這個(gè)章節(jié)在更深的細(xì)節(jié)上討論每種模型，并在這個(gè)文檔的后面描述當(dāng)前Chromium的實(shí)現(xiàn)的一些問(wèn)題。
單網(wǎng)站實(shí)例單進(jìn)程
默認(rèn)情況下，Chromium為用戶訪問(wèn)的每個(gè)網(wǎng)站實(shí)例創(chuàng)建一個(gè)渲染器進(jìn)程。這保證了不同網(wǎng)站的網(wǎng)頁(yè)獨(dú)立渲染，讓對(duì)同一個(gè)網(wǎng)站的不同訪問(wèn)相互獨(dú)立。因此一個(gè)網(wǎng)站實(shí)例中的失敗（比如，渲染器崩潰）或者重的資源使用不會(huì)影響瀏覽器的其他部分。這個(gè)模型基于內(nèi)容的源和腳本會(huì)相互影響的標(biāo)簽頁(yè)間的關(guān)系。因此，兩個(gè)標(biāo)簽頁(yè)可以在同一個(gè)渲染進(jìn)程里展示頁(yè)面，同時(shí)在給定的一個(gè)標(biāo)簽頁(yè)中導(dǎo)航到網(wǎng)站外的一個(gè)網(wǎng)頁(yè)，可能切換標(biāo)簽頁(yè)的渲染進(jìn)程。（注意，Chromium當(dāng)前的實(shí)現(xiàn)有一些重要的問(wèn)題，會(huì)在下面的Caveat(警告)部分討論。）
具體說(shuō)來(lái)，我們把一個(gè)注冊(cè)域名（例如：google.com或bbc.co.uk）加一個(gè)scheme（例如：https:// ）定義為一個(gè)網(wǎng)站。這與同源策略定義相似，但它將子域名（比如：mail.google.com和docs.google.com）和端口（比如http://foo.com:8080 ）合并到同一個(gè)網(wǎng)站中。允許網(wǎng)站的不同子域名或端口中的頁(yè)面通過(guò)Javascript訪問(wèn)是有必要的，如果他們的document.domain變量相同的話，同源策略也會(huì)這樣允許。
一個(gè)網(wǎng)站實(shí)例是一些相同網(wǎng)站的相連網(wǎng)頁(yè)的集合。我們這樣認(rèn)為兩個(gè)頁(yè)面是相連的：如果他們可以在腳本代碼中獲取彼此的引用的話（比如：如果一個(gè)頁(yè)面被另一個(gè)頁(yè)面用Javascript在一個(gè)新窗口中打開(kāi)）。
優(yōu)點(diǎn)
- 隔離不同網(wǎng)站的內(nèi)容。這提供了網(wǎng)頁(yè)內(nèi)容的命運(yùn)共享的一種有意義的形式，在這種形式中，網(wǎng)頁(yè)間的失敗不會(huì)相互影響。
- 隔離展示相同網(wǎng)站的獨(dú)立標(biāo)簽頁(yè)。在不同的標(biāo)簽頁(yè)中獨(dú)立訪問(wèn)同樣的網(wǎng)站會(huì)創(chuàng)建不同的進(jìn)程。這可以避免同個(gè)實(shí)例中的爭(zhēng)奪與失敗，使其不會(huì)影響其他實(shí)例。
缺點(diǎn)
- 更多的內(nèi)存負(fù)載。在大多數(shù)工作負(fù)載下，這個(gè)模型會(huì)比下面的每個(gè)網(wǎng)站一個(gè)進(jìn)程創(chuàng)建更多渲染器進(jìn)程。這雖然能增加穩(wěn)定性并且增加并發(fā)的機(jī)會(huì)，但它也增加了內(nèi)存負(fù)載。
- 更復(fù)雜的實(shí)現(xiàn)。不像每個(gè)標(biāo)簽頁(yè)一個(gè)進(jìn)程或者單進(jìn)程，這個(gè)模型需要復(fù)雜的邏輯以支持標(biāo)簽在網(wǎng)頁(yè)間導(dǎo)航時(shí)的進(jìn)程交換，以及代理一些允許的源之間的JavaScript行為，比如傳遞消息。（關(guān)于這個(gè)話題的更多內(nèi)容以及我們正在進(jìn)行的對(duì)這種模型的完全支持的努力，查看下面的Caveats(警告)部分以及我們的站點(diǎn)隔離工程頁(yè)面。）
單網(wǎng)站單進(jìn)程
Chromium也支持這樣一種進(jìn)程模式，隔離不同的網(wǎng)站，但將相同網(wǎng)站的所有實(shí)例組合到一塊。為了使用這個(gè)模型，用戶需要在啟動(dòng)Chromium時(shí)在終端指定 --process-per-site開(kāi)關(guān)。這創(chuàng)建更少的渲染進(jìn)程，用魯棒性交換更少的內(nèi)存占用。這個(gè)模型基于內(nèi)容的源，而非標(biāo)簽頁(yè)間的關(guān)系。
優(yōu)點(diǎn)
隔離不同網(wǎng)站的內(nèi)容。正如每個(gè)網(wǎng)站實(shí)例一個(gè)進(jìn)程的模型那樣，不同網(wǎng)站的頁(yè)面不會(huì)共享命運(yùn)（不會(huì)同生共死。。）。
更少的內(nèi)存占用。這個(gè)模型比上一個(gè)模型和每個(gè)標(biāo)簽一個(gè)進(jìn)程的模型可能創(chuàng)建更少的并行進(jìn)程。這對(duì)于減少Chromium的內(nèi)存足跡可能是需要的。
缺點(diǎn)
- 可能導(dǎo)致更大的渲染進(jìn)程。像google.com這樣的站點(diǎn)上有著大量的應(yīng)用程序，它們可能在瀏覽器里被同時(shí)打開(kāi)，并且全部在同一個(gè)進(jìn)程里渲染。因此，這些應(yīng)用程序中的資源爭(zhēng)奪與失敗會(huì)影響許多標(biāo)簽頁(yè)，使得瀏覽器看起來(lái)不能更好地響應(yīng)。不幸的是，在細(xì)粒度上而非通過(guò)注冊(cè)域名區(qū)分網(wǎng)站邊界，并且不影響向后兼容性是很困難的。
- 實(shí)現(xiàn)更加復(fù)雜。與每個(gè)網(wǎng)站實(shí)例一個(gè)進(jìn)程的模型相似，這需要在導(dǎo)航中交換進(jìn)程以及代理一些javascript操作的邏輯。
單標(biāo)簽頁(yè)單進(jìn)程
每個(gè)網(wǎng)站或每個(gè)網(wǎng)站實(shí)例一個(gè)進(jìn)程都需要在創(chuàng)建渲染進(jìn)程時(shí)考慮網(wǎng)站內(nèi)容的源。Chromium也支持一種簡(jiǎn)單的模型，將一個(gè)渲染器進(jìn)程分配給每組腳本相關(guān)的標(biāo)簽頁(yè)。這個(gè)模型可以使用 --process-per-tab命令行開(kāi)關(guān)來(lái)選中。
特別地，我們會(huì)把一些腳本相關(guān)聯(lián)的標(biāo)簽頁(yè)成為一個(gè)瀏覽實(shí)例，它也與HTML5范疇中的“一個(gè)瀏覽上下文單元”對(duì)應(yīng)。這個(gè)集合由一個(gè)標(biāo)簽以及這個(gè)標(biāo)簽用javascript代碼所打開(kāi)的標(biāo)簽組合而成。這樣的標(biāo)簽必須在同一個(gè)進(jìn)程中渲染，以允許在這些標(biāo)簽頁(yè)間執(zhí)行javascript調(diào)用（大多數(shù)通常發(fā)生在同源頁(yè)面之間）。
優(yōu)點(diǎn)
- 容易理解。每個(gè)標(biāo)簽頁(yè)分配有一個(gè)渲染進(jìn)程，并不會(huì)隨時(shí)間改變。
缺點(diǎn)
- 導(dǎo)致我們不想要的頁(yè)面之間命運(yùn)共享。如果用戶在瀏覽實(shí)例中導(dǎo)航一個(gè)標(biāo)簽頁(yè)到一個(gè)不同的網(wǎng)站中，新的頁(yè)面會(huì)和其他在同一個(gè)瀏覽實(shí)例中的任何其他標(biāo)簽頁(yè)共享命運(yùn)。
某些情況下，盡管處于安全的需要，在這個(gè)模型中，Chromium仍然強(qiáng)制標(biāo)簽頁(yè)中的進(jìn)程交換已經(jīng)沒(méi)有什么價(jià)值。例如，通常的網(wǎng)頁(yè)不允許與優(yōu)先級(jí)高的網(wǎng)頁(yè)（比如設(shè)置，或者新標(biāo)簽頁(yè)）共享進(jìn)程。因此，這個(gè)模型在實(shí)踐中并沒(méi)有比單個(gè)網(wǎng)站實(shí)例單進(jìn)程更簡(jiǎn)單。
單進(jìn)程
最后，出于比較的目的，Chromium支持單進(jìn)程模型，通過(guò)--single-process命令行開(kāi)關(guān)打開(kāi)。在這個(gè)模型中，瀏覽器和渲染引擎跑在同一個(gè)操作系統(tǒng)進(jìn)程里。
單進(jìn)程模型提供了一個(gè)衡量多進(jìn)程架構(gòu)帶來(lái)的負(fù)荷的基線。這不是一個(gè)安全的架構(gòu)，也不是一個(gè)魯棒的架構(gòu)，因?yàn)槿魏武秩酒鞯谋罎?huì)導(dǎo)致整個(gè)瀏覽器進(jìn)程掛掉。它只是設(shè)計(jì)用于測(cè)試和開(kāi)發(fā)目的，并且可能包含在其他架構(gòu)中沒(méi)有的bug。
沙箱與插件
在每個(gè)多進(jìn)程架構(gòu)里，Chromium的渲染器進(jìn)程運(yùn)行在一個(gè)沙箱進(jìn)程中，它對(duì)用戶電腦只有有限的訪問(wèn)權(quán)限。這些進(jìn)程對(duì)用戶的文件系統(tǒng)，顯示器，或者大部分其他的資源沒(méi)有直接的接觸。相反，他們只通過(guò)瀏覽器進(jìn)程獲得對(duì)允許的資源的訪問(wèn)，而瀏覽器進(jìn)程可以在這種訪問(wèn)上附加安全策略。因此，Chromium的瀏覽器進(jìn)程可以減輕一個(gè)被利用的渲染器引擎能做的事情。
瀏覽器插件，比如Flash和Silverlight，也在他們自己的進(jìn)程中執(zhí)行，并且有些插件，比如Flash運(yùn)行在Chromium的沙箱中。在Chromium支持的每個(gè)多進(jìn)程架構(gòu)中，對(duì)每種活躍的插件都只有一個(gè)進(jìn)程。因此，所有的Flash實(shí)例運(yùn)行在同一個(gè)進(jìn)程里，不論它們出現(xiàn)在哪個(gè)網(wǎng)站或標(biāo)簽頁(yè)中。
警告
這個(gè)部分列出一些Chromium當(dāng)前進(jìn)程模型實(shí)現(xiàn)的警告，以及它們的意義。
- 大多數(shù)始于渲染器的標(biāo)簽頁(yè)中的導(dǎo)航還沒(méi)有列入進(jìn)程交換中。如果用戶點(diǎn)擊一個(gè)鏈接，提交一個(gè)表單，或者被腳本重定向，，如果導(dǎo)航是跨站的話，Chromium不會(huì)試圖切換標(biāo)簽頁(yè)中的渲染器進(jìn)程。Chromium只會(huì)為始于瀏覽器的跨站導(dǎo)航交換進(jìn)程，比如在地址欄輸入一個(gè)URL或者打開(kāi)一個(gè)書(shū)簽。因此，不同網(wǎng)站的頁(yè)面可能會(huì)在同一個(gè)進(jìn)程中渲染，甚至是在單網(wǎng)站實(shí)例單進(jìn)程模型和單網(wǎng)站單進(jìn)程模型中。這很可能在將來(lái)的Chromium版本中，作為網(wǎng)站隔離工程的一部分進(jìn)行修改。
然而，網(wǎng)頁(yè)可以使用一種機(jī)制來(lái)讓一個(gè)鏈接指向一個(gè)不相關(guān)的頁(yè)面，這樣它們可以在不同的進(jìn)程中安全地渲染。如果一個(gè)link有rel=noreferrer或target=blank這樣的屬性，那么Chromium會(huì)在另外的進(jìn)程中渲染它。
子頁(yè)面現(xiàn)在是與父頁(yè)面在相同進(jìn)程中渲染的。雖然跨站點(diǎn)的子頁(yè)面沒(méi)有訪問(wèn)它們的父頁(yè)面的腳本，而且它們可以在不同的進(jìn)程中安全地渲染，但Chromium還沒(méi)有在獨(dú)立的進(jìn)程中渲染它們。與上面的第一個(gè)警告相似，這意味著不同站點(diǎn)的頁(yè)面會(huì)在同樣的進(jìn)程中渲染。這很可能在Chromium將來(lái)的版本中進(jìn)行修改。
Chromium創(chuàng)建的渲染進(jìn)程數(shù)目有上限。這避免瀏覽器占用用戶電腦的太多進(jìn)程。這個(gè)限制與計(jì)算機(jī)的內(nèi)存成比例，并且最多可以有80個(gè)進(jìn)程。因?yàn)檫@樣的限制，一個(gè)渲染器可能被分配給多個(gè)站點(diǎn)。這種重用現(xiàn)在是隨機(jī)進(jìn)行的，但將來(lái)的版本中，Chromium會(huì)做一個(gè)啟發(fā)式的策略，智能的把站點(diǎn)分配給渲染器進(jìn)程。
實(shí)現(xiàn)記錄
Chromium中有兩個(gè)類代表了不同的進(jìn)程模型實(shí)現(xiàn)的抽象需要：BrowsingInstance和SiteInstance。
BrowsingInstance類代表了一個(gè)瀏覽器中腳本相連的集合，在HTML5領(lǐng)域中也被稱為相關(guān)瀏覽上下文單元。在單標(biāo)簽頁(yè)單進(jìn)程模型中，我們?yōu)槊總€(gè)BrowsingInstance創(chuàng)建一個(gè)渲染器進(jìn)程。
SiteInstance類代表了來(lái)自相同站點(diǎn)的相同頁(yè)面。它是BrowsingInstance內(nèi)部頁(yè)面的一個(gè)子集，因?yàn)樵贐rowsingInstance內(nèi)部，每個(gè)站點(diǎn)只有一個(gè)SiteInstance，所以它很重要。在單網(wǎng)站實(shí)例單進(jìn)程模型中，我們?yōu)槊總€(gè)SiteInstance創(chuàng)建一個(gè)渲染器進(jìn)程。為了實(shí)現(xiàn)單網(wǎng)站單進(jìn)程，我們必須確保來(lái)自同一個(gè)站點(diǎn)的所有的SiteInstance歸入相同的進(jìn)程中。
學(xué)術(shù)論文
Charles Reis, Steven D. Gribble (both authors at UW + Google)
Eurosys 2009. Nuremberg, Germany, April 2009.
摘要
今天的許多網(wǎng)站包含大量客戶端代碼，因此，他們不再是簡(jiǎn)單的文檔，而更多地表現(xiàn)出程序的特征。這給瀏覽器提出了魯棒性與性能的挑戰(zhàn)。為了給用戶提供一個(gè)魯棒而又快速響應(yīng)的平臺(tái)，瀏覽器必須識(shí)別應(yīng)用程序邊界，在他們之間提供隔離。
我們?cè)谶@篇文章中提出三個(gè)點(diǎn)。第一，我們?yōu)閣eb程序和程序?qū)嵗峁┏橄螅⒄f(shuō)明這些抽象描繪了瀏覽器組件是如何交互的，合適的程序邊界該如何識(shí)別出來(lái)；第二，我們識(shí)別回退可用性的代價(jià)，因?yàn)檫@約束了在不干擾已有網(wǎng)站的情況下，將網(wǎng)頁(yè)內(nèi)容劃分為程序所能做到的程度；第三，我們展示了一個(gè)多進(jìn)程瀏覽器架構(gòu)，相互隔離這些web應(yīng)用程序，提高容錯(cuò)度，優(yōu)化資源管理和性能。我們會(huì)討論這個(gè)架構(gòu)在Google Chrome中是如何實(shí)現(xiàn)的，然后我們會(huì)提供一個(gè)量化的性能評(píng)估以檢查這種架構(gòu)的好處與代價(jià)。
Chromium瀏覽器安全架構(gòu)
Adam Barth, Collin Jackson, Charles Reis, and The Google Chrome Team
Stanford Technical Report, September 2008.
摘要
大多數(shù)當(dāng)前網(wǎng)頁(yè)瀏覽器使用一個(gè)單片架構(gòu)，將user和web合并到同一個(gè)保護(hù)域中。如果一個(gè)攻擊者在這樣的瀏覽器中利用了任意一個(gè)代碼執(zhí)行漏洞，他們都可以盜取敏感文件或者安裝惡意軟件。在這篇文章里，我們會(huì)展示Chromium（Google Chrome是在這個(gè)開(kāi)源軟件的基礎(chǔ)上構(gòu)建的）的安全架構(gòu)。Chromium有兩個(gè)處于不同保護(hù)域中的模塊：一個(gè)是瀏覽器內(nèi)核，與操作系統(tǒng)交流，一個(gè)是渲染引擎，在沙箱中運(yùn)行，有著有限的權(quán)限。這個(gè)架構(gòu)能夠減輕高危攻擊，而且不犧牲已有網(wǎng)站的可用性。我們?yōu)槊總€(gè)瀏覽器調(diào)用定義了一個(gè)威脅模型，并評(píng)估這個(gè)架構(gòu)能夠如何減少過(guò)去的漏洞。
