HTTP緩存技術(shù)詳解


title: HTTP緩存技術(shù)詳解
date: 2018-05-21 14:20:06
tags:

  • HTTP
  • 緩存
    categories: 深入http

通過網(wǎng)絡(luò)獲取內(nèi)容既緩慢房匆,成本又高:大的響應(yīng)需要在客戶端和服務(wù)器之間進行多次往返通信蹈丸,這拖延了瀏覽器可以使用和處理內(nèi)容的時間县貌,同時也增加了訪問者的數(shù)據(jù)成本升薯。因此膏秫,緩存和重用以前獲取的資源的能力成為優(yōu)化性能很關(guān)鍵的一個方面喘落。

與緩存相關(guān)的HTTP頭部字段

http1.0時期的緩存方案

頭部名稱 說明
Pragma 控制緩存行為规伐,如果設(shè)置為no-cache蟹倾,表示禁用緩存。和http1.1中的Cache-Control頭部功能相似
Expires 過期時間猖闪,用的是服務(wù)器的時間鲜棠,如果客戶端和服務(wù)器時間不一致,則會存在緩存時間誤差培慌。http1.1可以用Cache-Control來實現(xiàn)相似的功能豁陆。

如果使用了Pragma: 'no-cache'的話,再設(shè)置Expires或者Cache-Control吵护,就沒有用了盒音,說明Pragma的權(quán)值比后兩者高。

如果設(shè)置了Expires之后馅而,客戶端在需要請求數(shù)據(jù)的時候祥诽,首先會對比當(dāng)前系統(tǒng)時間和這個Expires時間,如果沒有過那個時間瓮恭,則直接讀取本地磁盤中的緩存數(shù)據(jù)雄坪,不發(fā)送請求。

http1.1的緩存方案

通用頭部字段屯蹦,即請求和響應(yīng)都可以包含

頭部名稱 說明
Cache-Control 控制緩存行為
Pragma http1.0的字段维哈,作用和Cache-Control大體相同

  • Cache-Control作為請求頭部
指令 參數(shù) 說明
no-cache 強制向源服務(wù)器再次驗證
no-store 不緩存請求或相應(yīng)的任何內(nèi)容
max-age=[秒] 必需 相應(yīng)的最大Age值
max-stale=(=[秒]) 可省略 接收已過期的響應(yīng)
min-fresh=[秒] 必需 期望在指定時間內(nèi)的響應(yīng)仍有效
no-transform 代理不可更改媒體類型
only-if-cached 從緩存獲取資源
cache-extension - 新指令標(biāo)記(token)

Cache-Control: no-cache

使用 no-cache 指令的目的是為了防止從緩存中返回過期的資源。 客戶端發(fā)送的請求中如果包含 no-cache 指令登澜,則表示客戶端將不會接 收緩存過的響應(yīng)阔挠。于是,“中間”的緩存服務(wù)器必須把客戶端請求轉(zhuǎn)發(fā) 給源服務(wù)器脑蠕。

Cache-Control: max-age=604800(單位:秒)

當(dāng)客戶端發(fā)送的請求中包含 max-age 指令時购撼,如果判定緩存資源的緩 存時間數(shù)值比指定時間的數(shù)值更小,那么服務(wù)端就直接返回304,客戶端會使用自己本地緩存的資源。 另外褥实,當(dāng)指定 max-age 值為 0授霸,那么服務(wù)器就會使用ETag和modefied-time驗證,來決定返回304還是200廓旬。

應(yīng)用 HTTP/1.1 版本的緩存服務(wù)器遇到同時存在 Expires 首部字段的情 況時哼审,會優(yōu)先處理 max-age 指令谐腰,而忽略掉 Expires 首部字段。而 HTTP/1.0 版本的緩存服務(wù)器的情況卻相反涩盾,max-age 指令會被忽略十气。

  • Cache-Control作為響應(yīng)頭部
