12.12 動畫：一個瀏覽器是如何工作的？

對於面試的大部分前端開發者來說，對瀏覽器的瞭解也算是一知半解，因為我們一開始前端覺得，我們開發中通常使用瀏覽器來顯示和調試頁面用的，不會涉入到太過的相關瀏覽器工作原理知識。

這你就大錯特錯了，雖然瀏覽器默默的為我們工作，但是有關瀏覽器的工作原理不但在你就業前端面試中屬於重中之重，也是在前端優化中佔有很大比重。作為一個前端開發如果不瞭解瀏覽器的工作原理，只能永遠停留在前端“切圖仔”水平。

學習瀏覽器工作原理是為了能夠運用到實際項目中，比如前端的性能優化以及錯誤排查，都會涉及到瀏覽器相關的知識，所以掌握瀏覽器的工作原理是必不可缺的，相信你學完之後，能夠對你的個人能力和見識會有很大的提升。

瀏覽器涉及到的知識點非常多而且非常重要，文章中可能其中有不足和錯誤的地方，也歡迎各位指出！

思維導圖

1 瀏覽器的職責

我們由淺入深的去了解瀏覽器的工作原理。首先學習一個事物要知道它是什麼，它要完成一個什麼樣的事情，也就是擁有什麼樣的職責。

對於瀏覽器來說，表面上看來，我們輸入了 URL，然後等待幾秒瀏覽器就展現出我們想要訪問的網址內容了。對沒錯，這就是瀏覽器的職責所在。這只是停留在了表面，要想深入知道瀏覽器在這個階段發生了什麼？需要我們進一步探索瀏覽器的工作原理。

所以說，無論是面試還是實際工作中，瀏覽器無時不刻和我們打交道。那我們就要從在瀏覽器輸入 URL 開始說起，直到瀏覽器最後展現出網站內容，這個過程瀏覽器做了哪些工作，又是如何工作的呢？

我們會詳細分為以下幾大模塊進行系統的講解：

1、DNS 解析

2、TCP 連接

3、HTTP

4、構建 DOM 樹

5、構建 CSSOM 樹

6、生成渲染樹

7、合成、繪製

其中有些部分我們之前的文章已經分享過，所以也不過到陳述，到時候會鞏固一下，重點我們放在瀏覽器的渲染原理上，這也是我們以後在學習前端優化中的重點。

2 DNS 解析

在之前的文章 TCP 三次握手中提到，要想得到接收方的 MAC 地址，需要通過對方的 IP 地址獲取，對方的 IP 需要通過 DNS 解析。

2.1

為什麼進行 DNS 解析？

所謂的 DNS 解析就是將我們輸入在網頁地址欄的 URL 通過 DNS 解析成 IP 地址。DNS 就是將域名轉化成 ip 地址的過程。那麼這個過程會發生什麼呢？和小鹿一起深入探究一下。

2.2

系統緩存查詢

首先瀏覽器會調用一個庫函數，檢測本地的 hosts 文件（可以認為是電腦本地的一個地址映射文件），從該文件中查看是否有對應的該域名的 IP 地址，這個過程是在系統緩存中查找是否存在該域名對應的 IP 地址。

比如在瀏覽器的地址欄中輸入小鹿的博客網址（www.xiaolu.com），然後回車，此時瀏覽器拿著這個域名去本地電腦的一個名為 hosts 文件中查詢是否存在該域名所對應的 IP 地址，如果有，就返回給瀏覽器，如果沒有，我們繼續往下進行。

2.3

路由器緩存、ISP 緩存

如果系統緩存沒有，就會向 DNS 服務器發送請求，而網絡服務一般都會先經過路由器以及網絡服務商（電信），所以會先查詢路由器緩存，然後再查詢 ISP 的 DNS 緩存。

2.4

DNS 遞歸查詢

如果路由器緩存和 ISP 的 DNS 緩存還是沒有的話，我們就進行 DNS 遞歸查詢。從根域名服務器開始查詢，然後再到頂級域名服務器，最後到主域名服務器依次查詢。

但是這裡有兩種查詢方式，不僅僅有遞歸查詢一種方式，還有一個查詢方式是迭代查詢，兩種查詢方式的區別是什麼呢？

我們前端會在性能優化的使用用到 DNS 的相關知識，我們在這稍微提一下，如何進行 DNS 優化呢？

DNS 查詢經歷很多步驟，查詢很慢。瀏覽器獲取到 IP 地址後，一般都會加到瀏覽器的緩存中，本地的 DNS 緩存服務器，也可以去記錄。

另外使用 DNS 負載均衡，通常我們的網站應用各種雲服務，DNS 系統根據每臺機器的負載量，地理位置的限制等等，去提供高效快速的 DNS 解析服務。

3 TCP 連接

我們通過 DNS 查詢到 IP 地址之後，我們就開始打算與服務器建立連接，為接下來的數據傳輸做準備，這部分在之前的文章中寫的非常詳細，一定要去看哦。

面試官最愛問你的，網絡分層中每一層有哪些內容

動畫：用動畫給面試官解釋 TCP 三次握手過程

4 HTTP 請求

我們客戶端與服務端通過 TCP 的三次握手建立連接之後，客戶端

