HTTP緩存
- 重用已獲取的資源可以有效的提高網站與應用的性能。Web 緩存可以減小延遲與網絡阻塞,進而減小顯示某個資源所用的時間。藉助 HTTP 緩存,Web 站點變得更具備響應性。
- 緩存是一種保存資源副本並在下次請求時直接使用該副本的技術。當 web 緩存發現請求的資源已經被存儲,它會攔截請求,返回該資源的拷貝,而不會去源服務器從新下載。這樣帶來的好處有:緩解服務器端壓力,提高性能(獲取資源的耗時更短了)。對於網站來講,緩存是達到高性能的重要組成部分。緩存須要合理配置,由於並非全部資源都是永久不變的:重要的是對一個資源的緩存應截止到其下一次發生改變(即不能緩存過時的資源)。
須要緩存的狀況
- 一個檢索請求的成功響應: 對於 GET請求,響應狀態碼爲:200,則表示爲成功。一個包含例如HTML文檔,圖片,或者文件的響應.
- 不變的重定向: 響應狀態碼:301.
- 錯誤響應: 響應狀態碼:404 的一個頁面.
- 不徹底的響應: 響應狀態碼 206,只返回局部的信息.
- 除了 GET 請求外,若是匹配到做爲一個已被定義的cache鍵名的響應.
Cookie
- Cookie(複數形態Cookies),中文名稱爲「小型文本文件」或「小甜餅」,指某些網站爲了辨別用戶身份而儲存在用戶本地終端(Client Side)上的數據(一般通過加密)
- Cookie就像你第一次去夜店,保安(服務器)給了你一個手環,你的手環有效期是24h,你忽然出去接了一個電話,原來是陳浩南叫你去砍人(幹其餘事),而後你忙完了,回來繼續嗨,帶着你的手環給保安(服務器)看了(讀Cookie)就放你進去了,你的每次進出都要看你的手環,Cookie就是你的手環
- Cookie老是保存在客戶端中,按在客戶端中的存儲位置,可分爲內存Cookie和硬盤Cookie。 內存Cookie由瀏覽器維護,保存在內存中,瀏覽器關閉後就消失了,其存在時間是短暫的。硬盤Cookie保存在硬盤裏,是人爲設置的,有一個過時時間,除非用戶手工清理或到了過時時間,硬盤Cookie不會被刪除,其存在時間是長期的。因此,按存在時間,可分爲非持久Cookie和持久Cookie。
Cookie是什麼
- 服務器經過 Set-Cookie 頭給客戶端(瀏覽器)一串字符串
- 瀏覽器獲得Cookie以後,每次請求都帶上Cookie
- 服務器讀取Cookie以後就知道用戶的信息
- Cookie的生命週期默認是你關掉瀏覽器就over,後端能夠強行設置時間,+1s~~~ ,辣麼內存Cookie就變成了硬盤Cookie
- Cookie本質是http協議中的一項內容
- Cookie大小在4k左右
Cookie的缺點
- Cookie會被附加在每一個HTTP請求中,因此無形中增長了流量。
- 因爲在HTTP請求中的Cookie是明文傳遞的,因此安全性成問題,除非用HTTPS。
- Cookie的大小限制在4KB左右,對於複雜的存儲需求來講是不夠用的。
- Cookie不安全,用戶能夠更改
Cookie在那裏
C盤的一個祕密地點,Don't look for me.
css
session
session是什麼
因爲Cookie不安全呀,機智的程序員就想了一個方法,把一個隨機的id和咱們的數據一一對應存放起來,session是一個抽象的東西,是一個數據結構,Cookie保存在客戶端,而session保存在服務器,session的生命週期默認爲20min,也是能夠更改的
html
session-Cookie具體步驟
- 將 SessionID(隨機數)經過 Cookie 發給客戶端
- 客戶端訪問服務器時,服務器讀取 SessionID
- 服務器有一塊硬盤(哈希表)保存了全部 session
- 經過 SessionID 咱們能夠獲得對應用戶的隱私信息,如 id、email
- 這塊硬盤(哈希表)就是服務器上的全部 session
不基於Cookie的session
把sessinID直接傳給前端,用LocalStorage + 查詢參數實現前端
常見面試題
- Cookie和session是什麼關係
- 通常來講,session是基於Cookie實現的,sessionId要存放在cookie中發送給客戶端,Cookie是session的以來
- Cookie和localStorage的區別
- localStorage和sessionStorage區別
- sessionStorage生命週期在用戶關閉(會話結束)頁面後就失效
localStorage
localStorage是什麼
localStroage是html5提供的一個api,它的實質是存放在瀏覽器的一個哈希表{'key':'value'}
,
html5
localStorage在那裏
C盤的一個祕密地點,和硬盤Cookie同樣
程序員
localStorage的api
不用解釋直接都看得懂,這裏介紹常見的幾個寫,讀,刪web
localStorage.setItem('myCat', 'Tom');
var cat = localStorage.getItem("myCat");
localStorage.removeItem("myCat");
複製代碼
localStorage的特色
- localStorage和HTTP無關,
- HTTP請求不會帶上localStorage
- 域名相同才能讀取localStorage(沒有同源辣麼嚴格)
- 每一個域名localStorage最大存儲量爲10M左右(每一個瀏覽器不同,本身測試好吧~)
- 因爲數據存在本地,生命週期爲無限,不用考慮過時的問題.
localStorage經常使用場景
- 記錄不敏感的信息(用戶名之類的,生日,不能記錄密碼)
- 用來提示用戶新的功能(彈出對話框)
sessionStorage
基本內容同localStorage,區別在於SessionStorage在用戶關閉頁面(會話結束)後就失效.面試
HTTP緩存
重複請求很大的文件很影響性能,因而有了不少優化的方案算法
Cache-Control
Cache-Control 通用消息頭被用於在http 請求和響應中經過指定指令來實現緩存機制。緩存指令是單向的, 這意味着在請求設置的指令,在響應中不必定包含相同的指令。後端
緩存靜態資源
當一些靜態的東西,好比js,css,圖像,能夠設置爲靜態緩存api
Cache-Control:public, max-age=315360000 //10年
複製代碼
首頁不能設置緩存,若是你設置了,那麼用戶的得不到最新的響應,不能獲取到你的最新網頁
更新緩存
若是個人js,css等須要更新了,而上面我設置了10年的緩存,那我該怎麼辦?
主要你改變了url,就會從新請求,因此你能夠加上各類查詢參數,改下URL就好
Expires
- Expires是RFC 2616(HTTP/1.0)協議中和網頁緩存相關字段。
- Cache-Control是它的升級版,若是還有一個 設置了 "max-age" 或者 "s-max-age" 指令的Cache-Control響應頭,那麼 Expires 頭就會被忽略。
- Expires 頭指定了一個日期/時間(格林威治時間), 在這個日期/時間以後,HTTP響應被認爲是過期的,這個時間是本地時間
- 詳見mdn
Etag
- 通常把md5放在Etag響應頭中,用來檢測是否須要從新下載緩存等,若是Etag中的md5碼相同,那麼不用從新請求,好比讓狀態碼變爲304,減小服務器負擔,用於性能優化
- ETag HTTP響應頭是資源的特定版本的標識符。這可讓緩存更高效,並節省帶寬,由於若是內容沒有改變,Web服務器不須要發送完整的響應。而若是內容發生了變化,使用ETag有助於防止資源的同時更新相互覆蓋
- 和緩存的區別,緩存是直接不請求,Etag呢,若是
ETag: "<etag_value>"
也就是md5的話,會請求,可是不下載
MD5
- MD5消息摘要算法,一種被普遍使用的密碼散列函數,不是加密算法
- 用來檢驗文件是否一致
lastmodified
- The Last-Modified 是一個響應首部,其中包含源頭服務器認定的資源作出修改的日期及時間。 它一般被用做一個驗證器來判斷接收到的或者存儲的資源是否彼此一致。因爲精確度比 ETag 要低,因此這是一個備用機制
- Last-Modified 響應頭能夠做爲一種弱校驗器。說它弱是由於它只能精確到一秒。若是響應頭裏含有這個信息,客戶端能夠在後續的請求中帶上 If-Modified-Since 來驗證緩存。
- 和Etag的區別:Etag是用md5做爲響應內容的特徵值,而lastmodified是比較響應內容的修改時間
- Etag比lastModified更加嚴謹,若是資源發生變化,Etag就會發生變化,就會把最新的資源給客戶端返回去,而lastModified不識別s(秒)單位裏的修改,因此若是資源在s(秒)單位裏發生了修改,那lastModified也不會發生改變,這樣若是隻用了lastModified,客戶端獲得的資源就不是最新的;可是設定了Etag以後,每次客戶端發出請求,服務端都會根據資源從新生成一個Etag,對性能有影響
因此爲何不用cache-control呢?