HTTP快取

勝天半子bibi醬發表於2018-03-26
HTTP快取

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.

session

session是什麼

由於Cookie不安全呀,機智的程式設計師就想了一個方法,把一個隨機的id和我們的資料一一對應存放起來,session是一個抽象的東西,是一個資料結構,Cookie儲存在客戶端,而session儲存在伺服器，session的生命週期預設為20min,也是可以更改的

session-Cookie具體步驟

  • 將 SessionID（隨機數）通過 Cookie 發給客戶端
  • 客戶端訪問伺服器時，伺服器讀取 SessionID
  • 伺服器有一塊硬碟（雜湊表）儲存了所有 session
  • 通過 SessionID 我們可以得到對應使用者的隱私資訊，如 id、email
  • 這塊硬碟（雜湊表）就是伺服器上的所有 session

不基於Cookie的session

把sessinID直接傳給前端,用LocalStorage + 查詢引數實現

常見面試題

  1. Cookie和session是什麼關係
  • 一般來說,session是基於Cookie實現的,sessionId要存放在cookie中傳送給客戶端,Cookie是session的以來
  1. Cookie和localStorage的區別
  • http請求不會帶著localStorage
  1. localStorage和sessionStorage區別
  • sessionStorage生命週期在使用者關閉(會話結束)頁面後就失效

localStorage

localStorage是什麼

localStroage是html5提供的一個api,它的實質是存放在瀏覽器的一個雜湊表{'key':'value'},

localStorage在那裡

C盤的一個祕密地點,和硬碟Cookie一樣

localStorage的api

不用解釋直接都看得懂,這裡介紹常見的幾個寫,讀,刪

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，影像，可以設定為靜態快取

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呢？

相關文章