http請求頭

1. document.referrer 與 Request Headers的refere

Request Headers上referer當前頁面的地址欄。

而當前的頁面的上一個頁面 document.referrer，並不必定是當前頁面的url

 

 2.瀏覽器緩存

關於Pragma:no-cache，跟Cache-Control: no-cache相同。

Pragma: no-cache兼容http 1.0 ，Cache-Control: no-cache是http 1.1提供的。

所以，Pragma: no-cache能夠應用到http 1.0 和http 1.1，而Cache-Control: no-cache只能應用於http 1.1.

 

瀏覽器緩存主要有兩類:緩存協商和完全緩存,也有稱之爲協商緩存和強緩存。

1.強緩存:不會向服務器發送請求,直接從緩存中讀取資源,在chrome控制檯的network選項中能夠看到該請求返回200的狀態碼;

2.協商緩存:向服務器發送請求,服務器會根據這個請求的request header的一些參數來判斷是否命中協商緩存,若是命中,則返回304狀態碼並帶上新的response header通知瀏覽器從緩存中讀取資源;

二者的共同點是,都是從客戶端緩存中讀取資源;區別是強緩存不會發請求,協商緩存會發請求。

 

 

強制緩存

 

Expires:response header裏的過時時間,瀏覽器再次加載資源時,若是在這個過時時間內,則命中強緩存。

Cache-Control:當值設爲max-age=300時,則表明在這個請求正確返回時間(瀏覽器也會記錄下來)的5分鐘內再次加載資源,就會命中強緩存。

cache-control除了該字段外,還有下面幾個比較經常使用的設置值:

-no-cache:不使用本地緩存。須要使用緩存協商,先與服務器確認返回的響應是否被更改,若是以前的響應中存在ETag,那麼請求的時候會與服務端驗證,若是資源未被更改,則能夠避免從新下載。

-no-store:直接禁止瀏覽器緩存數據,每次用戶請求該資源,都會向服務器發送一個請求,每次都會下載完整的資源。

-public:能夠被全部的用戶緩存,包括終端用戶和CDN等中間代理服務器。

-private:只能被終端用戶的瀏覽器緩存,不容許CDN等中繼緩存服務器對其緩存。

 

 

Cache-Control僅指定了max-age,因此默認爲private,緩存時間爲31536000秒(365天)也就是說,在365天內再次請求這條數據,都會直接獲取緩存數據庫中的數據,直接使用。

 

沒懂的話,咱們換通俗一點的話來講一遍。當客戶端第一次訪問資源的時候,服務端在返回資源內容的同時也返回了Expires: Sun, 16 Oct 2016 05:43:02 GMT。

 

服務端告訴瀏覽器: 你Y的先把這個文件給我緩存起來,在這個過時時間以前,這個文件都不會變化了,你下次須要這個文件的時候,你就不要過來找我要了,你就去緩存中拿就行了,又快又好。

 

瀏覽器回答說:諾。

 

因而在第二次html頁面中又要訪問這個資源的時候,而且訪問的日期在Sun, 16 Oct 2016 05:43:02 GMT以前,瀏覽器就不去服務器那邊獲取文件了,本身從緩存中自食其力了。

 

可是呢,瀏覽器畢竟是在客戶端的,客戶端的時間但是不許確的,用戶能夠隨着本身的喜愛修改本身機器的時間,好比我把我機器的時間調成Sun, 16 Oct 2016 05:43:03 GMT,那麼呢?個人瀏覽器就不會再使用緩存了,而每次都去服務器獲取文件。因而,服務器怒了:給你個絕對時間,你因爲環境被修改無法判斷過時,那麼我就給你相對時間吧。因而就返回了Cache-Control: max-age:600,瀏覽器你給我緩存個10分鐘去。因而瀏覽器只有乖乖的緩存10分鐘了。

 

可是問題又來了,若是有的服務器同時設置了Expires和Cache-Control怎麼辦呢?(不是閒的沒事幹,而是因爲Cache-Controll是HTTP1.1中才有的)那麼就是根據更先進的設置Cache-Control來爲標準。

 

