瀏覽器中輸入URL後會發生什麼事情超級詳細版

這個問題實在是老生常談，甚至是面試必考題之一，

我這裡記錄一下我學習的結果，僅供自己學習

首先要了解的是，乙個瀏覽器是有好多程序的，比如瀏覽器程序、渲染程序、gpu程序、網路程序、外掛程式程序

瀏覽器程序是管理瀏覽器本身的，而渲染程序基本上是乙個標籤頁乙個，那麼為什麼要說基本上呢？可以看 4.7 的內容

gpu程序是在渲染程序的基礎上，對展現的影象進行進一步處理的

網路程序是用來和網路通訊的，而在 chrome 中，乙個標籤頁同一時間只會對同乙個網域名稱維持 6個tcp鏈結，多餘的在這六個連線結束之前只能掛起。所以當請求被放到了三個網域名稱下的話，同時最多會有 18個連線

外掛程式程序是用來專門執行外掛程式的

因為任何輸入都是不可信的，所以渲染程序、外掛程式程序其實都是被放在了乙個沙箱中，禁止訪問系統的私密檔案以及操作

你首先輸入之後，會對你的輸入內容進行檢查，然後根據檢查的結果，去決定是使用搜尋引擎搜尋，還是當作乙個url 資源

所以當瀏覽器認為是乙個 url 資源之後，

瀏覽器程序會給當前的url 加上對應的協議，如 http，cookie，請求頭，當前的 ip，當前服務的埠號等等資訊

瀏覽器程序將完整的 url 資訊推給網路程序

網路程序對該資訊進行命中，如果有快取，則從快取中讀取，沒有的話，繼續

接下來就會進行 dns 服務的解析，這個是通過 udp 的 (瀏覽器會快取這個解析的結果，所以第二次開啟同乙個網頁的時候，會發現快一點的原因，這個佔了一部分)

獲取對應服務的 ip 之後，這個時候才進行 tcp 的三次握手

握手成功發出 http 請求 (http1和 http2 是基於tcp 的)

進行資料報資訊的傳輸，在這個過程中，tcp 會校驗每個包是否都收到，沒有的話進行重發，並且給每個包打上序號標籤，保證資訊的完整，客戶端根據資料報的序號標籤對資料進行整理排序 (所以說為什麼 http3 出現的原因就在這裡了，實在是效率太低。硬生生將資料的傳輸量增加了一倍)

資訊傳輸完之後會第一時間關閉tcp嗎？還真不一定

如果你的請求中帶著 keep-alive 的話，接下來的請求會復用這個tcp連線，省去了三次握手的過程

然後根據之前包裝的服務埠號等資訊定位到對應的應用中

首先，會檢查響應頭是什麼，然後會檢查 content-type

如果是 301 或者 302 ，那麼重新進行第二大點的內容

如果是 304 ，也就是說伺服器告訴瀏覽器資料沒有過期，繼續從快取拿

還有其他的，我也不多說(其實我也一知半解)

接著是前端都喜歡的 200 了，你以為 200 就結束了？

咱們進入 text/html 中

渲染程序又會分為好幾個執行緒，比如常說的 js 執行緒

這個時候會給前端開發者乙個最後掙扎的機會：beforeunload，比如還有東西沒有儲存，是否離開之類的。如果選擇否，則不進行接下來的操作

如果使用者選了確定，開始解析，則會替換之前的頁面 (所以直到這一步之前，之前的頁面都是保留著的！！)

瀏覽器並不能直接識別 html 和 css，所以需要解析這一部分，生成兩棵樹

具體樹的結構可以在控制台輸出 document 獲得 dom 樹，以及 document.stylesheets 獲得 css 的樹

在css樹中，其實瀏覽器是不能直接使用類似於 color： red 這樣的屬性的，會轉化為 color：rgb(255, 0,0)，也不能識別 rem，會轉化為對應的 px，等等

接下來的解析過程不多說，其他的資料有很多，但是要注意的是，渲染樹中其實不包含那些不可見的東西，比如 display：none

需要注意的是，如果你是從乙個頁面中開啟的另乙個頁面，瀏覽器會判斷當前 url 中的網域名稱是否是和之前的是同乙個，是的話，則共用上乙個頁面的渲染程序 (所以會出現一掛掛好幾個的現象)

全部資料都處理好了之後，會將渲染的樹推到瀏覽器本身

然後瀏覽器會將這些渲染的指令進行光柵化去渲染，部分交給 gpu 程序進行渲染

而在執行過程當中，如果js 中有 generator ，就又會生成單獨的協程來進行控制權的移交

瀏覽器中輸入URL後會發生什麼事情 超級詳細版