問題-概況篇

2-問題-概況篇

回溯

首先回顧一下咱們的問題：

「在瀏覽器地址欄中輸入 url 到頁面展示的短短几秒內瀏覽器究竟作了什麼？」

咱們根據前文的兩篇文章，能夠知道整個瀏覽器中的主進程是Browser Process，而進程中會有不一樣的線程，因此該進程將不一樣的任務交給不一樣的線程處理：

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

解決問題

回到問題自己，這樣的操做在瀏覽器看來能夠分爲如下幾步：

1. 處理輸入

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

2. 開始導航

當用戶點擊回車，UI thread 通知 Network thread 獲取網頁內容，同時控制 tab 上的 spinner 展現（逆時針），表示正在請求頁面。

Network thread 會按照順序查詢 DNS，隨後爲請求簡歷 TLS （傳輸層安全性協定：Transport Layer Security）鏈接。

若是 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 檢測也會觸發確保敏感數據不會被傳遞 Renderer process。

4. 查看渲染進程

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

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

5. 確認導航

完成了上述過程，數據和渲染進行都是準備狀態，Browser Process 會給 Renderer Process 發送 IPC 消息來確認導航，一旦 Browser Process 收到 renderer process 的渲染確認消息，導航過程結束，頁面加載過程開始（ UI thread 通知 tab 的 spinner 展現（順時針））。

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

6. 額外的步驟

導航被確認，Renderer Processs 會使用相關的資源將頁面渲染出來。當 Renderer Process 渲染結束（即觸發因此頁面的onload事件），會發送 IPC 消息到 Browser Process，而後 UI thread 中止展現 tab 中的 spinner。

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

以上就是瀏覽器對應咱們問題的處理步驟了，是否是從以往回答更多側重如何查詢 DNS 的維度看到了本身的不足哩。

其實系列文章能夠在這裏結束咯，可總感受仍是將知識僅僅涉及表層（固然面試管夠啦~）。因此問了本身一個問題：

Renderer Process 是如何將文檔渲染出來的呢？

隨便說一下：讓咱們前端工程師曾經頭疼的不就是瀏覽器內核嗎? （畢竟我作的第一個網站就是用 window XP系統運行的）而瀏覽器內核就是 Renderer Process！

注：部分圖片引自參考文獻

下一篇文章

瀏覽器內核-流程概況