iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 14
0
Modern Web

前端開發 30 個問題系列 第 14

How browser works (1) - A brief of Chrome architecture

  • 分享至 

  • twitterImage
  •  

前言
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 其實在這次鐵人賽的第一篇文章有出現過,就是那位歐洲核子研究中心 (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


TD
Be curious as astronomer, think as physicist, hack as engineer, fight as baseball player

More about me

"Life is like riding a bicycle. To keep your balance, you must keep moving."


上一篇
JavaScript async/await
下一篇
How browser works (2) - DNS
系列文
前端開發 30 個問題31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言