指令 參數(shù) 說明
public 可向任意方提供響應(yīng)的緩存
private 可省略 僅向特定用戶返回響應(yīng)
no-cache 可省略 緩存前必需先確認其有效性
no-store 不緩存請求或相應(yīng)的任何內(nèi)容
no-transform 代理不可更改媒體類型
must-revalidate 可緩存但必須再向源服務(wù)器進行確認
proxy-revalidate 要求中間緩存服務(wù)器對緩存的響應(yīng)有效性再進行確認
max-age=[秒] 必需 響應(yīng)的最大Age值
s-maxage=[秒] 必需 公共緩存服務(wù)器響應(yīng)的最大Age值
cache-extension - 新指令標(biāo)記(token)

Cache-Control: public

當(dāng)指定使用 public 指令時,則明確表明其他用戶也可利用緩存春霍。

Cache-Control: private

當(dāng)指定 private 指令后砸西,響應(yīng)只以特定的用戶作為對象,這與 public 指令的行為相反址儒。 緩存服務(wù)器會對該特定用戶提供資源緩存的服務(wù)芹枷,對于其他用戶發(fā)送 過來的請求,代理服務(wù)器則不會返回緩存莲趣。

Cache-Control: no-cache

如果服務(wù)器返回的響應(yīng)中包含 no-cache 指令鸳慈,那么緩存服務(wù)器不能對 資源進行緩存。源服務(wù)器以后也將不再對緩存服務(wù)器請求中提出的資 源有效性進行確認喧伞,且禁止其對響應(yīng)資源進行緩存操作走芋。

Cache-Control: no-cache=Location

由服務(wù)器返回的響應(yīng)中,若報文首部字段 Cache-Control 中對 no-cache 字段名具體指定參數(shù)值潘鲫,那么客戶端在接收到這個被指定參數(shù)值的首 部字段對應(yīng)的響應(yīng)報文后翁逞,就不能使用緩存。換言之溉仑,無參數(shù)值的首 部字段可以使用緩存熄攘。只能在響應(yīng)指令中指定該參數(shù)。

Cache-Control: no-store

當(dāng)使用 no-store 指令時彼念,暗示請求(和對應(yīng)的響應(yīng))或響應(yīng)中包含機密信息挪圾。

注:從字面意思上很容易把 no-cache 誤解成為不緩存,但事實上 no-cache 代表不緩 存過期的資源逐沙,緩存會向源服務(wù)器進行有效期確認后處理資源哲思,也許稱為 do-notserve-from-cache-without-revalidation 更合適。no-store 才是真正地不進行緩存吩案。

因此棚赔,該指令規(guī)定緩存不能在本地存儲請求或響應(yīng)的任一部分。

Cache-Control: max-age=604800(單位:秒)

當(dāng)客戶端發(fā)送的請求中包含 max-age 指令時徘郭,如果判定緩存資源的緩 存時間數(shù)值比指定時間的數(shù)值更小靠益,那么客戶端就不會發(fā)起請求,而是直接使用自己本地緩存的資源残揉。 另外胧后,當(dāng)指定 max-age 值為 0,那么客戶端一定會發(fā)起一個請求給服務(wù)端抱环,服務(wù)端會進行資源的校驗壳快,決定返回304還是200纸巷。

應(yīng)用 HTTP/1.1 版本的緩存服務(wù)器遇到同時存在 Expires 首部字段的情 況時,會優(yōu)先處理 max-age 指令眶痰,而忽略掉 Expires 首部字段瘤旨。而 HTTP/1.0 版本的緩存服務(wù)器的情況卻相反,max-age 指令會被忽略竖伯。

Cache-Control: s-maxage=604800(單位 :秒)

s-maxage 指令的功能和 max-age 指令的相同存哲,它們的不同點是 smaxage 指令只適用于供多位用戶使用的公共緩存服務(wù)器 ,如CDN緩存七婴。也就是 說宏胯,對于向同一用戶重復(fù)返回響應(yīng)的服務(wù)器來說,這個指令沒有任何 作用本姥。

另外肩袍,當(dāng)使用 s-maxage 指令后,則直接忽略對 Expires 首部字段及 max-age 指令的處理婚惫。

