在瀏覽器位址列輸入URL之後發生了什麼？

在瀏覽器位址列輸入url之後發生了什麼？eg：www.baidu.com

https:由於安全隱患，會使用 hsts 強制客戶端使用 https 訪問頁面。

其它操作：瀏覽器還會進行一些額外的操作，比如安全檢查、訪問限制（之前國產瀏覽器限制 996.icu）。

先查詢瀏覽器快取（即瀏覽器裡的書籤和歷史記錄），如果有就直接推給你

查詢系統快取（即本地hosts檔案），如果hosts檔案中有指定ip就解析這個ip位址

查詢本地dns伺服器。本地dns伺服器會先查詢快取，如果快取中存在就返回ip，如果沒有本地dns就向根dns伺服器發起請求。

根dns伺服器不會儲存網域名稱和ip的對應關係，而是告訴本地dns可以去.com域伺服器上查詢，而且會給.com出域伺服器的位址。

域伺服器上同樣也不會儲存網域名稱和ip的對應關係，而是告訴本地dns可以去網域名稱解析伺服器上查詢，會給出網域名稱解析伺服器的位址。

最後，本地dns想網域名稱解析伺服器發起請求，最終就會得到該網域名稱對應的ip位址。本地dns在獲取到ip位址之後，不光會返回到瀏覽器裡，還會儲存在快取中，下次就可以直接在快取中讀取。

擴充套件：dns劫持

三次握手建立鏈結，即客戶端傳送鏈結請求，服務端收到請求後返回給客戶端，最後客戶端在回傳乙個資料給服務端。三次握手之所以要鏈結三次，就是為了保證客戶端和服務端既能保證自己能正常傳送訊息，又能確保對方能正常收到資訊。

如圖所示：

客戶端傳送乙個帶有syn標誌的資料報給服務端，服務端收到後，回傳乙個帶有syn/ack標誌的資料報以示傳達確認資訊，最後客戶端再回傳乙個帶ack標誌的資料報，代表握手結束，連線成功。

通俗點理解三次握手：

服務端：好的，同意了

客戶端：好嘞

建立tcp連線之後，發起http請求，請求一般分為三部分

請求方法uri協議/版本

請求頭(request header)

請求正文

下面是完整的請求示意圖：

擴充套件：https請求

伺服器端收到請求後的由web伺服器（準確說應該是http伺服器）處理請求，諸如apache、ngnix、iis等。web伺服器解析使用者請求，知道了需要排程哪些資源檔案，再通過相應的這些資源檔案處理使用者請求和引數，並呼叫資料庫資訊，最後將結果通過web伺服器返回給瀏覽器客戶端。

如圖所示：

為了避免伺服器與客戶端雙方的資源占用和損耗，當雙方沒有請求或響應傳遞時，任意一方都可以發起關閉請求。與建立tcp連線的3次握手類似，關閉tcp連線，需要4次握手。

通俗點理解四次握手：

服務端：好的，接收到了，我看看我這邊還有沒有要傳的

服務端：我這邊也沒有了，關閉吧

客戶端：好嘞

對於獲取到的html、css、js、等等資源。

瀏覽器通過解析html，生成dom樹，解析css，生成css規則樹，然後通過dom樹和css規則樹生成渲染樹。渲染樹與dom樹不同，渲染樹中並沒有head、display為none等不必顯示的節點。

在解析css的同時，可以繼續載入解析html，但在解析執行js指令碼時，會停止解析後續html，這就會出現阻塞問題，關於js阻塞相關問題，這裡不過多闡述。

根據渲染樹布局，計算css樣式，即每個節點在頁面中的大小和位置等幾何資訊。

html預設是流式布局的，css和js會打破這種布局，改變dom的外觀樣式以及大小和位置。這時就要提到兩個重要概念：repaint和reflow。

repaint：螢幕的一部分重畫，不影響整體布局，比如某個css的背景色變了，但元素的幾何尺寸和位置不變。

eflow：意味著元件的幾何尺寸變了，我們需要重新驗證並計算渲染樹。是渲染樹的一部分或全部發生了變化。這就是reflow，或是layout。

有些情況下，比如修改了元素的樣式，瀏覽器並不會立刻 reflow 或 repaint 一次，而是會把這樣的操作積攢一批，然後做一次 reflow，這又叫非同步 reflow 或增量非同步 reflow。

有些情況下，比如 resize 視窗，改變了頁面預設的字型等。對於這些操作，瀏覽器會馬上進行 reflow。

此答案參考文章：