一文摸透從輸入URL到頁面渲染的過程

一文摸透從輸入URL到頁面渲染的過程

從輸入URL到頁面渲染需要Chrome瀏覽器的多個進程配合，所以我們先來談談現階段Chrome瀏覽器的多進程架構。

一、Chrome架構

目前Chrome採用的是多進程的架構模式，可分為主要的五類進程，分別是：瀏覽器（Browser）主進程、 GPU 進程、網路（NetWork）進程、多個渲染進程和多個插件進程；

  • 瀏覽器進程。主要負責介面顯示、用戶交互、子進程管理，同時提供存儲等功能。
  • 渲染進程。核心任務是將 HTML、CSS 和 JavaScript 轉換為用戶可以與之交互的網頁，排版引擎Blink和JavaScript引擎V8都是運行在該進程中，默認情況下，Chrome會為每個Tab標籤創建一個渲染進程。出於安全考慮，渲染進程都是運行在沙箱模式下。
  • GPU進程。其實，Chrome剛開始發布的時候是沒有GPU進程的。而GPU的使用初衷是為了實現3D CSS的效果，只是隨後網頁、Chrome的UI介面都選擇採用GPU來繪製，這使得GPU成為瀏覽器普遍的需求。最後，Chrome在其多進程架構上也引入了GPU進程。
  • 網路進程。主要負責頁面的網路資源載入，之前是作為一個模組運行在瀏覽器進程裡面的，直至最近才獨立出來，成為一個單獨的進程。
  • 插件進程。主要是負責插件的運行，因插件易崩潰，所以需要通過插件進程來隔離，以保證插件進程崩潰不會對瀏覽器和頁面造成影響

了解了Chrome的多進程架構，就能夠從宏觀上理解從輸入URL到頁面渲染的過程了，這個過程主要分為導航階段和渲染階段。

二、導航階段

Ⅰ.瀏覽器主進程

1.用戶輸入URL

  • 1、瀏覽器進程檢查url，組裝協議，構成完整的url，這時候有兩種情況：
    • 輸入的是搜索內容：地址欄會使用瀏覽器默認的搜索引擎，來合成新的帶搜索關鍵字的URL。
    • 輸入的是請求URL：地址欄會根據規則，給這段內容加上協議，合成為完整的URL；
  • 2、瀏覽器進程通過進程間通訊（IPC）把url請求發送給網路進程；

Ⅱ.網路進程

2.URL請求過程

  • 3、網路進程接收到url請求後檢查本地快取是否快取了該請求資源，如果有則將該資源返回給瀏覽器進程；