服務端接收到客戶端發送的信息，就返回響應信息和文件。客戶端如何判斷服務端是否成功返回了呢？就需要下列的一些狀態碼來識別，同樣前端做的工作也是通過狀態碼來判斷當前響應狀態。

• 1XX（信息性狀態碼） : 服務器正在處理請求中。

• 2XX （成功狀態碼）: 請求處理完畢。

• 3XX （重定向狀態碼）: 需要附加操作以完成請求。

• 301：永久性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，以後使用該資源，使用現在所指 URI。

• 302：臨時性重定向。表示該狀態碼被分配了新的 URI，希望用戶本次能夠使用新的 URI 訪問。

• 304：服務器資源未改變，可直接使用客戶端未過期的緩存。

• 4XX （客戶端錯誤狀態碼）: 服務器無法處理請求。

• 400：該請求報文中有語法錯誤。

• 403：沒有資源的訪問權限。

• 404：找不到資源。

• 5XX （服務端錯誤狀態碼）: 服務器處理請求出錯。

• 500：服務器發生錯誤

• 503：服務器超荷載或正在維護。

遠程服務器找到資源並使用 HTTP 響應返回該資源，值為 200 的 HTTP 響應狀態表示一個正確的響應。

5 瀏覽器的渲染原理

5.1

構建 DOM

服務器將 HTML、CSS、JS文件轉化為 0,1字節數據在網絡中傳輸給瀏覽器，瀏覽器通過判斷狀態碼開始接收、解析文件，這開始運用到瀏覽器的渲染原理。

首先瀏覽器要做的就是獲取 HTTP 的 Request 的 body 中字符串（字符流）的 HTML 文本，進行解析並構建 DOM 樹。

將字符流轉化為字符串之後，瀏覽器開始進行詞法分析，雖然這個名詞我們不熟悉，但是我們要知道，一個 HTML 字符串我們要拆分開才能構建 DOM 樹，詞法分析就是將字符串拆分成的過程。將字符串轉化為的 token（標記） —— token 作為代碼的最小單位，也就是拆分後的結果，這個過程我們稱為標記化。

我們將字符串拆解之後，然後將這些標記轉化為 Node 結點，瀏覽器根據不同的結點開始構建一棵 DOM 樹。這就是整個 DOM 樹構建的過程，其中還涉及到很多的細節，比如詞法分析是如何一個過程（狀態機），有興趣的小夥伴可以詳細查看英文文檔，在文章底部。

5.2

構建 CSSOM 樹

瀏覽器已經把 HTML 文件轉化為了 DOM 樹，下面就對 CSS 樣式文件進行解析，構建成 CSSOM 樹。這個過程和上述構建 DOM 樹的過程有點相似，但是其中 CSSOM 樹的構建更加的耗時。下面我們來看看如何耗時的？

瀏覽器通過遞歸的方式 DOM 樹為結點設置樣式。通過先找到具體的標籤，然後遞歸找到設置的上級標籤，最後確定選擇器選擇的所選標籤的樣式。

比如下邊的例子，瀏覽器是如何確定結點的樣式的呢？

<code> 1 

2
 3 
小鹿動畫學編程，一天一篇動畫餵飽你！
4
 5 
你好，小鹿！
6
 7
 8
 9 div span p{
10 color: red;
11 font-size: 12px;
12 }
13 div {
14 background:red;  

15 }
/<code>

首先在 HTML 中找到 p 標籤，一共有兩個地方，然後按照樣式的繼續遞歸中找具有父節點的 p，我們只好把第二個 p 過濾掉，然後繼續向上找父節點 div，匹配成功，然後將樣式設置到結點上。

我們通過上邊的動畫，可以知道為什麼構建 CSSOM 樹的時候非常耗時了，我們在寫代碼的時候可以做出優化，所以應該避免書寫過於具體的 CSS 選擇器，少一些添加無意義的 HTML 標籤，有利於提高習頁面的性能。

5.3

構建渲染樹

我們分別將上邊生成的 DOM 和 CSSOM 樹進行合併，生成我們的渲染樹。但是在合併的時候，並不是兩者簡單的進行結合，因為有些結點我們並不需要顯示，還記得有一個 display:none 屬性嗎？如果某結點的樣式有這個屬性，就不會出現在渲染樹中。

合成、繪製

瀏覽器在生成渲染樹的時候，就會根據渲染樹進行佈局，調用 GPU 進行繪製，然後合成圖層，最後顯示在屏幕上。

小結

通過上邊的對瀏覽器工作原理的介紹，相信你對瀏覽器有了新的認識和簡介，但是隻看上邊的知識還完全不能深入到底層，如果還想要進行深入的對瀏覽器的工作原理進行研究，可以看邊“”英文文檔《How Browsers Work》，已經有人把它翻譯成了中文，但是我自己又翻譯了一遍。

第一，提高自己閱讀英文文檔的能力；

第二，從中學會提取關鍵的內容。

雖然翻譯過程中遇到很多問題，但是相信你翻譯完之後，對你又有新的收穫和認識，更重要的是你的能力又比別人提升了 —— 更何況我這個英語四級沒過的人都堅持翻譯下來了呢！

如果看到這裡，說明你喜歡這篇文章，請轉發

閱讀更多 程序猿久一 的文章

關鍵字: 美好，一直在身邊 雲計算 前端開發