流程圖

這題扎眼看上去沒問題，無非是 HTTP 請求到瀏覽器渲染，但可以聊的東西很多。我想它的執行順序是，用戶輸入——開始導航——HTTP請求——瀏覽器渲染。其中用戶輸入、開始導航、瀏覽器渲染是瀏覽器方面的知識點，HTTP請求是 HTTP 方面的知識點。

以下就是從輸入 url 到看到頁面的整個流程圖。

從url輸入到頁面渲染

前言

了解"開始導航"之前，需要先知道瀏覽器架構，簡單來說，現代瀏覽器由1個瀏覽器主進程、1個GPU進程、多個渲染進程、多個插件進程、網絡進程、音頻進程、存儲進程組成。

下圖是李兵在《瀏覽器工作原理與實踐》中所示，展示 Chrome 瀏覽器的架構。

目前的瀏覽器架構

以及未來現代瀏覽器架構示意圖：

未來現代chrome瀏覽器架構

文章現代瀏覽器內部揭秘中有一張圖，是這樣描述的。

現代瀏覽器內部解密

圖中表明瀏覽器主進程包含了 UI 線程、網絡線程、存儲線程，與李兵的觀點有所不同。那以誰為準呢?以時間為準，李兵的專欄是19年所寫，而《現代瀏覽器內部解密》是 18 年的文章，站在 2022 年的背景，現代瀏覽器，UI、網絡、存儲等都已升級為進程，而非是瀏覽器主進程中的線程。

用戶輸入

當用戶在地址欄中輸入一個字符串時，地址欄會判斷輸入的關鍵字是搜索內容，還是請求的URL。

• 如果是搜索內容，地址欄會使用瀏覽器默認的搜索引擎，合成新的帶搜索關鍵字的URL 例如在chrome中搜長澤雅美在chrome中搜長澤雅美。
• 如果輸入內容符合 URL 規則，例如輸入azhubaby.com，那么地址欄會根據規則，把這段內容加上協議合成完成的 URL，如 https://azhubaby.com。

當用戶輸入關鍵字并鍵入回車之后，意味著當前頁面將替換為新的頁面，此時瀏覽器中有個 API——beforeunload，它允許頁面在離開之前觸發是否一個確認對話框。這里使用此API，可讓瀏覽器不再導航。

// 監聽離開頁面前的事件
window.addEventListener('beforeunload', (event) => {
 event.preventDefault();
    event.returnValue = '';
})

可在這里看看 beforeunload 的demo。

從瀏覽器架構分工上講，當用戶輸入字符串時是 UI 進程(老一點的瀏覽器是瀏覽器主進程)在運作。

開始導航

當敲下 Enter 鍵時，UI 進程將指揮權交接給了網絡進程。網絡進程接受請求指令前，會先查找本地緩存是否有緩存。如果有緩存該資源，那么直接返回資源給瀏覽器進程;如果在緩存中沒找到該資源，那么則正式進入HTTP請求階段。

關于HTTP緩存方面的知識可以看看這篇——面試常客：HTTP 緩存。

HTTP請求

之前寫過一篇TCP/IP 協議及網絡分層模型，講述了 TCP/IP 網絡分層協議，它就像搭積木一樣，每一層需要下一層的支撐，我們的 HTTP 請求是其 HTTP 協議的應用，需要先連接傳輸層(TCP)以及更底層網絡互連層(IP)。

TCP/IP 網絡分層模型

而IP從哪里來，通過 DNS， 使其域名 和 IP 做映射。

我們使用倒推法可以理清“路線”：

HTTP 請求 —— HTTP 協議連接 —— TCP 協議連接 —— IP 協議連接 —— 需要知道 IP——DNS 做域名/IP映射。

所以進入 HTTP 請求的第一步是 DNS 解析。

DNS 解析

這里對 DNS 不做過多概述，簡單來說，它的作用是用域名代替 IP 地址，符合人的記憶。輸入du.azhubaby.com ，表示 IP 地址 47.102.152.19 ，你可以在命令行中 ping 一個域名，來求證一下結果。

ping域名

HTTP 請求之前的第一步是判斷 DNS 中是否有緩存，如果有，直接返回 IP 地址;如果沒有，則進行 DNS 解析，并把結果 IP 緩存到 DNS。

有了 IP 地址后，IP 層連接成功，接下來就是 TCP 傳輸層。

TCP 連接

這里要看HTTP協議的版本，如果是 HTTP/1.1 的話，就要考慮TCP隊列否飽滿，因為 HTTP/1.1 最多允許一個域名連接 6 條TCP，太多了就要在等待TCP隊列中排隊;如果是 HTTP/2 的話，那就沒事，它允許TCP并發。

這里還要考慮到如果協議是 HTTPS 協議的話，還需要建立一條 TLS 連接。

等真正 TCP 連接時，就聯想到網紅面試題：三次握手、四次揮手。

三次握手、四次揮手

為什么是三次握手和四次揮手，因為只有這樣才能讓雙方(客戶端和服務端)知道彼此的接收能力和發送能力是沒問題的。

http-tcp-three-handshakes

步驟為：

• 客戶端提出建立連接，發出客戶端seq：seq=client_isn。
• 服務端收到消息后返回 ack=client_isn+1 和服務端seq：seq=server_isn。
• 客戶端收到后返回ack=server_isn+1 表示收到了。

可以理解為男女雙方確認關系，男女雙方要結婚，怎么辦?先見父母得到父母認同，之前聽過這樣一句話：得不到父母祝福的婚姻是不幸福的(當然，不見父母直接結婚的也有，但不主流)。

• 男方提出去女方家，帶上見面禮seq：seq=男方的誠意。
• 女方家收到見面禮后返回(給男方)紅包 ack=我們認可你啦 以及女方去男方家也帶上見面禮seq：seq=女方的誠意。
• 男方家收到見面禮后返回(給女方的)紅包 ack=server_isn+1。

這個叫確定關系。所以要又來又回三次，雙方都確保知道對方的誠意和自己的誠意。

那什么是四次揮手呢?

在斷開之前，需要進行四次揮手。

http-tcp-four-handshakes

為什么要有四次揮手?

主要是為了確保雙方都知道對方斷開連接。

具體步驟為：

• 客戶端第一次發送消息給服務端告訴它需要斷開連接。
• 服務端收到消息后返回消息告訴客戶端：知道了，為了確保服務端收到了之前所有的 HTTP 請求，服務端需要等一等再斷開連接。
• 服務端確認所有的HTTP請求都收到了，主動發消息給客戶端：我這邊所有的請求都處理完了，我也可以斷開連接了。
• 客戶端收到這個請求后，返回消息告訴服務端：我知道，斷開連接吧。

主要是為了確認雙方的接收能力和發送能力是否正常、制定自己的初始化序列號為后面的可靠性傳送做準備。

可以理解為一對男女要分手。

• 女方提出分手，說你對我不好，我要分手。
• 男方覺得需求合理，同意分手，但分手之前要把聯系方式、合照、各種亂七八糟的的事情算清楚再分手。
• 男方理清楚后，主動發消息給女方，說這邊都處理清楚了，以后你是你，我是我，我們可以分手了。
• 女方收到消息后，返回告訴男方：我知道了，分手吧。

于是乎，它們就斷了，分手手續完成。具體詳細的信息可看猿人谷的面試官，不要再問我三次握手和四次揮手，一個字：細。

發送HTTP請求

TCP連接已經通了，現在正式發送 HTTP 請求，這里又有的聊了，如 HTTP 的報文內容、請求頭、響應頭、請求方法、狀態碼等知識點。

首先 HTTP 的報文結構由 起始行 + 頭部 + 空行 + 實體組成，簡單來說就是 header+body，HTTP 的報文可以沒有body(get方法)，但必須要有 header。

請求頭由請求行 + 頭部字段構成，響應頭由狀態行 + 頭部字段構成。

請求行有三部分：請求方法、請求目標和版本號。

• 例如 GET / HTTP/1.1。

狀態行也有三部分：版本號、狀態碼和原因字符串。

• 例如 HTTP/1.1 200 OK。

在瀏覽器中，打開F12，在 NetWork 中任何一個請求中，你都會看到這樣的結構。

報文結構

這里我們也常會遇到一些例如 GET 和 POST 請求方式的區別、HTTP 狀態碼等相關的衍生問題。

GET 和 POST 請求方式的區別

• 從緩存角度看，GET 會被緩存，POST 不會被緩存。
• 從參數角度看，GET 通過在 URL 的"?"后以 key=value 方式傳參，數據之間以“&”相連接;POST 則要將數據封裝到請求體中發送，這個過程不可見。
• 從安全角度看，GET 不安全，因為 URL 可見;POST 較 GET 安全度高。
• 從編碼角度看，GET 只接受 ASCII 字符，向服務器發送中文字符可能會出現亂碼;POST 支持標準字符集，可以正確傳遞中文。
• 從數據長度的限制看，GET 一般受 URL 長度限制(URL 的最大長度是 2048 個字符)，POST 無限制。

HTTP 狀態碼

RFC 標準把狀態碼分成了五類 ，用數字的第一位表示分類，而 0~99 不用，這樣狀態碼的實際可用范圍就大大縮小了，由 000~999 變成了 100~599。

這五類的具體含義是：

• 1××：提示信息，表示目前是協議處理的中間狀態，還需要后續的操作。
• 2××：成功，報文已經收到并被正確處理。
• 3××：重定向，資源位置發生變動，需要客戶端重新發送請求。
• 4××：客戶端錯誤，請求報文有誤，服務器無法處理。
• 5××：服務器錯誤，服務器在處理請求時內部發生了錯誤。

目前 RFC 標準里總共有 41 個狀態碼。

• 101 - Switching Protocols，客戶端使用 Upgrade 頭字段。
• 200 - 請求成功。
• 204 - 無內容，服務器成功處理了請求，但沒有返回任何內容。
• 206 - 一般用來做斷點續傳，或者是視頻文件等大文件的加載。
• 301 - 永久重定向。
• 302 - 臨時重定向。
• 304 - 未修改協商緩存，返回緩存中的數據。它不具有通常的跳轉含義，但可以理解成 重定向到緩存的文件(即緩存重定向)。
• 400 - 請求中語法錯誤。
• 401 - 未授權。
• 403 - 服務器收到請求，但是拒絕提供服務，即資源不可用。
• 404 - 無法找到請求資源。
• 408 Request Timeout - 請求超時。
• 414 - 請求 URI 過長(如圖一新浪常有)。
• 500 - 服務器內部錯誤。
• 501 - 尚未實施：服務器不具備請求功能。
• 502 - 網關錯誤。
• 503 - 服務器不可用，主動用503響應請求或 Nginx 設置限速，超過限速，會返回503。
• 504 - 網關超時。

這里要對 304 做一下說明，當請求頭 If-Modified-Since 或 If-None-Match 中判斷修改時間是否一致(或唯一標識是否一致)，是，則返回304，使用瀏覽器內存中的本地緩存;不一致則說明要更新，繼續請求資源放回給客戶端，并帶上 Last-Modified 或 ETag。

請求方式

HTTP/1.1 規定了八種方法，都必須是大寫形式。

• GET：獲取資源，可以理解為讀取或者下載數據。只有GET請求才能起到緩存效果。
• HEAD：獲取資源的元信息。
• POST：像資源提交數據，相當于寫入或上傳數據。
• PUT：類似 POST。
• DELETE：刪除資源。
• CONNECT：建立特殊的連接隧道。
• OPTIONS：列出可對資源實行的方式。
• TRACE：追蹤請求 - 響應的傳輸路徑。

瀏覽器渲染

當HTTP 請求完畢后，斷開 TCP 連接，將資源返回給客戶端(瀏覽器)。此時瀏覽器要判斷是否與打開的網站是同一個站點。因為如果是同一個站點的話，則可使用同站點的渲染進程渲染頁面，如果不是，瀏覽器則打開新的渲染進程解析資源。

瀏覽器渲染的大致流程如下圖所示：

瀏覽器渲染大致流程

我們可以將頁面渲染分為三個步驟：

解析

• HTML 被解析為 DOM 樹，CSS 被解析為 CSS 規則樹，JavaScript 通過 DOM API 和 CSSOM API 來操作 DOM Tree 和 CSS Rule Tree。

渲染

• 瀏覽器引擎通過 DOM Tree 和 CSS Rule Tree 構建 Rendering Tree(渲染樹)，這其中進行大量的 回流(Reflow) 和 重繪(Repaint)。
• 回流和重繪 回流：意味著元件的幾何尺寸變了，需要重新驗證并計算 Render Tree重繪：屏幕的一部分需要重畫，比如某個CSS 的背景色變了，但元件的幾何尺寸沒有變回流的成本要比重繪大。

繪制

• 最后通過操作系統(瀏覽器)的Native GUI的API繪制。

其中，衍生出重繪和回流的問題，提高性能的方法之一就是減少瀏覽器的渲染時間，其中的一個優化點就是減少重繪和回流。

減少回流和重繪的方法

1. 不要一條條修改 DOM 樣式，與其這樣，不如預定義好CSS的class，然后修改DOM的樣式。
2. 把DOM“離線”后修改 使用 documentFragment 對象在內存里操作 DOM先把 DOM 給 display：none(有一次 。 Reflow)，然后你想怎么改就怎么改，再把它顯示出來clone 一個 DOM 節點到內存里，然后想怎么改就怎么改，改完后和在線的那個交換一下。
3. 不要把 DOM 節點的屬性值放在一個循環中當作循環的變量，不然這會導致大量地讀寫這個節點的屬性
4. 盡可能地修改層級比較低的DOM。
5. 不要使用 table 布局。

造成回流的屬性：

width、height、padding、margin、border、position、top、left、bottom、right、float、clear、text-align、vertical-align、line-height、font-weight、font-size、font-family、overflow、white-space

造成重繪的屬性：

color、border-style、border-radius、text-decoration、box-shadow、outline、background

記住一點，回流是與幾何大小相關，重繪與大小無關。

如此，從輸入 url 到看到頁面的整個流程就走完了。

總結

這道題能衍生很多問題，從一題可以測試出面試者的HTTP、瀏覽器相關知識。正所謂”鵬怒而飛，其翼若垂天之云;水擊三千里，碧空九萬丈;好風憑借力，送我上青云。“。這道題之所以能成為經典題，不是沒有它的原因的。

筆者這里做一個總結，把這題可以衍生的知識點逐一列出，待君思索。

瀏覽器方面

• 瀏覽器架構 由什么組成?瀏覽器主進程、GPU進程、多個渲染進程、多個插件進程、網絡進程、音頻進程、存儲進程等渲染進程中有哪些進程?GUI渲染線程、JS 引擎線程、事件觸發線程、網絡異步線程、定時器線程進程和線程的區別?進程是應用程序創建的實例，而線程依托于進程，它是計算機最小的運行單位。
• 瀏覽器渲染 渲染流程?解析、渲染、繪制重繪和回流 兩者的區別重繪和回流的屬性如何減少重繪和回流，提高渲染性能。

HTTP方面

• HTTP緩存 強緩存 HTTP/1.1 Cache-ControlHTTP/1.0 ExpiresCache-Control > Expires 協商緩存 HTTP/1.1 ETag/If-None-MatchHTTP/1.0 Last-Modified/If-Modified-Since精準度：ETag > Last-Modified性能：Last-Modified > ETag。

TCP/IP 連接 三次握手、四次揮手

• 網絡層面的性能優化 HTTP/1.1的做法HTTP/2 的做法HTTP/3 的做法每個階段采用的性能優化是有所不同的。