瀏覽器 Multi-process 架構
上一篇先走過一次完整的 Navigation，這篇會先停在瀏覽器內部，看看工作到底由誰負責。
我們會從 Single-process 架構的限制開始，接著看 Chromium 為什麼要把 Browser、Renderer、GPU 與 Network 等工作拆開，以及 Multi-process 隨之帶來的成本。那就接著往下看吧！
瀏覽器 Single-process 架構
在 Single-process 架構下，瀏覽器的各項工作雖然仍可能分布在多條執行緒，但都共用同一個 process，因此主要會有不穩定、不流暢與不安全三個問題。
不穩定性
所有功能和頁面都共用同一個 process，只要其中一個頁面造成 process 崩潰，就可能連帶讓整個瀏覽器掛掉。
早期的 plugin 也可能在瀏覽器 process 內執行，而 plugin 本身又容易發生問題；只要 plugin 一死，整個瀏覽器就可能跟著掛掉！這也增加了不少不穩定性。
不流暢性
至於不流暢性，如果其中一個 Tab 執行速度很慢或進入無窮迴圈，和它共用 process 的其他頁面也可能受到影響，使用者看起來就像整個瀏覽器都卡住了。
記憶體管理也比較棘手：關掉頁面時，process 仍會繼續執行，無法像終止獨立 process 一樣，由作業系統一次回收該 process 的資源。如果還伴隨 memory leak，瀏覽器就可能越用越卡。
安全性
再來是安全性，因為 Single-process 架構缺少不同內容之間的作業系統層級隔離。一般 JavaScript 仍然會受到瀏覽器安全模型限制，不能任意讀寫本機資料；但如果渲染引擎或早期 plugin 有漏洞，攻擊程式就可能利用整個瀏覽器 process 原有的權限，增加使用者資料被讀取或竊取的風險。
瀏覽器 Multi-process 架構
它跟前面的 Single-process 架構不同，會把 Browser Process、Renderer Process、GPU Process 與 Network Service 等工作拆到不同 process；早期架構也會將 plugin 放進獨立的 Plugin Process。當某個 Renderer Process 掛掉時，通常只會影響由該 process 負責的頁面或 frame，不至於直接讓整個瀏覽器一起掛掉。
不過，拆分 process 之後，不同 Process 之間就需要透過 IPC 進行溝通。雖然多了通訊成本，卻也改善了前面提到的三個問題！
不穩定性： 在 Renderer Process 彼此隔離的情況下，單一頁面陣亡後，通常不會影響其他 process 中的頁面；把受影響的頁面關掉或重新載入，其他頁面仍可正常運作。
不流暢性： 當單一頁面發生延遲時，不同 Renderer Process 中的頁面通常還是能正常瀏覽。關閉頁面並終止專屬的 Renderer Process 後，作業系統也能一併回收它的記憶體；不過，如果多個頁面共用同一個 process，就無法單靠關閉其中一頁達到相同效果。
不安全性： Renderer Process 會在低權限的 sandbox 中執行，直接存取任意檔案或敏感資源會受到限制；需要額外能力時，必須透過受控的 IPC 請求權限較高的 Browser Process 處理。這樣即使網頁利用了 Renderer Process 的漏洞，也能降低它直接接觸本機資料的風險。
這裡可以先用「每個 Tab 各自有 Renderer Process」來理解，但實際上並不是一個 Tab 固定對應一個 Renderer Process。Chromium 會依網站、跨站 iframe、裝置資源與 process 數量上限來安排；同一個 Tab 可能使用多個 Renderer Process，多個頁面也可能共用同一個 process。
常見 Process 分工
為了方便建立整體概念，可以先把幾個常見角色整理成下面這樣：
- Browser Process：管理瀏覽器 UI、Tab、Navigation、權限與其他 process 的協調工作。
- Renderer Process：處理網頁內容，包括 HTML parsing、JavaScript、style、Layout 與 Paint；通常會受到 sandbox 限制。
- GPU Process：集中處理 GPU 相關工作，支援 Rasterization、Compositing 與 WebGL 等功能。
- Network Service：處理 DNS、連線、HTTP request、cache 與其他網路工作；在目前 Chromium 架構中通常會以獨立 utility process 執行，但瀏覽器仍可能依啟動參數或環境採用不同配置。
- Extension 相關 process：Chrome Extension 的背景頁面、service worker 或 extension page 可能由 Renderer Process 執行，不能直接把現代 Extension 全部視為早期的 Plugin Process。
前面的 Multi-process 架構圖來自較早期的 Chrome 架構說明，適合用來理解「不同功能拆到不同 process」的概念；其中 Plugin Process 與部分 process 名稱不代表目前 Chromium 的完整配置。
拆出更多 Process
雖然把工作拆到更多 Process，有機會透過平行處理提升反應速度與隔離性，但不是拆得越多就一定越快，因為過多的 Process 會帶來以下兩個缺點：
- 每個 Process 都有獨立的記憶體空間，也可能各自保留一份共用基礎元件，因此會占用更多記憶體。
- 系統架構會變得更複雜。前面提過，不同 Process 之間需要透過 IPC 溝通，拆得越細，通訊、排程與維護成本就會越高！
所以還是要權衡拆出 Process 帶來的優勢，是否比前面兩個缺點更有價值。如果沒有的話，就不一定需要拆成獨立 process。
總結
瀏覽器從 Single-process 逐漸走向 Multi-process，主要是為了解決穩定性、流暢性與安全性這三個問題。透過把 Renderer Process 等工作拆分出去，單一頁面發生錯誤時，通常不會直接拖垮整個瀏覽器；再搭配 sandbox 與 Site Isolation，也能降低網頁程式直接存取本機資料或其他網站資料的風險。
不過，Process 並不是拆得越多越好。不同 Process 之間需要透過 IPC 溝通，拆分得越細，雖然能增加隔離與平行處理的能力，卻也會帶來更多記憶體使用量、溝通成本與架構複雜度。因此瀏覽器需要在隔離性、效能、記憶體使用量與架構複雜度之間取得平衡，依照不同工作內容安排適合的 Process。
了解分工後，接下來就能回到 Navigation 的網路階段。當 Network Service 準備連線時，如果 URL 使用網域名稱，第一步通常是先完成 DNS resolution，取得後續連線需要的 IP 位址。