網紅面試題：從輸入 Url 到看到頁面發生了什麼

我想它的執行順序是，用戶輸入——開始導航——HTTP請求——瀏覽器渲染。其中用戶輸入、開始導航、瀏覽器渲染是瀏覽器方面的知識點，HTTP請求是 HTTP 方面的知識點。

前言 了解"開始導航"之前，需要先知道瀏覽器架構，簡單來說，現代瀏覽器由1個瀏覽器主進程、1個GPU進程、多個渲染進程、多個插件進程、網絡進程、音頻進程、存儲進程組成。 下圖是李兵在《瀏覽器工作原理與實踐》中所示，展示 Chrome 瀏覽器的架構。

現代瀏覽器內部解密 圖中表明瀏覽器主進程包含了 UI 線程、網絡線程、存儲線程，與李兵的觀點有所不同。那以誰為準呢?以時間為準，李兵的專欄是19年所寫，而《現代瀏覽器內部解密》是 18 年的文章，站在 2022 年的背景，現代瀏覽器，UI、網絡、存儲等都已升級為進程，而非是瀏覽器主進程中的線程。 用戶輸入 當用戶在地址欄中輸入一個字符串時，地址欄會判斷輸入的關鍵字是搜索內容，還是請求的URL。 如果是搜索內容，地址欄會使用瀏覽器默認的搜索引擎，合成新的帶搜索關鍵字的URL 例如在chrome中搜長澤雅美在chrome中搜長澤雅美。 如果輸入內容符合 URL 規則，例如輸入azhubaby.com，那麼地址欄會根據規則，把這段內容加上協議合成完成的 URL，如 https://azhubaby.com。 當用戶輸入關鍵字並鍵入回車之後，意味著當前頁面將替換為新的頁面，此時瀏覽器中有個 API——beforeunload，它允許頁面在離開之前觸發是否一個確認對話框。這裡使用此API，可讓瀏覽器不再導航。

從瀏覽器架構分工上講，當用戶輸入字符串時是 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 連接時，就聯想到網紅面試題：三次握手、四次揮手。 三次握手、四次揮手 為什麼是三次握手和四次揮手，因為只有這樣才能讓雙方(客戶端和服務端)知道彼此的接收能力和發送能力是沒問題的。

步驟為： 客戶端提出建立連接，發出客戶端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繪製。 其中，衍生出重繪和回流的問題，提高性能的方法之一就是減少瀏覽器的渲染時間，其中的一個優化點就是減少重繪和回流。 減少回流和重繪的方法 不要一條條修改 DOM 樣式，與其這樣，不如預定義好CSS的class，然後修改DOM的樣式。 把DOM“離線”後修改 使用 documentFragment 對像在內存裡操作 DOM先把 DOM 給 display：none(有一次 。 Reflow)，然後你想怎麼改就怎麼改，再把它顯示出來clone 一個 DOM 節點到內存裡，然後想怎麼改就怎麼改，改完後和在線的那個交換一下。 不要把 DOM 節點的屬性值放在一個循環中當作循環的變量，不然這會導致大量地讀寫這個節點的屬性 盡可能地修改層級比較低的DOM。 不要使用 table 佈局。

記住一點，回流是與幾何大小相關，重繪與大小無關。 如此，從輸入 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 的做法每個階段採用的性能優化是有所不同的。