瀏覽器的一個請求從傳送到返回都經歷了什麼？

    瀏覽器輸入url經歷圖 分析過程： 1.使用者輸入url，瀏覽器內部程式碼將url進行拆分解析 url解析圖   2.瀏覽器首先去找本地的hosts檔案，檢查在該檔案中是否有相應的域名、IP對應關係，如果有，則向其IP地址傳送請求，如果沒有就會將domain（域）傳送給 dns（域名伺服器）進行解析（解析如下圖），將域名解析成對應的伺服器IP地址，發回給瀏覽器   DNS解析domian過程圖 註釋：（結合上圖看） 瀏覽器客戶端向本地DNS伺服器傳送一個含有域名www.cnblogs.com的DNS查詢報文。 本地DNS伺服器把查詢報文轉發到根DNS伺服器，根DNS伺服器注意到其com字尾，於是向本地DNS伺服器返回comDNS伺服器的IP地址。 本地DNS伺服器再次向comDNS伺服器傳送查詢請求，comDNS伺服器注意到其www.cnblogs.com字尾並用負責該域名的權威DNS伺服器的IP地址作為迴應。 最後，本地DNS伺服器將含有www.cnblogs.com的IP地址的響應報文傳送給客戶端。   3.瀏覽器費了一頓周折終於拿到了伺服器IP，接下來就是網路通訊（過程如下圖），分層由高到低分別為：應用層、傳輸層、網路層、資料鏈路層。傳送端從應用層往下走，接收端從資料鏈路層往上走 首先：應用層客戶端傳送HTTP請求 HTTP請求包括請求報頭和請求主體兩個部分，其中請求報頭包含了至關重要的資訊，包括請求的方法（GET / POST）、目標url、遵循的協議（http / https / ftp…），返回的資訊是否需要快取，以及客戶端是否傳送cookie等。 請求報文   然後：傳輸層TCP傳輸報文    位於傳輸層的TCP協議為傳輸報文提供可靠的位元組流服務。它為了方便傳輸，將大塊的資料分割成以報文段為單位的資料包進行管理，併為它們編號，方便伺服器接收時能準確地還原報文資訊。TCP協議通過“三次握手”等方法保證傳輸的安全可靠。 客戶端傳送一個帶有SYN標誌的資料包給服務端，在一定的延遲時間內等待接收的回覆。服務端收到後，回傳一個帶有SYN/ACK標誌的資料包以示傳達確認資訊，最後客戶端再回傳一個帶ACK標誌的資料包，代表握手結束，連線成功。   SYN （Synchronize Sequence Numbers）同步序列編號 ACK  (Acknowledgement）確認字元   下圖也可以這麼理解： 客戶端：“你好，在家不，有你快遞。”---SYN 服務端：“在的，送來就行。”-----SYN/ACK 客戶端：“好嘞。”-----ACK   接著：網路層IP協議查詢MAC地址    IP協議的作用是把TCP分割好的各種資料包傳送給接收方。而要保證確實能傳到接收方還需要接收方的MAC地址，也就是實體地址。IP地址和MAC地址是一一對應的關係，一個網路裝置的IP地址可以更換，但是MAC地址一般是固定不變的。ARP協議可以將IP地址解析成對應的MAC地址。當通訊的雙方不在同一個區域網時，需要多次中轉才能到達最終的目標，在中轉的過程中需要通過下一個中轉站的MAC地址來搜尋下一個中轉目標。 資料到達資料鏈路層    在找到對方的MAC地址後，就將資料傳送到資料鏈路層傳輸。這時，客戶端傳送請求的階段結束   再次：伺服器接收資料    接收端的伺服器在鏈路層接收到資料包，再層層向上直到應用層。這過程中包括在運輸層通過TCP協議將分段的資料包重新組成原來的HTTP請求報文。 伺服器響應請求    服務接收到客戶端傳送的HTTP請求後，查詢客戶端請求的資源，並返回響應報文，響應報文中包括一個重要的資訊——狀態碼。狀態碼由三位數字組成， 其中比較常見的是200 OK表示請求成功。 301表示永久重定向，即請求的資源已經永久轉移到新的位置。在返回301狀態碼的同時，響應報文也會附帶重定向的url，客戶端接收到後將http請求的url做相應的改變再重新發送。 404 not found 表示客戶端請求的資源找不到。   最後： 伺服器返回相應檔案     伺服器端收到請求後的由web伺服器（準確說應該是http伺服器）處理請求，諸如Apache、Ngnix、IIS等。web伺服器解析使用者請求，知道了需要排程哪些資原始檔，再通過相應的這些資原始檔處理使用者請求和引數，並呼叫資料庫資訊，最後將結果通過web伺服器返回給瀏覽器客戶端。 伺服器有自己的MVC 結構（如下圖）   關閉TCP連線 為了避免伺服器與客戶端雙方的資源佔用和損耗，當雙方沒有請求或響應傳遞時，任意一方都可以發起關閉請求。與建立TCP連線的3次握手類似，關閉TCP連線，需要4次握手。   4次握手 上圖可以這麼理解： 客戶端：“兄弟，我這邊沒資料要傳了，咱關閉連線吧。”----FIN 服務端：“收到，我看看我這邊有木有資料了。”----ACK 服務端：“兄弟，我這邊也沒資料要傳你了，咱可以關閉連線了。”----FIN 客戶端：“好嘞。”----ACK   4.頁面的渲染階段 流程：

1. 解析HTML生成DOM樹。
2. 解析CSS生成CSSOM規則樹。
3. 將DOM樹與CSSOM規則樹合併在一起生成渲染樹。
4. 遍歷渲染樹開始佈局，計算每個節點的位置大小資訊。
5. 將渲染樹每個節點繪製到螢幕。

    webkit渲染引擎流程   過程的重點：   渲染阻塞 當瀏覽器遇到一個 script 標記時，DOM 構建將暫停，直至指令碼完成執行，然後繼續構建DOM。每次去執行JavaScript指令碼都會嚴重地阻塞DOM樹的構建，如果JavaScript指令碼還操作了CSSOM，而正好這個CSSOM還沒有下載和構建，瀏覽器甚至會延遲指令碼執行和構建DOM，直至完成其CSSOM的下載和構建。 所以，script 標籤的位置很重要。實際使用時，可以遵循下面兩個原則：

CSS 優先：引入順序上，CSS 資源先於 JavaScript 資源。

JS置後：我們通常把JS程式碼放到頁面底部，且JavaScript 應儘量少影響 DOM 的構建。

當解析html的時候，會把新來的元素插入dom樹裡面，同時去查詢css，然後把對應的樣式規則應用到元素上，查詢樣式表是按照從右到左的順序去匹配的。 例如： div p {font-size: 16px}，會先尋找所有p標籤並判斷它的父標籤是否為div之後才會決定要不要採用這個樣式進行渲染）。 所以，我們平時寫CSS時，儘量用id和class，千萬不要過渡層疊。   渲染樹繪製 在繪製階段，遍歷渲染樹，呼叫渲染器的paint()方法在螢幕上顯示其內容。渲染樹的繪製工作是由瀏覽器的UI後端元件完成的。 reflow與repaint： 根據渲染樹佈局，計算CSS樣式，即每個節點在頁面中的大小和位置等幾何資訊。HTML預設是流式佈局的，CSS和js會打破這種佈局，改變DOM的外觀樣式以及大小和位置。這時就要提到兩個重要概念：replaint和reflow。

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

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

所以我們應該儘量減少reflow和replaint，我想這也是為什麼現在很少有用table佈局的原因之一。 display:none 會觸發 reflow，visibility: hidden屬性並不算是不可見屬性，它的語義是隱藏元素，但元素仍然佔據著佈局空間，它會被渲染成一個空框，所以visibility:hidden 只會觸發 repaint，因為沒有發生位置變化。 有些情況下，比如修改了元素的樣式，瀏覽器並不會立刻 reflow 或 repaint 一次，而是會把這樣的操作積攢一批，然後做一次 reflow，這又叫非同步 reflow 或增量非同步 reflow。 有些情況下，比如 resize 視窗，改變了頁面預設的字型等。對於這些操作，瀏覽器會馬上進行 reflow。   參考： https://www.cnblogs.com/webdeve/p/7865520.html https://www.cnblogs.com/kongxy/p/4615226.html   瀏覽器輸入url經歷圖 分析過程： 1.使用者輸入url，瀏覽器內部程式碼將url進行拆分解析 url解析圖   2.瀏覽器首先去找本地的hosts檔案，檢查在該檔案中是否有相應的域名、IP對應關係，如果有，則向其IP地址傳送請求，如果沒有就會將domain（域）傳送給 dns（域名伺服器）進行解析（解析如下圖），將域名解析成對應的伺服器IP地址，發回給瀏覽器   DNS解析domian過程圖 註釋：（結合上圖看） 瀏覽器客戶端向本地DNS伺服器傳送一個含有域名www.cnblogs.com的DNS查詢報文。 本地DNS伺服器把查詢報文轉發到根DNS伺服器，根DNS伺服器注意到其com字尾，於是向本地DNS伺服器返回comDNS伺服器的IP地址。 本地DNS伺服器再次向comDNS伺服器傳送查詢請求，comDNS伺服器注意到其www.cnblogs.com字尾並用負責該域名的權威DNS伺服器的IP地址作為迴應。 最後，本地DNS伺服器將含有www.cnblogs.com的IP地址的響應報文傳送給客戶端。   3.瀏覽器費了一頓周折終於拿到了伺服器IP，接下來就是網路通訊（過程如下圖），分層由高到低分別為：應用層、傳輸層、網路層、資料鏈路層。傳送端從應用層往下走，接收端從資料鏈路層往上走 首先：應用層客戶端傳送HTTP請求 HTTP請求包括請求報頭和請求主體兩個部分，其中請求報頭包含了至關重要的資訊，包括請求的方法（GET / POST）、目標url、遵循的協議（http / https / ftp…），返回的資訊是否需要快取，以及客戶端是否傳送cookie等。 請求報文   然後：傳輸層TCP傳輸報文    位於傳輸層的TCP協議為傳輸報文提供可靠的位元組流服務。它為了方便傳輸，將大塊的資料分割成以報文段為單位的資料包進行管理，併為它們編號，方便伺服器接收時能準確地還原報文資訊。TCP協議通過“三次握手”等方法保證傳輸的安全可靠。 客戶端傳送一個帶有SYN標誌的資料包給服務端，在一定的延遲時間內等待接收的回覆。服務端收到後，回傳一個帶有SYN/ACK標誌的資料包以示傳達確認資訊，最後客戶端再回傳一個帶ACK標誌的資料包，代表握手結束，連線成功。   SYN （Synchronize Sequence Numbers）同步序列編號 ACK  (Acknowledgement）確認字元   下圖也可以這麼理解： 客戶端：“你好，在家不，有你快遞。”---SYN 服務端：“在的，送來就行。”-----SYN/ACK 客戶端：“好嘞。”-----ACK   接著：網路層IP協議查詢MAC地址    IP協議的作用是把TCP分割好的各種資料包傳送給接收方。而要保證確實能傳到接收方還需要接收方的MAC地址，也就是實體地址。IP地址和MAC地址是一一對應的關係，一個網路裝置的IP地址可以更換，但是MAC地址一般是固定不變的。ARP協議可以將IP地址解析成對應的MAC地址。當通訊的雙方不在同一個區域網時，需要多次中轉才能到達最終的目標，在中轉的過程中需要通過下一個中轉站的MAC地址來搜尋下一個中轉目標。 資料到達資料鏈路層    在找到對方的MAC地址後，就將資料傳送到資料鏈路層傳輸。這時，客戶端傳送請求的階段結束   再次：伺服器接收資料    接收端的伺服器在鏈路層接收到資料包，再層層向上直到應用層。這過程中包括在運輸層通過TCP協議將分段的資料包重新組成原來的HTTP請求報文。 伺服器響應請求    服務接收到客戶端傳送的HTTP請求後，查詢客戶端請求的資源，並返回響應報文，響應報文中包括一個重要的資訊——狀態碼。狀態碼由三位數字組成， 其中比較常見的是200 OK表示請求成功。 301表示永久重定向，即請求的資源已經永久轉移到新的位置。在返回301狀態碼的同時，響應報文也會附帶重定向的url，客戶端接收到後將http請求的url做相應的改變再重新發送。 404 not found 表示客戶端請求的資源找不到。   最後： 伺服器返回相應檔案     伺服器端收到請求後的由web伺服器（準確說應該是http伺服器）處理請求，諸如Apache、Ngnix、IIS等。web伺服器解析使用者請求，知道了需要排程哪些資原始檔，再通過相應的這些資原始檔處理使用者請求和引數，並呼叫資料庫資訊，最後將結果通過web伺服器返回給瀏覽器客戶端。 伺服器有自己的MVC 結構（如下圖）   關閉TCP連線 為了避免伺服器與客戶端雙方的資源佔用和損耗，當雙方沒有請求或響應傳遞時，任意一方都可以發起關閉請求。與建立TCP連線的3次握手類似，關閉TCP連線，需要4次握手。   4次握手 上圖可以這麼理解： 客戶端：“兄弟，我這邊沒資料要傳了，咱關閉連線吧。”----FIN 服務端：“收到，我看看我這邊有木有資料了。”----ACK 服務端：“兄弟，我這邊也沒資料要傳你了，咱可以關閉連線了。”----FIN 客戶端：“好嘞。”----ACK   4.頁面的渲染階段 流程：

1. 解析HTML生成DOM樹。
2. 解析CSS生成CSSOM規則樹。
3. 將DOM樹與CSSOM規則樹合併在一起生成渲染樹。
4. 遍歷渲染樹開始佈局，計算每個節點的位置大小資訊。
5. 將渲染樹每個節點繪製到螢幕。

    webkit渲染引擎流程   過程的重點：   渲染阻塞 當瀏覽器遇到一個 script 標記時，DOM 構建將暫停，直至指令碼完成執行，然後繼續構建DOM。每次去執行JavaScript指令碼都會嚴重地阻塞DOM樹的構建，如果JavaScript指令碼還操作了CSSOM，而正好這個CSSOM還沒有下載和構建，瀏覽器甚至會延遲指令碼執行和構建DOM，直至完成其CSSOM的下載和構建。 所以，script 標籤的位置很重要。實際使用時，可以遵循下面兩個原則：

CSS 優先：引入順序上，CSS 資源先於 JavaScript 資源。

JS置後：我們通常把JS程式碼放到頁面底部，且JavaScript 應儘量少影響 DOM 的構建。

當解析html的時候，會把新來的元素插入dom樹裡面，同時去查詢css，然後把對應的樣式規則應用到元素上，查詢樣式表是按照從右到左的順序去匹配的。 例如： div p {font-size: 16px}，會先尋找所有p標籤並判斷它的父標籤是否為div之後才會決定要不要採用這個樣式進行渲染）。 所以，我們平時寫CSS時，儘量用id和class，千萬不要過渡層疊。   渲染樹繪製 在繪製階段，遍歷渲染樹，呼叫渲染器的paint()方法在螢幕上顯示其內容。渲染樹的繪製工作是由瀏覽器的UI後端元件完成的。 reflow與repaint： 根據渲染樹佈局，計算CSS樣式，即每個節點在頁面中的大小和位置等幾何資訊。HTML預設是流式佈局的，CSS和js會打破這種佈局，改變DOM的外觀樣式以及大小和位置。這時就要提到兩個重要概念：replaint和reflow。

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

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

所以我們應該儘量減少reflow和replaint，我想這也是為什麼現在很少有用table佈局的原因之一。 display:none 會觸發 reflow，visibility: hidden屬性並不算是不可見屬性，它的語義是隱藏元素，但元素仍然佔據著佈局空間，它會被渲染成一個空框，所以visibility:hidden 只會觸發 repaint，因為沒有發生位置變化。 有些情況下，比如修改了元素的樣式，瀏覽器並不會立刻 reflow 或 repaint 一次，而是會把這樣的操作積攢一批，然後做一次 reflow，這又叫非同步 reflow 或增量非同步 reflow。 有些情況下，比如 resize 視窗，改變了頁面預設的字型等。對於這些操作，瀏覽器會馬上進行 reflow。   參考： https://www.cnblogs.com/webdeve/p/7865520.html https://www.cnblogs.com/kongxy/p/4615226.html