http請求到響應經歷的階段 瀏覽器的一個請求從發送到返回都經歷了什麼？

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

 

 

瀏覽器輸入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