這裡涉及到瀏覽器的快取策略問題，有興趣的可以上網查閱相關資料。

  • 4、準備IP地址和埠：進行DNS解析時先查找快取，沒有再使用DNS伺服器解析，查找順序為：

    • 瀏覽器快取；
    • 本機快取；
    • hosts文件；
    • 路由器快取；
    • ISP DNS快取；
    • DNS遞歸查詢（本地DNS伺服器 -> 許可權DNS伺服器 -> 頂級DNS伺服器 -> 13台根DNS伺服器）

  • 5、等待TCP隊列：瀏覽器會為每個域名最多維護6個TCP連接，如果發起一個HTTP請求時，這 6個 TCP連接都處於忙碌狀態，那麼這個請求就會處於排隊狀態；解決方案：

    • 採用域名分片技術：將一個站點的資源放在多個（CDN）域名下面。
    • 升級為HTTP2，就沒有6個TCP連接的限制了；

  • 6、通過三次握手建立TCP連接：

    123

    • 第一次：客戶端先向伺服器端發送一個同步數據包，報文的TCP首部中：標誌位：同步SYN為1，表示這是一個請求建立連接的數據包；序號Seq=x，x為所傳送數據的第一個位元組的序號，隨後進入SYN-SENT狀態；

    標誌位值為1表示該標誌位有效。

    • 第二次：伺服器根據收到數據包的SYN標誌位判斷為建立連接的請求，隨後返回一個確認數據包，其中標誌位SYN=1，ACK=1，序號seq=y，確認號ack=x + 1表示收到了客戶端傳輸過來的x位元組數據，並希望下次從x+1個位元組開始傳，並進入SYN-RCVD狀態；

    這裡要區分標誌位ACK和確認號ack；

    • 第三次：客戶端收到後，再給伺服器發送一個確認數據包，標誌位ACK=1，序號seq=x+1，確認號ack=y+1，隨後進入ESTABLISHED狀態；

    伺服器端收到後，也進入ESTABLISHED狀態，由此成功建立了TCP連接，可以開始數據傳送；

    • 為什麼要第三次揮手？避免伺服器等待造成資源浪費，具體原因：

    如果沒有最後一個數據包確認（第三次握手），A先發出一個建立連接的請求數據包，由於網路原因繞遠路了。A經過設定的超時時間後還未收到B的確認數據包。

    於是發出第二個建立連接的請求數據包，這次網路通暢，B的確認數據包也很快就到達A。於是A與B開始傳輸數據；

    過了一會A第一次發出的建立連接的請求數據包到達了B，B以為是再次建立連接，所以又發出一個確認數據包。由於A已經收到了一個確認數據包，所以會忽略B發來的第二個確認數據包，但是B發出確認數據包之後就要一直等待A的回復，而A永遠也不會回復。

    由此造成伺服器資源浪費，這種情況多了B電腦可能就停止響應了。

  • 7、構建並發送HTTP請求資訊；

  • 8、伺服器端處理請求；

  • 9、客戶端處理響應，首先檢查伺服器響應報文的狀態碼：

    • 如果是301/302表示伺服器已更換域名需要重定向，這時網路進程會從響應頭的Location欄位裡面讀取重定向的地址，然後再發起新的HTTP或者HTTPS請求，跳回第4步。
    • 如果是200，就檢查Content-Type欄位，值為text/html說明是HTML文檔，是application/octet-stream說明是文件下載；

  • 10、請求結束，當通用首部欄位Conection不是Keep-Alive時，即不為TCP長連接時，通過四次揮手斷開TCP連接：

  • 第一次：客戶端（主動斷開連接）發送數據包給伺服器，其中標誌位FIN=1，序號位seq=u，並停止發送數據；
  • 第二次：伺服器收到數據包後，由於還需傳輸數據，無法立即關閉連接，先返回一個標誌位ACK=1，序號seq=v，確認號ack=u+1的數據包；
  • 第三次：伺服器準備好斷開連接後，返回一個數據包，其中標誌位FIN=1，標誌位ACK=1，序號seq=w，確認號ack=u+1；
  • 第四次：客戶端收到數據包後，返回一個標誌位ACK=1，序號seq=u+1，確認號ack=w+1的數據包。

由此通過四次揮手斷開TCP連接。

詳細過程參見：詳解TCP連接的「三次握手」與「四次揮手」(上)

  • 為什麼要四次揮手？由於伺服器不能馬上斷開連接，導致FIN釋放連接報文與ACK確認接收報文需要分兩次傳輸，即第二次和第三次"揮手"；

3.準備渲染進程

  • 11、準備渲染進程：瀏覽器進程檢查當前url是否與之前打開了渲染進程的頁面的根域名相同，如果相同，則復用原來的進程，如果不同，則開啟新的渲染進程；

4.提交文檔

  • 12、提交文檔：
    • 渲染進程準備好後，瀏覽器向渲染進程發起「提交文檔」的消息，渲染進程接收到消息後與網路進程建立傳輸數據的「管道」
    • 渲染進程接收完數據後，向瀏覽器發送「確認提交」
    • 瀏覽器進程接收到確認消息後更新瀏覽器介面狀態：安全狀態、地址欄url、前進後退的歷史狀態、更新web頁面

三、渲染階段

在渲染階段通過渲染流水線在渲染進程的主執行緒和合成執行緒配合下，完成頁面的渲染；

Ⅲ.渲染進程

渲染進程中的主執行緒部分

5.構建DOM樹

  • 13、先將請求回來的數據解壓，隨後HTML解析器將其中的HTML位元組流通過分詞器拆分為一個個Token，然後生成節點Node，最後解析成瀏覽器識別的DOM樹結構。

    可以通過Chrome調試工具的Console選項打開控制台輸入document查看DOM樹；

