URL到頁面到底經歷了什麼(詳細版)

URL到頁面到底經歷了什麼

  • 本文主要在整理概括
  • 圖片均來源於網絡
  • 不足之處,請留言補充

1. 遊覽器查看緩存

圖片描述
圖片描述

2. 瀏覽器解析URL獲取協議,主機,端口,path

  • URL是啥?css

    scheme://host.domain:port/path/filename?
    • scheme: 協議,常見的有 http、https、ftp、file
    • domain:域名,經過域名操做服務器IP
    • port: 端口號
    • path: 路徑
    • filename: 定義文檔/資源的名稱
    • ?:後接查詢參數等

3. DNS解析

  • 即域名解析,由於瀏覽器並不能直接經過域名找到對應的服務器,而是要經過 IP 地址。從域名找到IP的過程就是DNS解析
  1. 遊覽器首發搜索的自身的DNS緩存html

    • 遊覽器會將DNS解析的IP與域名緩存起來,減小網絡請求的損耗。
    • 每一個遊覽器的緩存時間不同,chrome爲60s、IE爲30min、Firefox爲60s
  2. 若遊覽器沒有,則搜索操做系統中的DNS緩存chrome

  3. 若沒有,則搜索操做系統的hosts文件瀏覽器

  4. 路由緩存:路由器也有 DNS 緩存。緩存

  5. ISP 的 DNS 服務器:ISP 是互聯網服務提供商(Internet Service Provider)的簡稱,ISP 有專門的 DNS 服務器應對 DNS 查詢請求安全

  6. 根服務器:ISP 的 DNS 服務器還找不到的話,它就會向根服務器發出請求,進行遞歸查詢(DNS 服務器先問根域名服務器.com 域名服務器的 IP 地址,而後再問.baidu 域名服務器,依次類推)

  • 額外說明:DNS prefetch (遊覽器DNS預解析)服務器

    • 根據瀏覽器定義的規則,提早解析以後可能會用到的域名,使解析結果緩存到系統緩存中,縮短DNS解析時間,來提升網站的訪問速度。
    • 現代瀏覽器在 DNS Prefetch 上作了兩項工做:
    1. html 源碼下載完成後,會解析頁面的包含連接的標籤,提早查詢對應的域名網絡

    2. 對於訪問過的頁面,瀏覽器會記錄一份域名列表,當再次打開時,會在 html 下載的同時去解析 DNSdom

    • 分爲兩種:socket

      自動解析:

      瀏覽器使用超連接的href屬性來查找要預解析的主機名。當遇到a標籤,瀏覽器會自動將href中的域名解析爲IP地址,這個解析過程是與用戶瀏覽網頁並行處理的。可是爲了確保安全性,在HTTPS頁面中不會自動解析

      手動解析:

      經過link
          <link rel="dns-prefetch" href="www.baidu.com">
              
          在HTTPS頁面開啓自動解析功能時
          <meta http-equiv="x-dns-prefetch-control" content="on">
              
          在HTTP頁面關閉自動解析功能時
          <meta http-equiv="x-dns-prefetch-control" content="off">

4. 打開一個socket與目標IP地址,端口創建TCP連接(三次握手)

  • 在《計算機網絡》一書中其中有提到,三次握手的目的是「爲了防止已經失效的鏈接請求報文段忽然又傳到服務端,於是產生錯誤」
SYN:synchronous創建聯機

ACK:acknowledgement 確認

1. 第一次握手:客戶端發送一個SYN=1,seq=x(x是隨機數字的意思)的數據包,服務器看到咱們發過來數據包,就知道你要跟他創建連接

2. 第二次握手:服務器發給咱們一個SYN=1,seq=y,ACK=x+1。服務器發送前兩個數據是爲了確認本身的發消息能力,第三個數據在咱們的seq上加1,以確認創建的是同一個連接。

3. 第三次握手:咱們只須要向服務器發送一個ACK=y+1,服務器即可以確認本身的發送能力了。

圖片描述

5. 開始發送 HTTP 請求報文

圖片描述

第一部分:請求行(請求資源地址)

POST /examples/default.jsp HTTP/1.1

/*
 * POST(Method 請求方法)
 * /examples/default.jsp(URI:Uniform Resource Identifier 統一資源標識符)
 * HTTP(Protocol 協議)/1.1(Version 版本)
 */


第二部分:請求頭(Request headers)

Accept: text/plain; text/html 

請求頭包含請求的附加信息,由關鍵字/值對組成,每行一對,關鍵字和值用英文冒號「:」分隔


第三部分:第三部分:請求體(Entity body)

lastName=Franks&firstName=Michael

6. 服務器處理請求並返回 HTTP 報文

6.1 服務器

服務器是網絡環境中的高性能計算機,它偵聽網絡上的其餘計算機(客戶機)提交的服務請求,並提供相應的服務.

