1. 程式人生 > >前端Http協議快取初解

前端Http協議快取初解

[TOC]

簡介

使用者獲取網路資源,需要通過非常長的網路去伺服器上請求資源,另外服務端為了應對大量的使用者請求而不斷的提升硬體效能與頻寬。這對使用者與服務端都非常的不友好。而快取就是為了解決使用者請求速度與釋放伺服器壓力而生的。

為什麼我會寫Http快取,因為下面介紹的快取都是通過Http定義的。瀏覽器快取則是另外的如:SessionStorage,LocalStorage(個人見解)。

快取的判斷規則

1. 過期機制

過期機制就是瀏覽器根據快取的有效期進行判斷,如果在有效期內就使用快取,否則就拋棄這個快取。

一個快取副本必須滿足以下條件,瀏覽器會認為它是有效的,足夠新的:

    1. 含有完整的過期時間控制頭資訊(HTTP協議報頭),並且仍在有效期內;

    2. 瀏覽器已經使用過這個快取副本,並且在一個會話中已經檢查過新鮮度;

2. 驗證機制

瀏覽器帶上本地快取副本的驗證資訊提交給伺服器(Last-Modified,ETag),由伺服器決定是否採用這個快取。

客戶端請求的時候帶上Last-Modified,伺服器進行驗證返回If-Modified-Since來確定資源是否是有效快取。另外在控制頭資訊帶上這個資源的實體標籤Etag(Entity Tag),它可以用來作為瀏覽器再次請求過程的校驗標識。如過發現校驗標識不匹配,說明資源已經被修改或過期,瀏覽器需求重新獲取資源內容。

快取來源

1. from disk cache

此資源是從磁碟當中取出的,也是在已經在之前的某個時間載入過該資源,不會請求伺服器但是此資源不會隨著該頁面的關閉而釋放掉,因為是存在硬碟當中的,下次開啟仍會from disk cache。

2. from memory cache

字面理解是從記憶體中,其實也是字面的含義,這個資源是直接從記憶體中拿到的,不會請求伺服器一般已經載入過該資源且快取在了記憶體當中,當關閉該頁面時,此資源就被記憶體釋放掉了,再次重新開啟相同頁面時不會出現from memory cache的情況。

3. 請求來源

當http狀態為200是實實在在從瀏覽器獲取的資源,當http狀態為304時該數字是與服務端通訊報文的大小,並不是該資源本身的大小,該資源是從本地獲取的。

快取型別

強快取

1. Expires

伺服器傳送給客戶端一個UTC時間(如 expires: Thu, 19 Nov 2019 08:52:00 GMT),瀏覽器接收到了這個頭,就會為這個資源標記一個過期時間,在下次的請求時候判斷未過期會直接使用這個資源快取。來源會標記為from disk cache

瀏覽器在取到這個快取資源的時候,會用客戶機的時間與之對比,如果還在有效期內,則直接使用這個快取,不進行網路請求。否則會進入其他快取依據判斷。

而這個機制會有一個問題,就是,快取資源是否過期依賴客戶機時間。客戶機可以通過修改當前時間來使這個快取資源失效

2. Cache-Control

HTTP/1.1定義的 Cache-Control 頭用來區分對快取機制的支援情況, 請求頭和響應頭都支援這個屬性。通過它提供的不同的值來定義快取策略。

2.1 max-age

示例:

Cache-Control: max-age=100

這個示例表示,這個快取資源在本次請求後的100秒之後都有效。瀏覽器會直接返回from disk cache,不進行網路資源請求。

2.2 no-cache

示例:

Cache-Control: no-cache

這個示例表示,這個快取資源不進行強快取校驗,需要通過服務端的協商快取判斷是否啟用。

協商快取

1. Last-Modified,If-Modified-Since

當客戶端訪問資源時,伺服器會將資源最後修改時間通過 Last-Modified 標識由伺服器發往客戶端,客戶端記錄修改時間,再次請求本地存在的快取資源時,客戶端會通過 If-Modified-Since 頭將先前伺服器端發過來的最後修改時間戳傳送回去,伺服器端通過這個時間戳判斷客戶端的頁面是否是最新的,如果不是最新的,則返回新的內容,如果是最新的,則返回304告訴客戶端其本地快取資源是最新的。

2. ETag

伺服器為一個資源生成一個唯一的id值,一旦資源在服務端發生了改變則會重新生成一個tag,客戶端請求資源時,帶上了這個etag,如果不一致,服務端將會發送最新的資源給使用者,否則重定向304直接使用快取資源。

瀏覽器快取判斷流程

Alt text

參考文章