作者：4Ark
來源：https://4ark.me/post/b6c7c0a2.html
這個問題已經是老生常談了，更是經常被作為面試的壓軸題出現，網上也有很多文章，但最近閑的無聊，然后就自己做了一篇筆記，感覺比之前理解更透徹了，
注意：本文的步驟是建立在，請求的是一個簡單的 HTTP 請求，沒有 HTTPS、HTTP2、最簡單的 DNS、沒有代理、并且服務器沒有任何問題的基礎上，盡管這是不切實際的，
大致流程
-
URL 決議
-
DNS 查詢
-
TCP 連接
-
處理請求
-
接受回應
-
渲染頁面
一、URL 決議
地址決議：
首先判斷你輸入的是一個合法的 URL 還是一個待搜索的關鍵詞，并且根據你輸入的內容進行自動完成、字符編碼等操作，
HSTS
由于安全隱患，會使用 HSTS 強制客戶端使用 HTTPS 訪問頁面
其他操作
瀏覽器還會進行一些額外的操作，比如安全檢查、訪問限制（之前國產瀏覽器限制 996.icu），
檢查快取
二、DNS 查詢
基本步驟
1. 瀏覽器快取
瀏覽器會先檢查是否在快取中，沒有則呼叫系統庫函式進行查詢，
2. 作業系統快取
作業系統也有自己的 DNS快取，但在這之前，會向檢查域名是否存在本地的 Hosts 檔案里，沒有則向 DNS 服務器發送查詢請求，
3. 路由器快取
路由器也有自己的快取，
4. ISP DNS 快取
ISP DNS 就是在客戶端電腦上設定的首選 DNS 服務器，它們在大多數情況下都會有快取，
根域名服務器查詢
在前面所有步驟沒有快取的情況下，本地 DNS 服務器會將請求轉發到互聯網上的根域，下面這個圖很好的詮釋了整個流程：
根域名服務器（維基百科）
需要注意的點
遞回方式：一路查下去中間不回傳，得到最終結果才回傳資訊（瀏覽器到本地DNS服務器的程序）
迭代方式，就是本地DNS服務器到根域名服務器查詢的方式，
什么是 DNS 劫持
前端 dns-prefetch 優化
三、TCP 連接
TCP/IP 分為四層，在發送資料時，每層都要對資料進行封裝：
1. 應用層：發送 HTTP 請求
在前面的步驟我們已經得到服務器的 IP 地址，瀏覽器會開始構造一個 HTTP 報文，其中包括：
-
請求報頭（Request Header）：請求方法、目標地址、遵循的協議等等
-
請求主體（其他引數）
其中需要注意的點：瀏覽器只能發送 GET、POST 方法，而打開網頁使用的是 GET 方法
2. 傳輸層：TCP 傳輸報文
傳輸層會發起一條到達服務器的 TCP 連接，為了方便傳輸，會對資料進行分割（以報文段為單位），并標記編號，方便服務器接受時能夠準確地還原報文資訊，
在建立連接前，會先進行 TCP 三次握手，
關于 TCP/IP 三次握手，網上已經有很多段子和圖片生動地描述了，大家可以看下這篇：為什么 TCP 建立連接是三次握手，關閉連接確是四次揮手呢？
3. 網路層：IP協議查詢Mac地址
將資料段打包，并加入源及目標的IP地址，并且負責尋找傳輸路線，
判斷目標地址是否與當前地址處于同一網路中，是的話直接根據 Mac 地址發送，否則使用路由表查找下一跳地址，以及使用 ARP 協議查詢它的 Mac 地址，
注意：在 OSI 參考模型中 ARP 協議位于鏈路層，但在 TCP/IP 中，它位于網路層，
4. 鏈路層：以太網協議
以太網協議
根據以太網協議將資料分為以“幀”為單位的資料包，每一幀分為兩個部分：
-
標頭：資料包的發送者、接受者、資料型別
-
資料：資料包具體內容
Mac 地址
以太網規定了連入網路的所有設備都必須具備“網卡”介面，資料包都是從一塊網卡傳遞到另一塊網卡，網卡的地址就是 Mac 地址，每一個 Mac 地址都是獨一無二的，具備了一對一的能力，
廣播
發送資料的方法很原始，直接把資料通過 ARP 協議，向本網路的所有機器發送，接收方根據標頭資訊與自身 Mac 地址比較，一致就接受，否則丟棄，
注意：接收方回應是單播，
服務器接受請求
接受程序就是把以上步驟逆轉過來，參見上圖，
四、服務器處理請求
大致流程
HTTPD
最常見的 HTTPD 有 Linux 上常用的 Apache 和 Nginx，以及 Windows 上的 IIS，
它會監聽得到的請求，然后開啟一個子行程去處理這個請求，
處理請求
接受 TCP 報文后，會對連接進行處理，對HTTP協議進行決議（請求方法、域名、路徑等），并且進行一些驗證：
-
驗證是否配置虛擬主機
-
驗證虛擬主機是否接受此方法
-
驗證該用戶可以使用該方法（根據 IP 地址、身份資訊等）
重定向
假如服務器配置了 HTTP 重定向，就會回傳一個 301永久重定向回應，瀏覽器就會根據回應，重新發送 HTTP 請求（重新執行上面的程序），
URL 重寫
然后會查看 URL 重寫規則，如果請求的檔案是真實存在的，比如圖片、html、css、js檔案等，則會直接把這個檔案回傳，否則服務器會按照規則把請求重寫到 一個 REST 風格的 URL 上，然后根據動態語言的腳本，來決定呼叫什么型別的動態檔案解釋器來處理這個請求，
以 PHP 語言的 MVC 框架舉例，它首先會初始化一些環境的引數，根據 URL 由上到下地去匹配路由，然后讓路由所定義的方法去處理請求，
關注微信公眾號：Java技術堆疊，在后臺回復：架構，可以獲取我整理的 N 篇最新架構教程，都是干貨，
五、瀏覽器接受回應
瀏覽器接收到來自服務器的回應資源后，會對資源進行分析，
首先查看 Response header，根據不同狀態碼做不同的事（比如上面提到的重定向），
如果回應資源進行了壓縮（比如 gzip），還需要進行解壓，
然后，對回應資源做快取，
接下來，根據回應資源里的 MIME[3] 型別去決議回應內容（比如 HTML、Image各有不同的決議方式），
六、渲染頁面
瀏覽器內核
不同的瀏覽器內核，渲染程序也不完全相同，但大致流程都差不多，
基本流程
6.1. HTML 決議
首先要知道瀏覽器決議是從上往下一行一行地決議的，
決議的程序可以分為四個步驟：
① 解碼（encoding）
傳輸回來的其實都是一些二進制位元組資料，瀏覽器需要根據檔案指定編碼（例如UTF-8）轉換成字串，也就是HTML 代碼，
② 預決議（pre-parsing）
預決議做的事情是提前加載資源，減少處理時間，它會識別一些會請求資源的屬性，比如img標簽的src屬性，并將這個請求加到請求佇列中，
③ 符號化（Tokenization）
符號化是詞法分析的程序，將輸入決議成符號，HTML 符號包括，開始標簽、結束標簽、屬性名和屬性值，
它通過一個狀態機去識別符號的狀態，比如遇到<，>狀態都會產生變化，
④ 構建樹（tree construction）
注意：符號化和構建樹是并行操作的，也就是說只要決議到一個開始標簽，就會創建一個 DOM 節點，
在上一步符號化中，決議器獲得這些標記，然后以合適的方法創建DOM物件并把這些符號插入到DOM物件中，
<html><head><title>Web page parsing</title></head><body><div><h1>Web page parsing</h1><p>This is an example Web page.</p></div></body></html>
瀏覽器容錯進制
你從來沒有在瀏覽器看過類似”語法無效”的錯誤，這是因為瀏覽器去糾正錯誤的語法，然后繼續作業，
事件
當整個決議的程序完成以后，瀏覽器會通過DOMContentLoaded事件來通知DOM決議完成，
6.2. CSS 決議
一旦瀏覽器下載了 CSS，CSS 決議器就會處理它遇到的任何 CSS，根據語法規范[4]決議出所有的 CSS 并進行標記化，然后我們得到一個規則表，
CSS 匹配規則
在匹配一個節點對應的 CSS 規則時，是按照從右到左的順序的，例如：div p { font-size :14px }會先尋找所有的p標簽然后判斷它的父元素是否為div，
所以我們寫 CSS 時，盡量用 id 和 class，千萬不要過度層疊，
6.3. 渲染樹
其實這就是一個 DOM 樹和 CSS 規則樹合并的程序，
注意：渲染樹會忽略那些不需要渲染的節點，比如設定了display:none的節點，
計算
通過計算讓任何尺寸值都減少到三個可能之一：auto、百分比、px，比如把rem轉化為px，
級聯
瀏覽器需要一種方法來確定哪些樣式才真正需要應用到對應元素，所以它使用一個叫做specificity的公式，這個公式會通過：
-
標簽名、class、id
-
是否行內樣式
-
!important
然后得出一個權重值，取最高的那個，
渲染阻塞
當遇到一個script標簽時，DOM 構建會被暫停，直至腳本完成執行，然后繼續構建 DOM 樹，
但如果 JS 依賴 CSS 樣式，而它還沒有被下載和構建時，瀏覽器就會延遲腳本執行，直至 CSS Rules 被構建，
所有我們知道：
-
CSS 會阻塞 JS 執行
-
JS 會阻塞后面的 DOM 決議
為了避免這種情況，應該以下原則：
-
CSS 資源排在 JavaScript 資源前面
-
JS 放在 HTML 最底部，也就是
</body>前
另外，如果要改變阻塞模式，可以使用 defer 與 async，
6.4. 布局與繪制
確定渲染樹種所有節點的幾何屬性，比如：位置、大小等等，最后輸入一個盒子模型，它能精準地捕獲到每個元素在螢屏內的準確位置與大小，
然后遍歷渲染樹，呼叫渲染器的 paint() 方法在螢屏上顯示其內容，
6.5. 合并渲染層
把以上繪制的所有圖片合并，最終輸出一張圖片，
6.6. 回流與重繪
回流(reflow)
當瀏覽器發現某個部分發現變化影響了布局時，需要倒回去重新渲染，會從html標簽開始遞回往下，重新計算位置和大小，
reflow基本是無法避免的，因為當你滑動一下滑鼠、resize 視窗，頁面就會產生變化，
重繪(repaint)
改變了某個元素的背景色、文字顏色等等不會影響周圍元素的位置變化時，就會發生重繪，
每次重繪后，瀏覽器還需要合并渲染層并輸出到螢屏上，
回流的成本要比重繪高很多，所以我們應該盡量避免產生回流，
比如：display:none 會觸發回流，而 visibility:hidden 只會觸發重繪，
6.7. JavaScript 編譯執行
大致流程
可以分為三個階段：
1. 詞法分析
JS 腳本加載完畢后，會首先進入語法分析階段，它首先會分析代碼塊的語法是否正確，不正確則拋出“語法錯誤”，停止執行，
幾個步驟：
-
分詞，例如將
var a = 2，，分成var、a、=、2這樣的詞法單元， -
決議，將詞法單元轉換成抽象語法樹（AST），
-
代碼生成，將抽象語法樹轉換成機器指令，
2. 預編譯
JS 有三種運行環境：
-
全域環境
-
函式環境
-
eval
每進入一個不同的運行環境都會創建一個對應的執行背景關系，根據不同的背景關系環境，形成一個函式呼叫堆疊，堆疊底永遠是全域執行背景關系，堆疊頂則永遠是當前執行背景關系，
創建執行背景關系
創建執行背景關系的程序中，主要做了以下三件事：
-
創建變數物件
-
引數、函式、變數
-
建立作用域鏈
-
確認當前執行環境是否能訪問變數
-
確定 This 指向
3. 執行
JS 執行緒
雖然 JS 是單執行緒的，但實際上參與作業的執行緒一共有四個：
其中三個只是協助，只有 JS 引擎執行緒是真正執行的
其中三個只是協助，只有 JS 引擎執行緒是真正執行的
JS 引擎執行緒：也叫 JS 內核，負責決議執行 JS 腳本程式的主執行緒，例如 V8 引擎事件觸發執行緒：屬于瀏覽器內核執行緒，主要用于控制事件，例如滑鼠、鍵盤等，當事件被觸發時，就會把事件的處理函式推進事件佇列，等待 JS 引擎執行緒執行定時器觸發執行緒：主要控制
setInterval和setTimeout，用來計時，計時完畢后，則把定時器的處理函式推進事件佇列中，等待 JS 引擎執行緒，HTTP 異步請求執行緒：通過XMLHttpRequest連接后，通過瀏覽器新開的一個執行緒，監控readyState狀態變更時，如果設定了該狀態的回呼函式，則將該狀態的處理函式推進事件佇列中，等待JS引擎執行緒執行，
注：瀏覽器對同一域名的并發連接數是有限的，通常為 6 個，
宏任務
分為：
-
同步任務：按照順序執行，只有前一個任務完成后，才能執行后一個任務
-
異步任務：不直接執行，只有滿足觸發條件時，相關的執行緒將該異步任務推進任務佇列中，等待JS引擎主執行緒上的任務執行完畢時才開始執行，例如異步Ajax、DOM事件，setTimeout等，
微任務
微任務是ES6和Node環境下的，主要 API 有：Promise，process.nextTick，
微任務的執行在宏任務的同步任務之后，在異步任務之前，
代碼例子
console.log('1'); // 宏任務 同步
setTimeout(function() {
console.log('2'); // 宏任務 異步})
new Promise(function(resolve) {
console.log('3'); // 宏任務 同步
resolve();
}).then(function() {
console.log('4')// 微任務})
console.log('5') // 宏任務 同步
以上代碼輸出順序為：1,3,5,4,2
近期熱文推薦：
1.Java 15 正式發布， 14 個新特性，重繪你的認知！！
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看，，
4.吊打 Tomcat ，Undertow 性能很炸！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/249313.html
標籤：Java
上一篇：java爬蟲-初識