瀏覽器運行原理（二）

這是我參與8月更文挑戰的第5天，活動詳情查看：8月更文挑戰

輸入搜索內容的過程發生了什麼？

也許大多數人使用 Chrome 最多的場景就是在地址欄輸入關鍵字進行搜索或者輸入地址導航到某個網站，咱們來看看瀏覽器是怎麼看待這個過程的。

咱們知道瀏覽器 Tab 外的工做主要由 Browser Process 掌控，Browser Process（Browser進程） 又對這些工做進一步劃分，使用不一樣線程進行處理：

• UI thread (UI線程)： 控制瀏覽器上的按鈕及輸入框；
• network thread(netWork線程): 處理網絡請求，從網上獲取數據；
• storage thread(storage線程): 控制文件等的訪問；

回到咱們的問題，當咱們在瀏覽器地址欄中輸入文字，並點擊回車得到頁面內容的過程在瀏覽器看來能夠分爲如下幾步：

1. 處理輸入

UI thread 須要判斷用戶輸入的是 URL 仍是 query；

2. 開始導航

當用戶點擊回車鍵，UI thread 通知 network thread 獲取網頁內容，並控制 tab 上的 spinner 展示，表示正在加載中。

network thread 會執行 DNS 查詢，隨後爲請求創建 TLS 鏈接

若是 network thread 接收到了重定向請求頭如 301，network thread 會通知 UI thread 服務器要求重定向，以後，另一個 URL 請求會被觸發。

3. 讀取響應

當請求響應返回的時候，network thread 會依據 Content-Type 及 MIME Type sniffing 判斷響應內容的格式

判斷響應內容的格式

若是響應內容的格式是 HTML ，下一步將會把這些數據傳遞給 renderer process，若是是 zip 文件或者其它文件，會把相關數據傳輸給下載管理器。

Safe Browsing 檢查也會在此時觸發，若是域名或者請求內容匹配到已知的惡意站點，network thread 會展現一個警告頁。此外 CORB 檢測也會觸發確保敏感數據不會被傳遞給渲染進程。

4. 查找渲染進程

當上述全部檢查完成，network thread 確信瀏覽器能夠導航到請求網頁，network thread 會通知 UI thread 數據已經準備好，UI thread 會查找到一個 renderer process 進行網頁的渲染。

收到 Network thread 返回的數據後，UI thread 查找相關的渲染進程

因爲網絡請求獲取響應須要時間，這裏其實還存在着一個加速方案。當 UI thread 發送 URL 請求給 network thread 時，瀏覽器其實已經知道了將要導航到那個站點。UI thread 會並行的預先查找和啓動一個渲染進程，若是一切正常，當 network thread 接收到數據時，渲染進程已經準備就緒了，可是若是遇到重定向，準備好的渲染進程也許就不可用了，這時候就須要重啓一個新的渲染進程。

5. 確認導航

進過了上述過程，數據以及渲染進程均可用了， Browser Process 會給 renderer process 發送 IPC 消息來確認導航，一旦 Browser Process 收到 renderer process 的渲染確認消息，導航過程結束，頁面加載過程開始。

此時，地址欄會更新，展現出新頁面的網頁信息。history tab 會更新，可經過返回鍵返回導航來的頁面，爲了讓關閉 tab 或者窗口後便於恢復，這些信息會存放在硬盤中。

Browser Process 和 Renderer Process 經過 IPC 通訊，請求 Renderer Process 渲染頁面

6. 額外的步驟

一旦導航被確認，renderer process 會使用相關的資源渲染頁面，下文中咱們將重點介紹渲染流程。當 renderer process 渲染結束（渲染結束意味着該頁面內的全部的頁面，包括全部 iframe 都觸發了 onload 時），會發送 IPC 信號到 Browser process， UI thread 會中止展現 tab 中的 spinner。

Renderer Process 發送 IPC 消息通知 browser process 頁面已經加載完成

固然上面的流程只是網頁首幀渲染完成，在此以後，客戶端依舊可下載額外的資源渲染出新的視圖。

在這裏咱們能夠明確一點，全部的 JS 代碼其實都由 renderer Process 控制的，因此在你瀏覽網頁內容的過程大部分時候不會涉及到其它的進程。不過也許你也曾經監聽過 beforeunload 事件，這個事件再次涉及到 Browser Process 和 renderer Process 的交互，噹噹前頁面關閉時（關閉 Tab ，刷新等等），Browser Process 須要通知 renderer Process 進行相關的檢查，對相關事件進行處理。

瀏覽器進程發送 IPC 消息給渲染進程，通知要離開當前網站了

若是導航由 renderer process 觸發（好比在用戶點擊某連接，或者JS執行 window.location = "[http://newsite.com](https://link.zhihu.com/?target=http%3A//newsite.com/)" ） renderer process 會首先檢查是否有 beforeunload 事件處理器，導航請求由 renderer process 傳遞給 Browser process

若是導航到新的網站，會啓用一個新的 render process 來處理新頁面的渲染，老的進程會留下來處理相似 unload 等事件。

關於頁面的生命週期，更多內容可參考 Page Lifecycle API 。

瀏覽器進程發送 IPC 消息到新的渲染進程通知渲染新的頁面，同時通知舊的渲染進程卸載

除了上述流程，有些頁面還擁有 Service Worker （服務工做線程），Service Worker 讓開發者對本地緩存及判斷什麼時候從網絡上獲取信息有了更多的控制權，若是 Service Worker 被設置爲從本地 cache 中加載數據，那麼就沒有必要從網上獲取更多數據了。

值得注意的是 service worker 也是運行在渲染進程中的 JS 代碼，所以對於擁有 Service Worker 的頁面，上述流程有些許的不一樣。

當有 Service Worker 被註冊時，其做用域會被保存，當有導航時，network thread 會在註冊過的 Service Worker 的做用域中檢查相關域名，若是存在對應的 Service worker，UI thread 會找到一個 renderer process 來處理相關代碼，Service Worker 可能會從 cache 中加載數據，從而終止對網絡的請求，也可能從網上請求新的數據。

Service Worker 依據具體情形作處理

關於 Service Worker 的更多內容可參考 The Service Worker Lifecycle

若是 Service Worker 最終決定經過網上獲取數據，Browser 進程 和 renderer 進程的交互其實會延後數據的請求時間 。Navigation Preload 是一種與 Service Worker 並行的加速加載資源的機制，服務端經過請求頭能夠識別這類請求，而作出相應的處理。