cache-control指令流程圖

圖片51.png

請求頭部字段

頭部名稱 說明
If-Match 比較ETag是否一致氛赐,和響應(yīng)的ETag字段相對應(yīng)
If-None-Match 比較ETag是否不一致,和響應(yīng)的ETag字段相對應(yīng)
If-Modified-Since 比較資源最后更新時間是否一致先舷,和響應(yīng)的Last-Modified字段相對應(yīng)
If-Unmodified-Since 比較資源最后更新時間是否不一致艰管,和響應(yīng)的Last-Modified字段相對應(yīng)

響應(yīng)頭部字段

頭部名稱 說明
Etag 資源匹配信息

響應(yīng)實體頭部字段

頭部名稱 說明
Expires http1.0的緩存過期時間字段
Last-Modified 資源最后一次修改時間

緩存校驗字段

ETag

首部字段 ETag 能告知客戶端實體標(biāo)識。它是一種可將資源以字符串 形式做唯一性標(biāo)識的方式蒋川。服務(wù)器會為每份資源分配對應(yīng)的 ETag 值牲芋。

另外,當(dāng)資源更新時捺球,ETag 值也需要更新缸浦。生成 ETag 值時,并沒有 統(tǒng)一的算法規(guī)則氮兵,而僅僅是由服務(wù)器來分配裂逐。

資源被緩存時,就會被分配唯一性標(biāo)識泣栈。例如卜高,當(dāng)使用中文版的瀏覽 器訪問 http://www.google.com/ 時,就會返回中文版對應(yīng)的資源南片,而 使用英文版的瀏覽器訪問時掺涛,則會返回英文版對應(yīng)的資源。兩者的 URI 是相同的疼进,所以僅憑 URI 指定緩存的資源是相當(dāng)困難的薪缆。若在下 載過程中出現(xiàn)連接中斷、再連接的情況颠悬,都會依照 ETag 值來指定資 源矮燎。

強 ETag 值和弱 Tag 值

ETag 中有強 ETag 值和弱 ETag 值之分定血。

強 ETag 值赔癌,不論實體發(fā)生多么細微的變化都會改變其值诞外。

ETag: "usagi-1234"

弱 ETag 值只用于提示資源是否相同。只有資源發(fā)生了根本改變灾票,產(chǎn) 生差異時才會改變 ETag 值峡谊。這時,會在字段值最開始處附加 W/刊苍。

ETag: W/"usagi-1234"

If-Match

形如 If-xxx 這種樣式的請求首部字段既们,都可稱為條件請求。服務(wù)器接 收到附帶條件的請求后正什,只有判斷指定條件為真時啥纸,才會執(zhí)行請求。

首部字段 If-Match婴氮,屬附帶條件之一斯棒,它會告知服務(wù)器匹配資源所用 的實體標(biāo)記(ETag)值。這時的服務(wù)器無法使用弱 ETag 值主经。(請參 照本章有關(guān)首部字段 ETag 的說明) 服務(wù)器會比對 If-Match 的字段值和資源的 ETag 值荣暮,僅當(dāng)兩者一致 時,才會執(zhí)行請求罩驻。反之穗酥,則返回狀態(tài)碼 412 Precondition Failed 的響 應(yīng)。

可以理解為客戶端校驗當(dāng)前本地緩存是否在服務(wù)器端可用惠遏。

還可以使用星號(*)指定 If-Match 的字段值砾跃。針對這種情況,服務(wù) 器將會忽略 ETag 的值节吮,只要資源存在就處理請求蜓席。可以理解為客戶端強制請求服務(wù)器當(dāng)前的資源實體课锌。

這個值默認是上一次該資源響應(yīng)頭部的ETag字段值厨内。

If-None-Match

首部字段 If-None-Match 屬于附帶條件之一。它和首部字段 If-Match 作用相反渺贤。用于指定 If-None-Match 字段值的實體標(biāo)記(ETag)值與 請求資源的 ETag 不一致時雏胃,它就告知服務(wù)器處理該請求。如果一致志鞍,就返回304瞭亮,表示告知客戶端使用自己本地的緩存。

