我們每天都在使用瀏覽器，但是瀏覽器的內部是怎麼運作的呢？小白如我也不知道，直到看了這篇文章後才。。。
HIHI～😍 如果你是第一次來的話，『Chan-Chan-Dev』是一個專門用簡單的圖文與故事講解網路程式技術的網站。
若你也喜歡用這種方式學習的話，歡迎加入 Chan-Chan-Dev Facebook 的粉絲團，在發佈的時候就有比較多機會收到通知喔！😍
這篇的所有內容是來自於原文 《Inside look at modern web browser》 的第一篇。其實已經講的很淺顯易懂而且又有超級可愛的插圖，私心認爲已經很難有比它寫的更好的文章了 ，因此這篇文章更像是自己學習的筆記。
另外也因爲它是英文的版本，希望藉由自己的筆記分享可以在讓更多人學習到有幫助的資訊喔！😍
前情提要
在《Javascript 非同步 & Event Loop！10 分鐘輕鬆圖解學習！》有提到 Javascript 是單執行緒 的重點。之後也引發自己好奇究竟瀏覽器與 Javascript 的關係，進而才找到這篇很棒的文章。因此今天單純從瀏覽器的角度來看看 執行緒 (Thread) 與 行程 (Process) 吧。
行程 (Process) / 執行緒 (Thread)
在馬上跳入這麼硬的詞之前，讓我們來看個小圖解吧 😆
我們假想有一塊很大很大的空地。
既然地這麼大，就開始會有人圍出一個個的面積來蓋個工廠。
有了工廠之後，就開始需要請員工來協助執行工作，A 工廠比較有錢，可以請多個員工，而 B 工廠卻只請的起一個員工。
另外值得注意的是：工廠跟工廠之間因爲佔用不同的區域，所以是彼此獨立（隔離）的。這樣的話 A 工廠裏面的工作內容是不會被 B 工廠知道，反之也是如此喔。
讓我們將螢幕轉回棚內 😆
想像記憶體就是一大塊的空地，因此當一個應用程式被執行時，就會產生一個 行程 (Process)，也會被分配到記憶體的某一個區塊，就像是在空地上圍出一個面積用來蓋工廠。而執行緒 (Thread) 就像是員工般，會在 行程 (Process) 這個工廠內執行任務。
Inter Process Communication (IPC)
工廠之間也不可能完全沒有聯繫，他們總是會有需要溝通的時候。行程 (Process)也是如此，因此兩個 行程 (Process) 通訊的方式稱爲 Inter Process Communication (IPC)
瀏覽器架構
瀏覽器常見的有 Chrome、Firefox、IE、Safari … 等等等。本文介紹的主要以 Chrome 爲主喔！
有的只用一間工廠請好幾個員工（一個行程 (Process)，多個執行緒 (Thread) ），有的則是好幾間工廠，每間工廠只請一個員工（多個行程 (Process)，單個執行緒 (Thread) ），因此每一個實作的架構都不太一樣。
以下就統一用英文 Process 與 Thread 來介紹 😀
就不再使用中文的翻譯囉。
以瀏覽器來說會由好幾個不同的 Process一起合作，而 Browser Process 則是負責統合其他 Process)的角色。
其他的 Process 還有像是：
| Network Process | Storage Process | UI Process |
| GUP Process | Device Process | Renderer Process |
| Plugin Process | Extension Process |
Chrome 節省更多記憶體的優化方式
想像上述這些 Process 就是一個個的公司職位，當 Chrome （公司）發現它正運行在一臺很強大的裝置上（有很多資金）的時候，就會將每一個服務區分爲不同的 Process（公司職位），反之當它發現運行的裝置資源有限的時候，他就會合併一些 Process 在一起。
在這個時候，Browser Process 可能就會需要肩負 UI Process、Network Process、Storage Process 的角色囉（就是 CEO 自己要身兼多職啦 😭）
Process 粗略分工：
我們來看一下精簡狀態的時候，各個 Process 的分工：
Browser Process
用來控制部份的 Chrome 應用程式，例如包含 UI 界面上的 Address Bar、書籤、上一頁下一頁的按鈕。除此之外也須處理看不到的任務，例如網路請求與檔案存取等等的功能。
Renderer Process
在一個分頁內任何跟網頁顯示相關的任務都是 Renderer Process 負責喔！
Plugin Process
如其名，任何網站用到的外掛都是它負責的。
其他
當然還有其他的像是 Extension Process 或者 utility Process，如果想找到它們的話請參考下圖：
就可以看到每一個 Process 使用資源（例如：記憶體、CPU 等等）的量囉 😀
多個 Process 的好處
我們一樣繼續用多個職位在一間公司的角度來理解思考。
因爲有好幾個不同的職位負責不同的任務，因此若有某一個職位的人打電話都沒有反應，其他職位的任務不會因此受影響讓整間公司的運作整個停擺。
發生上述情況，老闆只需要再重新找一個同一個職位的人來負責即可。
Process 也是一樣的道理。若每一個分頁都各自有一個 Renderer Process 負責，所以任一其中的分頁發生問題時，也不會影響到其他分頁的運作，我們只需要開啓一個新的分頁繼續之前的那網頁即可喔 😀
Site Isolation
Site Isolation 是桌面版 Chrome 67 預設的功能。
它試圖在允許的情況下讓一個分頁內的每一個 iFrame 擁有自己的 Renderer Process。
為什麼需要這個功能呢？ 🤔
結論：安全性的考量。
讓我們先回到之前的場景，也就是一個分頁由有一個 Renderer Process 負責的情況。
我們剛剛聊過 Process 與 Process 之間像是一間間獨立的工廠，因此有對外隔絕的資源，因此外部無法存取到內部的記憶體等等的內容，達到保護的效果。
但是這個是在一個分頁只有一個網站的情境下。
使用 iframe 很多時候會在一個網站內去連接到其他的網站。舉例說：有一個 A.com 使用了 iframe 連接到 B.com 與 C.com 的網站。因此，就會形成了一個分頁裡有 3 個網站（A.com、B.com、C.com）的情況。
這樣在 A.com 網站的內容資料就有機會會被 B.com 或 C.com 存取到，因此就會有安全性的疑慮發生囉。
因此基於 Same-origin policy (同源政策) 的規範，必須要確保不會發生一個網站的資訊在非同意的情況下被另外一個網站存取到。於是 Process 的隔離就成爲將網站分離的最有效方式囉。因此才會在 Chrome 67 版的時候導入這項功能！
結論
在 《Inside look at modern web browser - Part1》 的文章中才知道我們每天在使用的瀏覽器原來是這麼多不同的 Process 相戶合作的結果。讓自己有點對於瀏覽器這個黑盒子有進一步的認識與瞭解。
之後有機會也會跟大家聊聊第二篇 《Inside look at modern web browser - Part2》。主要在講當一個網址敲入網址輸入框的時候會發生什麼事情呢？有興趣的大大們可以搶先收看原文喔！😀
最後感謝你願意看到這裏，希望這篇文章對你有所幫助。
若你想到身邊有需要這篇文章內容的朋友，也請你幫他一個忙把這篇文章分享給他 😍
若文章的內容有錯誤的地方，也歡迎隨時一起討論交流。😘
最後感謝你的閱讀囉，我們下次見！Bye ～ 🚀