圖解從輸入網址到顯示頁面中間發生了什麼

轉自

http://www.findme.wang/blog/detail/id/185.html

 

1、概述

咱們在地址欄中輸入網址，如www.findme.wang，到頁面顯示中間發生了哪些過程呢？查詢緩存、域名解析、三次握手、網絡協議、新鮮度檢查、HTTP協議、GET請求、DOM樹、渲染樹等一連串的關鍵字浮如今腦海中，因而簡要的繪製了一副圖以下： 

2、相關說明

1.瀏覽器如何檢查緩存是否存在

瀏覽器會依據請求的相關信息http header，通過一系列的計算做爲Hash的key值，查詢緩衝是否存在。

2.緩存控制細節

關於緩存，我看有的地方將其分類爲強緩存和協商緩存，其實協商緩存就是對過時的緩衝一種處理方式，感受不必分類。

3.怎樣判斷緩存是否過時

覽器在查找到緩存後，會檢查cache-control 和expires 來判斷緩存是否過時，以下圖。瀏覽器經過比較該值就能判斷緩存是否過時。 

 Expires是老版本的HTTP協議中規定的，返回的是一個絕對時間，在服務器的時間與客戶端的時間相差較大時，緩存管理容易出問題，當客戶端修改本地時間，就會影響緩存命中的結果。因而在http1.1的時候，提出了Cache-Control，這是一個相對時間，在配置緩存的時候，以秒爲單位，用數值表示，如：Cache-Control:max-age=1296000，其參數比較多，能夠參考以下： 瀏覽器緩存機制剖析 

當這兩個屬性Expires和Cache-Control同時存在時，Cache-Control優先級高於Expires。

4.緩存的新鮮度檢查

  當瀏覽器首次向服務器發送請求的時候，服務器響應的http頭部會攜帶，Last-Modified和ETag。 

當緩存過時的時候，瀏覽器就會將該兩個參數的值以If-Modified-Since、If-None-Match形式寫在HTTP頭中，發服務器請求資源。其中If-Modified-Since是與Last-Modified相互對應，If-None-Match與ETag相互對應，。爲了演示，咱們經過下圖方式複製瀏覽器請求 

請求內容以下，有狀態碼304，能夠看出，這是在檢查緩存的新鮮度。複製的請求頭，刪除cookie後的信息以下：

1 2 3 4 5 6 7 8 9 10

GET /Public/Home/css/blog.css HTTP/1.1 Host: www.findme.wang Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Accept: text/css,*/*;q=0.1 Referer: http: //www.findme.wang/Blog/detail/id/181.html Accept-Encoding: gzip, deflate, sdch Accept-Language: zh-CN,zh;q=0.8 If-None-Match:  "b410bb-cdf-54d69e0160e80" If-Modified-Since: Tue, 18 Apr 2017 05:06:50 GMT

在瀏覽器中，經過telnet測試以下：

從上圖，能夠看出，當服務器匹配到相應的資源，且發現資源並無修改的時候，並不會返回資源具體的信息，而是返回304，即資源並無修改。

後期補充

因爲時間限制以及本身對下面一塊瞭解也不是很透徹，須要查閱更多的資源如下內容，將會在後期補充上。 

1. 客戶端與服務器的鏈接與斷開鏈接 

2. 瀏覽器的渲染過程（同時介紹一下rectJS相關內容） 

3. mac地址查詢

 

—-有不對的地方，請各位不吝賜教—-