渲染引擎還有一個安全檢查模組叫 XSSAuditor，是用來檢測詞法安全的。在分詞器解析出來 Token 之後，它會檢測這些模組是否安全，比如是否引用了外部腳本，是否符合 CSP 規範，是否存在跨站點請求等。如果出現不符合規範的內容，XSSAuditor 會對該腳本或者下載任務進行攔截。

首次解析HTML時渲染進程會開啟一個預解析執行緒，遇到HTML文檔中內嵌的JavaScript和CSS外部引用就會同步提前下載這些文件，下載時間以最後下載完的文件為準。

6.構建CSSOM

  • 14、CSS解析器將CSS轉換為瀏覽器能識別的styleSheets也就是CSSOM：可以通過控制台輸入document.styleSheets查看；

    這裡要考慮一下阻塞的問題，由於JavaScript有修改CSS和HTML的能力，所以，需要先等到 CSS 文件下載完成並生成 CSSOM，然後再執行 JavaScript 腳本，最後再繼續構建 DOM。由於這種阻塞，導致了解析白屏；

優化方案：

  • 移除js和css的文件下載：通過內聯 JavaScript、內聯 CSS；
  • 盡量減少文件大小：如通過 webpack 等工具移除不必要的注釋，並壓縮 js 文件；
  • 將不進行DOM操作或CSS樣式修改的 JavaScript 標記上 sync 或者 defer非同步引入；
  • 使用媒體查詢屬性：將大的CSS文件拆分成多個不同用途的 CSS 文件，只有在特定的場景下才會載入特定的 CSS 文件。

可以通過瀏覽器調試工具的Network面板中的DOMContentLoaded查看最後生成DOM樹所需的時間；

image-20200405110720560

7.樣式計算

  • 15、轉換樣式表中的屬性值，使其標準化。比如將em轉換為px，color轉換為rgb；
  • 16、計算DOM樹中每個節點的具體樣式，這裡遵循CSS的繼承和層疊規則；可以通過Chrome調試工具的Elements選項的Computed查看某一標籤的最終樣式；

image-20200405110849074

8.布局階段

  • 17、創建布局樹，遍歷DOM樹中的所有節點，去掉所有隱藏的節點（比如head，添加了display:none的節點），只在布局樹中保留可見的節點。

  • 18、計算布局樹中節點的坐標位置（較複雜，這裡不展開）；

9.分層

  • 19、對布局樹進行分層，並生成分層樹（Layer Tree），可以通過Chrome調試工具的Layer選項查看。分層樹中每一個節點都直接或間接的屬於一個圖層（如果一個節點沒有對應的層，那麼這個節點就從屬於父節點的圖層）

image-20200405111350260

10.圖層繪製

  • 20、為每個圖層生成繪製列表（即繪製指令），並將其提交到合成執行緒。以上操作都是在渲染進程中的主執行緒中進行的，提交到合成執行緒後就不阻塞主執行緒了；

渲染進程中的合成執行緒部分

11.切分圖塊

21、合成執行緒將圖層切分成大小固定的圖塊（256x256或者512x512）然後優先繪製靠近視口的圖塊，這樣就可以大大加速頁面的顯示速度；

Ⅳ.GPU進程

12.柵格化操作

  • 22、在光柵化執行緒池中將圖塊轉換成點陣圖，通常這個過程都會使用GPU來加速生成，使用GPU生成點陣圖的過程叫快速柵格化，或者GPU柵格化，生成的點陣圖被保存在GPU記憶體中。

Ⅴ.瀏覽器主進程

13.合成與顯示

  • 23、合成：一旦所有圖塊都被光柵化，合成執行緒就會將它們合成為一張圖片，並生成一個繪製圖塊的命令——「DrawQuad」，然後將該命令提交給瀏覽器進程。

注意了：合成的過程是在渲染進程的合成執行緒中完成的，不會影響到渲染進程的主執行緒執行；

  • 24、顯示：瀏覽器進程裡面有一個叫viz的組件，用來接收合成執行緒發過來的DrawQuad命令，然後根據DrawQuad命令，將其頁面內容繪製到記憶體中，最後再將記憶體顯示在螢幕上。

到這裡，經過這一系列的階段，編寫好的HTML、CSS、JavaScript等文件，經過瀏覽器就會顯示出漂亮的頁面了。

參考資料：瀏覽器工作原理與實踐

VirMach 便宜 VPS

QNews

QNews