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

2022.04.28

我想它的執行順序是,用戶輸入——開始導航——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 的做法每個階段採用的性能優化是有所不同的。