# [IM014] How a browser works (1) - A brief of Chrome architecture

> **前言**
> 2020 秋天，我將用 30 天的時間，來嘗試回答和網路前端開發相關的 30 個問題。30 天無法一網打盡浩瀚的前端知識，有些問題可能對有些讀者來說相對簡單，不過期待這趟旅程，能幫助自己、也幫助讀者打開不同的知識大門。有興趣的話，跟著我一起探索吧！


## The process of browsing a web page

在人人上網的時代，瀏覽器扮演了一個非常重要的角色，絕大部分的人都是透過瀏覽器，來和這個世界建立連結。我們只要在瀏覽器上輸入網址，或是打入關鍵字，瀏覽器就可以帶我們找到我們想要的資源。

如果要用非常簡單的方式說明這個過程，那麼就會是：

1. 輸入網址
2. 分析網址，找到對應的 IP 位址
3. 依循 TCP/IP 協議建立連線
4. 發送 HTTP 請求
5. 收到對方伺服器的回應與資源
6. 解析資源並開始渲染網頁

在接下來的幾天時間當中，我將慢慢的深入探索當中的細節。不過在這之前，先來看看瀏覽器的構造吧！

## What does a browser do?

從 Tim Berners-Lee 在 1990 年創造出瀏覽器至今約 30 年的時間，中間經歷網路技術的快速發展，與幾次的瀏覽器大戰，讓今天的瀏覽器成為功能強大且複雜的應用程式。

這裡先岔題一下，這位 Tim Berners-Lee 其實在這次鐵人賽的[第一篇文章](https://ithelp.ithome.com.tw/articles/10236447)有出現過，就是那位歐洲核子研究中心 (CERN) 的科學家，在 1980 年代推動 HTML 的誕生，後來在 1994 年建立 W3C (World Wide Web Consortium)。Tim 身為網際網路、第一代瀏覽器的創造者，並建立讓網路能夠快速擴張的基礎協定與演算法，其卓越貢獻讓他獲得 2016 年圖靈獎。

> *"for inventing the World Wide Web, the first web browser, and the fundamental protocols and algorithms allowing the Web to scale"*

回過頭來，當今的瀏覽器要處理的事情相當的多，譬如要管理
* 連線 (network)
* 畫面渲染 (UI, renderer)
* 儲存 (storage)
* 操作 CPU 和 GPU
* 第三方套件 (plugins)

以及管理整個瀏覽器運作流程的功能。如果以 Chrome 瀏覽器為例，主要由下面幾個 process 來運作：

1. Browser process
2. Renderer process
3. Plugin process
4. GPU process

## What are process and thread?

在 CS 的世界常常會看到 "process" 和 "thread" 兩個字，這裡簡單說明一下：

> 行程（英語：process），是指電腦中已執行的程式

Process 是實際被載入記憶體當中並執行的程式碼，也就是說，平常我們在寫的程式碼 "program" 都只是份文件，被電腦載入後就稱作是 "process"。不同的 process 之間是互相獨立運作，譬如 CPU, 記憶體的使用等等。

> 執行緒（英語：thread）是作業系統能夠進行運算排程的最小單位。大部分情況下，它被包含在行程之中，是行程中的實際運作單位。一條執行緒指的是行程中一個單一順序的控制流，一個行程中可以並行多個執行緒

一個 process 當中會包含多個 threads，這些 threads 會共享同一個 process 當中的 CPU 或記憶體資源。可以想想一個 process 就是一間大工廠，當中有許多工人 (threads) 會一起工作並完成任務。

通常一個 CPU 一次只能執行一個 process（當然多核 CPU 就可以同時處理多個 process），所以如果同時有多個 process 在跑，就需要 CPU 排程 (scheduling) ，同時也要進行記憶體的管理。

## Four main processes in Chrome

回到 Chrome 瀏覽器上，剛剛提到的 process 分別的任務如下：

**Browser process**
基本上負責所有使用者看得到的功能，像是網址輸入欄、上一頁下一頁、書籤 ......等。

**Renderer process**
負責畫面渲染。在 Chrome 當中，每一個分頁都有獨立的 render process 來負責該畫面的渲染。

**Plugin process**
負責 plugins 的管理

**GPU process**
負責管理需要 GPU 處理的任務，而這些任務可能來自不同的 render process。

不過先前提到，process 之間都是相互獨立的，因此若不同的 process 之間需要「溝通」，那麼就需要依靠 Inter Process Communication (IPC) 的機制，讓不同的 process 能夠合作完成任務。

## Why multi-process?

最後，來看看為什麼 Chrome 要採取這種多個 process 的架構。

在瀏覽器剛誕生的時候，其實是 single process 的架構，也就是說，用一個 process 來處理掉所有的任務。但隨著網路技術的發展，開始面臨到一些問題，像是

1. 隨著 HTML/CSS/JavaScript 的演進，要渲染頁面越來越複雜
2. 更多的使用者互動需求
3. 安全性問題

如果單用一個 process 來處理，會面臨到相當大的挑戰，如果其中一個頁面遇到了問題，譬如在渲染的時候卡關，或是遇到惡意攻擊，那麼整個瀏覽器就會 crash。另外，如果有太多的請求在爭取 single process 當中 CPU 資源，也會造成效率降低。

因此 Chrome 使用了 multi-process 的架構，讓一個頁面有獨立的 renderer process 來負責處理，來達到「隔離」的效果。不過相對來說，這也會耗用不少的資源。

## End

今天很快速地看過 Chrome 瀏覽器的架構，明天會踏上瀏覽網頁的第一步：從輸入網址開始談起。我們明天見囉！

## Ref
* [前端三十｜30. [WEB] 從輸入網址列到渲染畫面，過程經歷了什麼事情？](https://medium.com/schaoss-blog/%E5%89%8D%E7%AB%AF%E4%B8%89%E5%8D%81-30-web-%E5%BE%9E%E8%BC%B8%E5%85%A5%E7%B6%B2%E5%9D%80%E5%88%97%E5%88%B0%E6%B8%B2%E6%9F%93%E7%95%AB%E9%9D%A2-%E9%81%8E%E7%A8%8B%E7%B6%93%E6%AD%B7%E4%BA%86%E4%BB%80%E9%BA%BC%E4%BA%8B%E6%83%85-49341bcf6aff)
* [Inside look at modern web browser](https://developers.google.com/web/updates/2018/09/inside-browser-part1)
* [Multi-process Architecture](https://blog.chromium.org/2008/09/multi-process-architecture.html)

***
> **TD**
> Be curious as astronomer, think as physicist, hack as engineer, fight as baseball player
>
> [More about me](https://tsungtingdu.github.io/profile/)
>
> *"Life is like riding a bicycle. To keep your balance, you must keep moving."*

***

###### tags: `ironman` `javascript`