瀏覽器的底層是如何完成一次網路請求的？
對於面試的大部分前端開發者來說，對瀏覽器的瞭解也算是一知半解，因為我們一開始前端覺得，我們開發中通常使用瀏覽器來顯示和除錯頁面用的，不會涉入到太過的相關瀏覽器工作原理知識。
這你就大錯特錯了，雖然瀏覽器默默的為我們工作，但是有關瀏覽器的工作原理不但在你就業前端面試中屬於重中之重，也是在前端優化中佔有很大比重。作為一個前端開發如果不瞭解瀏覽器的工作原理，只能永遠停留在前端“切圖仔”水平。
PS：前幾天還有個讀者和小鹿說，之前看到小鹿朋友圈發過這個這個導圖，當時沒當回事，第二天面試竟然問到了。
學習瀏覽器工作原理是為了能夠運用到實際專案中，比如前端的效能優化以及錯誤排查，都會涉及到瀏覽器相關的知識，所以掌握瀏覽器的工作原理是必不可缺的，相信你學完之後，能夠對你的個人能力和見識會有很大的提升。
瀏覽器涉及到的知識點非常多而且非常重要，文章中可能其中有不足和錯誤的地方，也歡迎各位指出！
思維導圖
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 快取。
PS：ISP快取，本身是一種寬頻接入提供商給網頁批量訪問加速的技術。ISP會將當前訪問量較大的網頁內容放到ISP伺服器的快取中，當有新的使用者請求相同內容時，可以直接從快取中傳送相關資訊，不必每次都去訪問真正的網站，從而加快了不同使用者對相同內容的訪問速度，同時也能節省網間流量結算成本。
2.4 DNS 遞迴查詢
如果路由器快取和 ISP 的 DNS 快取還是沒有的話，我們就進行 DNS 遞迴查詢。從根域名伺服器開始查詢，然後再到頂級域名伺服器，最後到主域名伺服器依次查詢。
但是這裡有兩種查詢方式，不僅僅有遞迴查詢一種方式，還有一個查詢方式是迭代查詢，兩種查詢方式的區別是什麼呢？
迭代查詢：DNS 收到請求時，而不是直接返回查詢結果，而是告訴客戶端另一臺 DNS 伺服器地址。然後客戶端再向這臺的 DNS 伺服器提交請求，依次迴圈。
遞迴查詢：當 DNS 伺服器收到請求時，就會檢查 DNS 快取，如果沒有就會詢問其他伺服器，並將返回的查詢結果返回客戶端。
我們前端會在效能優化的使用用到 DNS 的相關知識，我們在這稍微提一下，如何進行 DNS 優化呢？
DNS 查詢經歷很多步驟，查詢很慢。瀏覽器獲取到 IP 地址後，一般都會加到瀏覽器的快取中，本地的 DNS 快取伺服器，也可以去記錄。
另外使用 DNS 負載均衡，通常我們的網站應用各種雲服務，DNS 系統根據每臺機器的負載量，地理位置的限制等等，去提供高效快速的 DNS 解析服務。
3、TCP 連線
我們通過 DNS 查詢到 IP 地址之後，我們就開始打算與伺服器建立連線，為接下來的資料傳輸做準備，這部分在之前的文章中寫的非常詳細，一定要去看哦。
網路分層模型
動畫：用動畫給面試官解釋 TCP 三次握手過程
4、HTTP 請求
我們客戶端與服務端通過 TCP 的三次握手建立連線之後，客戶端開始向伺服器主動發起請求。
PS：對於 HTTP 協議，我們會在後邊單獨拿出一篇文章來詳細介紹它的發展史，這裡我們只涉及到 HTTP 的請求相關的內容。
服務端接收到客戶端傳送的資訊，就返回響應資訊和檔案。客戶端如何判斷服務端是否成功返回了呢？就需要下列的一些狀態碼來識別，同樣前端做的工作也是通過狀態碼來判斷當前響應狀態。
- 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 樹為結點設定樣式。通過先找到具體的標籤，然後遞迴找到設定的上級標籤，最後確定選擇器選擇的所選標籤的樣式。
比如下邊的例子，瀏覽器是如何確定結點的樣式的呢？
1 <div>
2 <span>
3 <p>小鹿動畫學程式設計，一天一篇動畫餵飽你！</p>
4 </span>
5 <p>你好，小鹿！</p>
6 </div>
7
8
9 div span p{
10 color: red;
11 font-size: 12px;
12 }
13 div {
14 background:red;
15 }
首先在 HTML 中找到 p 標籤，一共有兩個地方，然後按照樣式的繼續遞迴中找具有父節點的 p，我們只好把第二個 p 過濾掉，然後繼續向上找父節點 div，匹配成功，然後將樣式設定到結點上。
我們通過上邊的動畫，可以知道為什麼構建 CSSOM 樹的時候非常耗時了，我們在寫程式碼的時候可以做出優化，所以應該避免書寫過於具體的 CSS 選擇器，少一些新增無意義的 HTML 標籤，有利於提高習頁面的效能。
5.3 構建渲染樹
我們分別將上邊生成的 DOM 和 CSSOM 樹進行合併，生成我們的渲染樹。但是在合併的時候，並不是兩者簡單的進行結合，因為有些結點我們並不需要顯示，還記得有一個 display:none 屬性嗎？如果某結點的樣式有這個屬性，就不會出現在渲染樹中。
5.4合成、繪製
瀏覽器在生成渲染樹的時候，就會根據渲染樹進行佈局，呼叫 GPU 進行繪製，然後合成圖層，最後顯示在螢幕上。
小結
通過上邊的對瀏覽器工作原理的介紹，相信你對瀏覽器有了新的認識和簡介，但是隻看上邊的知識還完全不能深入到底層，如果還想要進行深入的對瀏覽器的工作原理進行研究，可以英文文件《How Browsers Work》。