在 GET 或 HEAD 方法中使用首部字段 If-None-Match 可獲取最新的資 源固棚。因此统翩,這與使用首部字段 If-Modified-Since 時有些類似仙蚜。

這個值默認是上一次該資源響應(yīng)頭部的ETag字段值。

Last-modified

Last-Modified: Wed, 23 May 2012 09:59:55 GMT

首部字段 Last-Modified 指明資源最終修改的時間厂汗。一般來說委粉,這個 值就是 Request-URI 指定資源被修改的時間。

If-Modified-Since

If-Modified-Since: Thu, 15 Apr 2004 00:00:00 GMT

首部字段 If-Modified-Since娶桦,屬附帶條件之一贾节,它會告知服務(wù)器若 If-Modified-Since 字段值早于資源的更新時間,則希望能處理該請求衷畦。 而在指定 If-Modified-Since 字段值的日期時間之后栗涂,如果請求的資源 都沒有過更新祈争,則返回狀態(tài)碼 304 Not Modified 的響應(yīng)。

這個值默認是上一次該資源響應(yīng)實體頭部的Last-Modified字段值菩混。

If-Unmodified-Since

If-Unmodified-Since: Thu, 03 Jul 2012 00:00:00 GMT

首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的作用相 反忿墅。它的作用的是告知服務(wù)器球匕,指定的請求資源只有在字段值內(nèi)指定 的日期時間之后,未發(fā)生更新的情況下帖烘,才能處理請求。如果在指定 日期時間后發(fā)生了更新秘症,則以狀態(tài)碼 412 Precondition Failed 作為響應(yīng) 返回。

可以理解為客戶端校驗當(dāng)前本地緩存是否在服務(wù)器端可用乡摹。

這個值默認是上一次該資源響應(yīng)實體頭部的Last-Modified字段值。

緩存分類

強緩存

強緩存在客戶端和服務(wù)器端都會存在聪廉。

客戶端:客戶端在請求資源前瞬痘,會檢查上一次該資源響應(yīng)頭的Cache-Control字段框全,如果該字段的值為max-age=time(大于0的秒數(shù)),如果該資源緩存的時間沒有過這個時間值干签,則直接使用本地的緩存,而不像服務(wù)器發(fā)請求。

服務(wù)器端:服務(wù)器端在接收到一個請求后喘沿,如果該請求的頭部Cache-Control字段的值為max-age=time(大于0的秒數(shù))闸度,如果距離上一次返回資源的時間小于這個秒數(shù),那么服務(wù)器不會讀取新的資源蚜印,而是直接返回304莺禁,告知客戶端使用自己本地上次緩存的資源即可。

:這兩種情況晒哄,其實歸根結(jié)底最后都是使用的客戶端本地的資源睁宰,服務(wù)器沒有返回資源實體肪获。這樣的好處是節(jié)省請求次數(shù)或者請求流量寝凌,但缺點是,如果在max-age時間內(nèi)服務(wù)器資源有更新孝赫,客戶端無法得到最新的服務(wù)器資源较木。此時可以通過Ctrl+F5強制刷新(其實就是設(shè)置一個Cache-Control:no-cache的請求頭),獲得最新的服務(wù)器資源青柄。

協(xié)商緩存(對比緩存)

對比緩存值存在于服務(wù)器端伐债。

在沒有走強緩存邏輯的情況下,服務(wù)器端會進行Last-Modified和Etag的校驗致开,如果校驗發(fā)現(xiàn)資源未更新峰锁,則會返回304,否則會返回新的資源實體双戳。

緩存流程圖

