## 前言
這個問題已經是老生常談了，更是經常被作為面試的壓軸題出現，網上也有很多文章，但最近閒的無聊，然後就自己做了一篇筆記，感覺比之前理解更透徹了。
這篇筆記是我這兩天看了數十篇文章總結出來的，所以相對全面一點，但由於我是做前端的，所以會比較重點分析瀏覽器渲染頁面那一部分，至於其他部分我會羅列出關鍵詞，感興趣的可以自行查閱，
**注意**：本文的步驟是建立在，請求的是一個簡單的 HTTP 請求，沒有 HTTPS、HTTP2、最簡單的 DNS、沒有代理、並且伺服器沒有任何問題的基礎上，儘管這是不切實際的。
## 大致流程
1、URL 解析
2、DNS 查詢
3、TCP 連線
4、處理請求
5、接受響應
6、渲染頁面
## 一、URL 解析
**地址解析**
首先判斷你輸入的是一個合法的 URL 還是一個待搜尋的關鍵詞，並且根據你輸入的內容進行自動完成、字元編碼等操作。
**HSTS**
由於安全隱患，會使用 HSTS 強制客戶端使用 HTTPS 訪問頁面。詳見：你所不知道的 HSTS。
**其他操作**
瀏覽器還會進行一些額外的操作，比如安全檢查、訪問限制（之前國產瀏覽器限制 996.icu）。
**檢查快取**
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/84af8fa5a3784722865c90843988a077.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5byR5aSp5YC-5Z-O,size_20,color_FFFFFF,t_70,g_se,x_16)
## 二、DNS 查詢
**基本步驟**
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/a601c68e6df44cb09a49fe6031ac0355.png)
**1、瀏覽器快取**
瀏覽器會先檢查是否在快取中，沒有則呼叫系統庫函式進行查詢。
**2、作業系統快取**
作業系統也有自己的 DNS快取，但在這之前，會向檢查域名是否存在本地的 Hosts 檔案裡，沒有則向 DNS 伺服器傳送查詢請求。
**3、路由器快取**
路由器也有自己的快取。
**4、ISP DNS 快取**
ISP DNS 就是在客戶端電腦上設定的首選 DNS 伺服器，它們在大多數情況下都會有快取。
**根域名伺服器查詢**
在前面所有步驟沒有快取的情況下，本地 DNS 伺服器會將請求轉發到網際網路上的根域，下面這個圖很好的詮釋了整個流程：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/be434800866c47c887451578aaf56bac.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5byR5aSp5YC-5Z-O,size_20,color_FFFFFF,t_70,g_se,x_16)
**需要注意的點**
1、遞迴方式：一路查下去中間不返回，得到最終結果才返回資訊（瀏覽器到本地DNS伺服器的過程）
2、迭代方式，就是本地DNS伺服器到根域名伺服器查詢的方式。
3、什麼是 DNS 劫持
4、前端 dns-prefetch 最佳化
## 三、TCP 連線
TCP/IP 分為四層，在傳送資料時，每層都要對資料進行封裝：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/f124bb25de5d4dba9fc676426878fb21.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5byR5aSp5YC-5Z-O,size_20,color_FFFFFF,t_70,g_se,x_16)
**1、應用層：傳送 HTTP 請求**
在前面的步驟我們已經得到伺服器的 IP 地址，瀏覽器會開始構造一個 HTTP 報文，其中包括：
**請求報頭（Request Header）：**
請求方法、目標地址、遵循的協議等等
**請求主體（其他引數）**
其中需要注意的點：
```
	瀏覽器只能傳送 GET、POST 方法，而開啟網頁使用的是 GET 方法
```
**2、傳輸層：TCP 傳輸報文**
傳輸層會發起一條到達伺服器的 TCP 連線，為了方便傳輸，會對資料進行分割（以報文段為單位），並標記編號，方便伺服器接受時能夠準確地還原報文資訊。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku
在建立連線前，會先進行 TCP 三次握手。
```
關於 TCP/IP 三次握手，網上已經有很多段子和圖片生動地描述了。
相關知識點：
```
**1、SYN 泛洪攻擊**
**3、網路層：IP協議查詢Mac地址**
將資料段打包，並加入源及目標的IP地址，並且負責尋找傳輸路線。
判斷目標地址是否與當前地址處於同一網路中，是的話直接根據 Mac 地址傳送，否則使用路由表查詢下一跳地址，以及使用 ARP 協議查詢它的 Mac 地址。
```
注意：在 OSI 參考模型中 ARP 協議位於鏈路層，但在 TCP/IP 中，它位於網路層。
```
**4、鏈路層：乙太網協議**
**乙太網協議**
根據乙太網協議將資料分為以“幀”為單位的資料包，每一幀分為兩個部分：
**標頭：**
資料包的傳送者、接受者、資料型別
**資料：**
資料包具體內容
**Mac 地址**
乙太網規定了連入網路的所有裝置都必須具備“網路卡”介面，資料包都是從一塊網路卡傳遞到另一塊網路卡，網路卡的地址就是 Mac 地址。每一個 Mac 地址都是獨一無二的，具備了一對一的能力。
**廣播**
傳送資料的方法很原始，直接把資料透過 ARP 協議，向本網路的所有機器傳送，接收方根據標頭資訊與自身 Mac 地址比較，一致就接受，否則丟棄。
**注意**：接收方回應是單播。
```
相關知識點：
```
1、ARP 攻擊
**伺服器接受請求**
接受過程就是把以上步驟逆轉過來，參見上圖。
## 四、伺服器處理請求
**大致流程**
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/a3dfd2af0f454ef48f367832f08ae14f.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5byR5aSp5YC-5Z-O,size_20,color_FFFFFF,t_70,g_se,x_16)
**HTTPD**
最常見的 HTTPD 有 Linux 上常用的 Apache 和 Nginx，以及 Windows 上的 IIS。
它會監聽得到的請求，然後開啟一個子程式去處理這個請求。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku
**處理請求**
接受 TCP 報文後，會對連線進行處理，對HTTP協議進行解析（請求方法、域名、路徑等），並且進行一些驗證：
1、驗證是否配置虛擬主機
2、驗證虛擬主機是否接受此方法
3、驗證該使用者可以使用該方法（根據 IP 地址、身份資訊等）
**重定向**
假如伺服器配置了 HTTP 重定向，就會返回一個 301永久重定向響應，瀏覽器就會根據響應，重新傳送 HTTP 請求（重新執行上面的過程）。
```
關於更多：詳見這篇文章
```
**URL 重寫**
然後會檢視 URL 重寫規則，如果請求的檔案是真實存在的，比如圖片、html、css、js檔案等，則會直接把這個檔案返回。
否則伺服器會按照規則把請求重寫到 一個 REST 風格的 URL 上。
然後根據動態語言的指令碼，來決定呼叫什麼型別的動態檔案直譯器來處理這個請求。
以 PHP 語言的 MVC 框架舉例，它首先會初始化一些環境的引數，根據 URL 由上到下地去匹配路由，然後讓路由所定義的方法去處理請求。
## 五、瀏覽器接受響應
瀏覽器接收到來自伺服器的響應資源後，會對資源進行分析。
首先檢視 Response header，根據不同狀態碼做不同的事（比如上面提到的重定向）。
如果響應資源進行了壓縮（比如 gzip），還需要進行解壓。整編：微信公眾號，搜雲庫技術團隊，ID：souyunku
然後，對響應資源做快取。
接下來，根據響應資源裡的 MIME 型別去解析響應內容（比如 HTML、Image各有不同的解析方式）。
##  六、渲染頁面
**瀏覽器核心**
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/3903486ae83543f3abc714021256aa5c.jpg?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5byR5aSp5YC-5Z-O,size_20,color_FFFFFF,t_70,g_se,x_16)
不同的瀏覽器核心，渲染過程也不完全相同，但大致流程都差不多。
**基本流程**
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/40f5d76c7293439495e24bc045c4329d.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5byR5aSp5YC-5Z-O,size_20,color_FFFFFF,t_70,g_se,x_16)
**1、HTML 解析**
首先要知道瀏覽器解析是從上往下一行一行地解析的。
解析的過程可以分為四個步驟：
**1. 解碼（encoding）**
傳輸回來的其實都是一些二進位制位元組資料，瀏覽器需要根據檔案指定編碼（例如UTF-8）轉換成字串，也就是HTML 程式碼。
**2. 預解析（pre-parsing）**
預解析做的事情是提前載入資源，減少處理時間，它會識別一些會請求資源的屬性，比如 img標籤的 src屬性，並將這個請求加到請求佇列中。
**3. 符號化（Tokenization）**
符號化是詞法分析的過程，將輸入解析成符號，HTML 符號包括，開始標籤、結束標籤、屬性名和屬性值。
它透過一個狀態機去識別符號的狀態，比如遇到 狀態都會產生變化。
**4. 構建樹（tree construction）**
```
注意：符號化和構建樹是並行操作的，也就是說只要解析到一個開始標籤，就會建立一個 DOM 節點。
```
在上一步符號化中，解析器獲得這些標記，然後以合適的方法建立 DOM物件並把這些符號插入到 DOM物件中。
```html

<title>
		Web page parsing
		</title>
	
	
		<div>
			<h1>
				Web page parsing
			</h1>
			<p>
				This is an example Web page.
			</p>
		</div>

```
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/8a38279a4e8546d5b5b35b6896461a92.jpg?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA5byR5aSp5YC-5Z-O,size_20,color_FFFFFF,t_70,g_se,x_16)
**瀏覽器容錯進位制**
你從來沒有在瀏覽器看過類似”語法無效”的錯誤，這是因為瀏覽器去糾正錯誤的語法，然後繼續工作。
**事件**
當整個解析的過程完成以後，瀏覽器會透過 DOMContentLoaded事件來通知 DOM解析完成。
**2、CSS 解析**
一旦瀏覽器下載了 CSS，CSS 解析器就會處理它遇到的任何 CSS，根據語法規範解析出所有的 CSS 並進行標記化，然後我們得到一個規則表。
**CSS 匹配規則**
在匹配一個節點對應的 CSS 規則時，是按照從右到左的順序的，例如：div p{font-size:14px}會先尋找所有的 p標籤然後判斷它的父元素是否為 div。
所以我們寫 CSS 時，儘量用 id 和 class，千萬不要過度層疊。
**3、 渲染樹**
其實這就是一個 DOM 樹和 CSS 規則樹合併的過程。
```
注意：渲染樹會忽略那些不需要渲染的節點，比如設定了 display:none的節點。
```
**計算**
透過計算讓任何尺寸值都減少到三個可能之一：auto、百分比、px，比如把 rem轉化為 px。
**級聯**
瀏覽器需要一種方法來確定哪些樣式才真正需要應用到對應元素，所以它使用一個叫做 specificity的公式，這個公式會透過：
1、標籤名、class、id
2、是否內聯樣式
3、 !important
然後得出一個權重值，取最高的那個。
**渲染阻塞**
當遇到一個 script標籤時，DOM 構建會被暫停，直至指令碼完成執行，然後繼續構建 DOM 樹。
但如果 JS 依賴 CSS 樣式，而它還沒有被下載和構建時，瀏覽器就會延遲指令碼執行，直至 CSS Rules 被構建。
所有我們知道：
1、CSS 會阻塞 JS 執行
2、JS 會阻塞後面的 DOM 解析
**為了避免這種情況，應該以下原則：**
1、CSS 資源排在 JavaScript 資源前面
2、JS 放在 HTML 最底部，也就是

在瀏覽器輸入 URL 回車之後發生了什麼（流程圖，超詳細版）

相關文章