深入剖析從輸入URL到頁面顯示過程原理

前言

說說從輸入 URL 到頁面顯示的過程,這是一個在面試中經常會被問到的問題,此問題能比較全面地考察應聘者知識的掌握程度。其中涉及到瞭網絡、操作系統、Web 等一系列的知識。

以 Chrome 瀏覽器為例,目前的 Chrome 瀏覽器有以下幾個進程:

瀏覽器進程。主要負責界面顯示、用戶交互、子進程管理,同時提供存儲等功能。

渲染進程。主要職責是把從網絡下載的 HTML、JavaScript、CSS、圖片等資源解析為可以顯示和交互的頁面。

GPU 進程。其實,Chrome 剛開始發佈的時候是沒有 GPU 進程的。而 GPU 的使用初衷是為瞭實現 3D CSS 的效果,隻是隨後網頁、Chrome 的 UI 界面都選擇采用 GPU 來繪制,這使得 GPU 成為瀏覽器普遍的需求。

網絡進程。主要負責頁面的網絡資源加載,之前是作為一個模塊運行在瀏覽器進程裡面的,後面才獨立出來,成為一個單獨的進程。

插件進程。主要是負責插件的運行,因插件易崩潰,所以需要通過插件進程來隔離,以保證插件進程崩潰不會對瀏覽器和頁面造成影響。

在瞭解瞭瀏覽器有哪些進程,以及它們各自的職責之後,結合這些進程,我們再來分析從輸入 URL 到頁面顯示的過程。

1. 用戶輸入

如果輸入的是內容,地址欄會使用瀏覽器默認的搜索引擎,來合成新的帶搜索關鍵字的 URL。

如果輸入的是 URL,那麼地址欄會根據規則,把這段內容加上協議,合成為完整的 URL。

2. URL 請求過程

瀏覽器進程會通過進程間通信(IPC)把 URL 請求發送至網絡進程,網絡進程接收到 URL 請求後,會在這裡發起真正的 URL 請求流程。那具體流程是怎樣的呢?

網絡進程會查找本地緩存是否緩存瞭該資源。如果有緩存資源,那麼直接返回資源給瀏覽器進程;如果在緩存中沒有查找到資源,那麼直接進入網絡請求流程。這請求前的第一步是要進行 DNS 解析,以獲取請求域名的服務器 IP 地址。如果請求協議是 HTTPS,那麼還需要建立 TLS 連接。

接下來就是利用 IP 地址和服務器建立 TCP 連接 (三次握手)。連接建立之後,瀏覽器端會構建請求行、請求頭等信息,並把和該域名相關的 cookie 等數據附加到請求頭中,然後向服務器發送構建的請求信息。

服務器接收到請求信息後,會根據請求信息生成響應數據(包括響應行、響應頭和響應體等信息),並發給網絡進程。等網絡進程接收瞭響應行和響應頭之後,就開始解析響應頭的內容瞭。

Content-Type 是 HTTP 頭中一個非常重要的字段, 它告訴瀏覽器服務器返回的響應體數據是什麼類型,然後瀏覽器會根據 Content-Type 的值來決定如何顯示響應體的內容。

如果 Content-Type 字段的值被瀏覽器判斷為下載類型,那麼該請求會被提交給瀏覽器的下載管理器,同時該 URL 請求的導航流程就此結束。但如果是 HTML,那麼瀏覽器則會繼續進行導航流程。

3. 準備渲染進程

如果協議根域名相同,則屬於同一站點。

但如果從一個頁面打開瞭另一個新頁面,而新頁面和當前頁面屬於同一站點的話,那麼新頁面會復用父頁面的渲染進程。

渲染進程準備好之後,還不能立即進入文檔解析狀態,因為此時的文檔數據還在網絡進程中,並沒有提交給渲染進程,所以下一步就進入瞭提交文檔階段。

4. 提交文檔

所謂提交文檔,就是指瀏覽器進程網絡進程接收到的 HTML 數據提交給渲染進程,具體流程是這樣的:

首先當瀏覽器進程接收到網絡進程的響應頭數據之後,便向渲染進程發起“提交文檔”的消息。

渲染進程接收到“提交文檔”的消息後,會和網絡進程建立傳輸數據的“管道”。

等文檔數據傳輸完成之後,渲染進程會返回“確認提交”的消息給瀏覽器進程。

瀏覽器進程在收到“確認提交”的消息後,會更新瀏覽器界面狀態,包括瞭安全狀態、地址欄的 URL、前進後退的歷史狀態,並更新 Web 頁面。

5. 渲染階段

一旦文檔被提交,渲染進程便開始頁面解析和子資源加載。

渲染進程將 HTML 內容轉換為能夠讀懂的 DOM 樹結構。

渲染引擎將 CSS 樣式表轉化為瀏覽器可以理解的 styleSheets,計算出 DOM 節點的樣式。

創建佈局樹,並計算元素的佈局信息。

對佈局樹進行分層,並生成分層樹

為每個圖層生成繪制列表,並將其提交到合成線程。

合成線程將圖層分成圖塊,並在光柵化線程池中將圖塊轉換成位圖

合成線程發送繪制圖塊命令 DrawQuad 給瀏覽器進程。

瀏覽器進程根據 DrawQuad 消息生成頁面,並顯示到顯示器上。

最後

以上就是筆者對這一常考面試題的一些總結,對於其中的一些具體過程並沒有詳細地列舉出來,更多關於輸入URL到頁面顯示過程的資料請關註WalkonNet其它相關文章!

推薦閱讀: