這題扎眼看上去沒問題，無非是 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緩存方面的知識可以看看這篇——面試?？停篐TTP 緩存。
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?？蛻舳耸盏胶蠓祷豠ck=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)?；亓骱椭乩L 回流：意味著元件的幾何尺寸變了，需要重新驗證并計算 Render Tree重繪：屏幕的一部分需要重畫，比如某個CSS 的背景色變了，但元件的幾何尺寸沒有變回流的成本要比重繪大。繪制最后通過操作系統(瀏覽器)的Native GUI的API繪制。其中，衍生出重繪和回流的問題，提高性能的方法之一就是減少瀏覽器的渲染時間，其中的一個優化點就是減少重繪和回流。
減少回流和重繪的方法不要一條條修改 DOM 樣式，與其這樣，不如預定義好CSS的class，然后修改DOM的樣式。把DOM“離線”后修改 使用 documentFragment 對象在內存里操作 DOM先把 DOM 給 display：none(有一次 。Reflow)，然后你想怎么改就怎么改，再把它顯示出來clone 一個 DOM 節點到內存里，然后想怎么改就怎么改，改完后和在線的那個交換一下。不要把 DOM 節點的屬性值放在一個循環中當作循環的變量，不然這會導致大量地讀寫這個節點的屬性盡可能地修改層級比較低的DOM。不要使用 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 的做法每個階段采用的性能優化是有所不同的。X 關閉
X 關閉