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