圖片61.png
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末虹蒋,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子飒货,更是在濱河造成了極大的恐慌魄衅,老刑警劉巖,帶你破解...
    沈念sama閱讀 222,729評論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件塘辅,死亡現(xiàn)場離奇詭異晃虫,居然都是意外死亡,警方通過查閱死者的電腦和手機扣墩,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,226評論 3 399
  • 文/潘曉璐 我一進店門哲银,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人呻惕,你說我怎么就攤上這事荆责。” “怎么了蟆融?”我有些...
    開封第一講書人閱讀 169,461評論 0 362
  • 文/不壞的土叔 我叫張陵草巡,是天一觀的道長。 經(jīng)常有香客問我,道長山憨,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 60,135評論 1 300
  • 正文 為了忘掉前任玛迄,我火速辦了婚禮棚亩,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘勒虾。我一直安慰自己瘸彤,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 69,130評論 6 398
  • 文/花漫 我一把揭開白布愕宋。 她就那樣靜靜地躺著结榄,像睡著了一般。 火紅的嫁衣襯著肌膚如雪邻寿。 梳的紋絲不亂的頭發(fā)上依溯,一...
    開封第一講書人閱讀 52,736評論 1 312
  • 那天黎炉,我揣著相機與錄音,去河邊找鬼慷嗜。 笑死,一個胖子當(dāng)著我的面吹牛薇溃,可吹牛的內(nèi)容都是我干的缭乘。 我是一名探鬼主播,決...
    沈念sama閱讀 41,179評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼邑时,長吁一口氣:“原來是場噩夢啊……” “哼特姐!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起唐含,我...
    開封第一講書人閱讀 40,124評論 0 277
  • 序言:老撾萬榮一對情侶失蹤捷枯,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后铜靶,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體他炊,經(jīng)...
    沈念sama閱讀 46,657評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,723評論 3 342
  • 正文 我和宋清朗相戀三年蚕苇,在試婚紗的時候發(fā)現(xiàn)自己被綠了涩笤。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片盒件。...
    茶點故事閱讀 40,872評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖恩沽,靈堂內(nèi)的尸體忽然破棺而出翔始,到底是詐尸還是另有隱情,我是刑警寧澤渤闷,帶...
    沈念sama閱讀 36,533評論 5 351
  • 正文 年R本政府宣布脖镀,位于F島的核電站,受9級特大地震影響弦蹂,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜腾务,卻給世界環(huán)境...
    茶點故事閱讀 42,213評論 3 336
  • 文/蒙蒙 一削饵、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧启昧,春花似錦、人聲如沸密末。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,700評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至座柱,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間戏锹,已是汗流浹背火诸。 一陣腳步聲響...
    開封第一講書人閱讀 33,819評論 1 274
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留伞插,地道東北人盾碗。 一個月前我還...
    沈念sama閱讀 49,304評論 3 379
  • 正文 我出身青樓,卻偏偏與公主長得像耗美,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子商架,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,876評論 2 361

推薦閱讀更多精彩內(nèi)容

  • 本篇文章篇幅比較長蛇摸,先來個思維導(dǎo)圖預(yù)覽一下。 一赶袄、概述 1.計算機網(wǎng)絡(luò)體系結(jié)構(gòu)分層 2.TCP/IP 通信傳輸流 ...
    滌生_Woo閱讀 55,054評論 24 557
  • 本文是《圖解HTTP》讀書筆記的第二篇饿肺,主要包括此書的第六章內(nèi)容,因為第六章的內(nèi)容較多敬辣,而且比較重要,所以單獨寫為...
    lijiankun24閱讀 1,371評論 0 6
  • 本文內(nèi)容大多參考《圖解HTTP》一書 一. 認識代理服務(wù)器 所以講緩存為什么要先扯代理服務(wù)器村刨?別急喊积,讓我們看一下一...
    流光號船長閱讀 1,937評論 0 10
  • 針對瀏覽器的http緩存的分析也算是老生常談了,每隔一段時間就會冒出一篇不錯的文章,其原理也是各大公司面試時幾乎必...
    全端玩法閱讀 879評論 0 9
  • 我現(xiàn)在在上海市靜安區(qū)富民路83號的一家啤酒吧工作拟蜻。名曰:Dr.Beer 這家酒吧的生意還不錯。因為夏天快到了诡必,這幾...
    曾在天涯up閱讀 141評論 0 1