6.2 MVC 後臺處理階段

6.3 http 響應報文

圖片描述

第一部分:響應行

HTTP/1.1 200 OK

/*
 * HTTP(Protocol 協議)/1.1(Version 版本)
 * 200(Status code)
 * OK(Description)
 */

第二部分:響應頭

Server: Microsoft-IIS/4.0  
Date: Mon, 5 Jan 2004 13:13:33 GMT  
Content-Type: text/html  
Last-Modified: Mon, 5 Jan 2004 13:13:12 GMT  
Content-Length: 112
....

第三部分:響應體

<html>
   <head></head>  
    <body>
        ....
   </body>
</html>

7. 瀏覽器解析渲染頁面

圖片描述

7.1 根據 HTML 解析 DOM 樹

根據 HTML 的內容,將標籤按照結構解析成爲 DOM 樹,DOM 樹解析的過程是一個深度優先遍歷。即先構建當前節點的全部子節點,再構建下一個兄弟節點。
在讀取 HTML 文檔,構建 DOM 樹的過程當中,若遇到 script 標籤,則 DOM 樹的構建會暫停,直至腳本執行完畢。

7.2 根據 CSS 解析生成 CSS 規則樹

解析 CSS 規則樹時 js 執行將暫停,直至 CSS 規則樹就緒。
瀏覽器在 CSS 規則樹生成以前不會進行渲染。

7.3 結合 DOM 樹和 CSS 規則樹,生成渲染樹

  • DOM樹 和 css 樹解析爲並行,兩者所有完成後纔會結合生成渲染樹

DOM 樹和 CSS 規則樹所有準備好了之後,瀏覽器纔會開始構建渲染樹。
精簡 CSS 並能夠加快 CSS 規則樹的構建,從而加快頁面相應速度。

7.4 根據渲染樹計算每個節點的信息(佈局)

佈局:經過渲染樹中渲染對象的信息,計算出每個渲染對象的位置和尺寸
迴流:在佈局完成後,發現了某個部分發生了變化影響了佈局,那就須要倒回去從新渲染。

7.5 根據計算好的信息繪製頁面

繪製階段,系統會遍歷呈現樹,並調用呈現器的「paint」方法,將呈現器的內容顯示在屏幕上。
重繪:某個元素的背景顏色,文字顏色等,不影響元素周圍或內部佈局的屬性,將只會引發瀏覽器的重繪。
迴流:某個元素的尺寸發生了變化,則需從新計算渲染樹,從新渲染。

8. 斷開鏈接(四次揮手)

  • 接收完畢後斷開連接

圖片描述

1)客戶端進程發出鏈接釋放報文,而且中止發送數據。釋放數據報文首部,FIN=1,其序列號爲seq=u(等於前面已經傳送過來的數據的最後一個字節的序號加1),此時,客戶端進入FIN-WAIT-1(終止等待1)狀態。 TCP規定,FIN報文段即便不攜帶數據,也要消耗一個序號。

2)服務器收到鏈接釋放報文,發出確認報文,ACK=1,ack=u+1,而且帶上本身的序列號seq=v,此時,服務端就進入了CLOSE-WAIT(關閉等待)狀態。TCP服務器通知高層的應用進程,客戶端向服務器的方向就釋放了,這時候處於半關閉狀態,即客戶端已經沒有數據要發送了,可是服務器若發送數據,客戶端依然要接受。這個狀態還要持續一段時間,也就是整個CLOSE-WAIT狀態持續的時間。

3)客戶端收到服務器的確認請求後,此時,客戶端就進入FIN-WAIT-2(終止等待2)狀態,等待服務器發送鏈接釋放報文(在這以前還須要接受服務器發送的最後的數據)。

4)服務器將最後的數據發送完畢後,就向客戶端發送鏈接釋放報文,FIN=1,ack=u+1,因爲在半關閉狀態,服務器極可能又發送了一些數據,假定此時的序列號爲seq=w,此時,服務器就進入了LAST-ACK(最後確認)狀態,等待客戶端的確認。

5)客戶端收到服務器的鏈接釋放報文後,必須發出確認,ACK=1,ack=w+1,而本身的序列號是seq=u+1,此時,客戶端就進入了TIME-WAIT(時間等待)狀態。注意此時TCP鏈接尚未釋放,必須通過2∗∗MSL(最長報文段壽命)的時間後,當客戶端撤銷相應的TCB後,才進入CLOSED狀態。

6)服務器只要收到了客戶端發出的確認,當即進入CLOSED狀態。一樣,撤銷TCB後,就結束了此次的TCP鏈接。能夠看到,服務器結束TCP鏈接的時間要比客戶端早一些。

參考

https://mp.weixin.qq.com/s/Ln...

http://blog.poetries.top/FE-I...

相關文章
相關標籤/搜索