好了,如今有個問題,我有個文件可能時不時會更新,服務端很是但願客戶端能時不時過來問一下這個文件是否過時,若是沒有過時,服務端不返回數據給你,只告訴瀏覽器你的緩存尚未過時(304)。而後瀏覽器使用本身存儲的緩存來作顯示。這個就叫作條件請求。

 

 

 

協商緩存

 

Last-Modify/If-Modify-Since:瀏覽器第一次請求一個資源的時候,服務器返回的header中會加上Last-Modify,Last-modify是一個時間標識該資源的最後修改時間;當瀏覽器再次請求該資源時,request的請求頭中會包含If-Modify-Since,該值爲緩存以前返回的Last-Modify。服務器收到If-Modify-Since後,根據資源的最後修改時間判斷是否命中緩存

Etag:web服務器響應請求時,告訴瀏覽器當前資源在服務器的惟一標識(生成規則由服務器決定)。

If-None-Match:當資源過時時(使用Cache-Control標識的max-age),發現資源具備Etage聲明,則再次向web服務器請求時帶上頭If-None-Match (Etag的值)。web服務器收到請求後發現有頭If-None-Match 則與被請求資源的相應校驗串進行比對,決定是否命中協商緩存;

ETag和Last-Modified的做用和用法,他們的區別:

1.Etag要優於Last-Modified。Last-Modified的時間單位是秒,若是某個文件在1秒內改變了屢次,那麼他們的Last-Modified其實並無體現出來修改,可是Etag每次都會改變確保了精度;

2.在性能上,Etag要遜於Last-Modified,畢竟Last-Modified只須要記錄時間,而Etag須要服務器經過算法來計算出一個hash值;

3.在優先級上,服務器校驗優先考慮Etag。

 

瀏覽器緩存過程

1.瀏覽器第一次加載資源,服務器返回200,瀏覽器將資源文件從服務器上請求下載下來,並把response header及該請求的返回時間一併緩存;

2.下一次加載資源時,先比較當前時間和上一次返回200時的時間差,若是沒有超過cache-control設置的max-age,則沒有過時,命中強緩存,不發請求直接從本地緩存讀取該文件(若是瀏覽器不支持HTTP1.1,則用expires判斷是否過時);若是時間過時,則向服務器發送header帶有If-None-Match和If-Modified-Since的請求

3.服務器收到請求後,優先根據Etag的值判斷被請求的文件有沒有作修改,Etag值一致則沒有修改,命中協商緩存,返回304;若是不一致則有改動,直接返回新的資源文件帶上新的Etag值並返回200;;

4.若是服務器收到的請求沒有Etag值,則將If-Modified-Since和被請求文件的最後修改時間作比對,一致則命中協商緩存,返回304;不一致則返回新的last-modified和文件並返回200;

 

 

瀏覽器中寫地址,回車 

F5 

Ctrl+F5

假設對一個資源:

 

瀏覽器第一次訪問,獲取資源內容和cache-control: max-age:600,Last_Modify: Wed, 10 Aug 2013 15:32:18 GMT因而瀏覽器把資源文件放到緩存中,而且決定下次使用的時候直接去緩存中取了。

 

瀏覽器url回車

瀏覽器發現緩存中有這個文件了,好了,就不發送任何請求了,直接去緩存中獲取展示。(最快)

 

下面我按下了F5刷新

F5就是告訴瀏覽器,別偷懶,好歹去服務器看看這個文件是否有過時了。因而瀏覽器就膽膽襟襟的發送一個請求帶上If-Modify-since:Wed, 10 Aug 2013 15:32:18 GMT

 

而後服務器發現:誒,這個文件我在這個時間後還沒修改過,不須要給你任何信息了,返回304就好了。因而瀏覽器獲取到304後就去緩存中歡歡喜喜獲取資源了。

 

按下了Ctrl+F5

這個但是要命了,告訴瀏覽器,你先把你緩存中的這個文件給我刪了,而後再去服務器請求個完整的資源文件下來。因而客戶端就完成了強行更新的操做...

 

 

 參考自：

https://www.aliyun.com/jiaocheng/980241.html?spm=5176.100033.2.22.69fb11ea0MUI4K

https://www.aliyun.com/jiaocheng/980412.html?spm=5176.100033.2.23.69fb11eaDVwhXr