瀏覽器緩存用到的協議

Ⅰ 瀏覽器緩存機制

有dns的地方,就有緩存。瀏覽器、操作系統、Local DNS、根域名伺服器，它們都會對DNS結果做一定程度的緩存。

DNS查詢過程如下:

首先搜索瀏覽器自身的DNS緩存,如果存在，則域名解析到此完成。
如果瀏覽器自身的緩存裡面沒有找到對應的條目，那麼會嘗試讀取操作系統的hosts文件看是否存在對應的映射關系,如果存在，則域名解析到此完成。
如果本地hosts文件不存在映射關系，則查找本地DNS伺服器(ISP伺服器,或者自己手動設置的DNS伺服器),如果存在,域名到此解析完成。
如果本地DNS伺服器還沒找到的話,它就會向根伺服器發出請求,進行遞歸查詢。

瀏覽器本地緩存失效後，瀏覽器會向CDN邊緣節點發起請求。類似瀏覽器緩存,CDN邊緣節點也存在著一套緩存機制。CDN邊緣節點緩存策略因服務商不同而不同，但一般都會遵循http標准協議，通過http響應頭中的
Cache-control: max-age 的欄位來設置CDN邊緣節點數據緩存時間。

當瀏覽器向CDN節點請求數據時，CDN節點會判斷緩存數據是否過期，若緩存數據並沒有過期，則直接將緩存數據返回給客戶端；否則，CDN節點就會向伺服器發出回源請求，從伺服器拉取最新數據，更新本地緩存，並將最新數據返回給客戶端。 CDN服務商一般會提供基於文件後綴、目錄多個維度來指定CDN緩存時間，為用戶提供更精細化的緩存管理。

CDN 優勢
CDN節點解決了跨運營商和跨地域訪問的問題，訪問延時大大降低。
大部分請求在CDN邊緣節點完成，CDN起到了分流作用，減輕了源伺服器的負載。

http請求報文（request）
請求行
請求方法  空格  URL 空格  協議版本 回車符 換行符
請求頭（通用信息頭、請求頭、實體頭）
頭部欄位名 冒號  值  回車鍵 換行符
...
頭部欄位名 冒號  值  回車鍵 換行符
空行
回車符   換行符
實體主體（只有post請求有）
主體

http響應報文（response）
狀態行
協議版本  空格  狀態碼 空格  狀態碼描述 回車符 換行符
響應頭部
頭部欄位名 冒號  值   回車符 換行符
...
頭部欄位名 冒號  值   回車符 換行符
空行
回車符   換行符
響應正文
正文

瀏覽器初次向伺服器發起請求後拿到請求結果，會根據響應報文中HTTP頭的緩存標識，決定是否緩存返回的結果，是則將請求結果和緩存標識存入瀏覽器緩存中

瀏覽器每次發起請求，都會現在瀏覽器緩存中查找該請求的結果以及緩存標識
瀏覽器                瀏覽器緩存        伺服器

——————第一次發起http請求——————>

<——沒有該請求的緩存結果和緩存標識————

——————————————發起http請求——————————————>

<——————————返回該請求結果和緩存規則————————————

——將請求結果和緩存標識存入瀏覽器緩存——>

強制緩存就是向瀏覽器緩存查找結果，並根據該結果的緩存規則來決定是否使用該緩存結果的過程

強制緩存的情況分為三種：
1、不存在該緩存結果和緩存標識，強制緩存失效，直接向伺服器發起請求
2、存在該緩存結果和緩存標識，但結果已經失效，強制緩存失效，使用協商緩存
3、存在該緩存結果和緩存標識，且該結果沒有失效，強制緩存生效，直接返回該結果

控制強制緩存的欄位：Expires，Cache-Control

Expires 是 HTTP/1.0 控制緩存的欄位，值為伺服器返回該請求的結果緩存時間
即再次發送請求是，客戶端時間 小於 Expires的值，直接使用緩存結果

Cache-Control 是HTTP/1.1的規則，主要用於控制網頁緩存，主要取值為：
public：所有的內容都緩存（客戶端和代理伺服器都可以緩存）
private：所有內容只有客戶端可以緩存（默認值）
no-cache：客戶端緩存內容，但是是否使用緩存則需要經過協商緩存來驗證決定
no-store：即不使用強制緩存，也不使用協商緩存
max-age=xxx：緩存內容將在xxx秒後失效

Expires 是一個絕對值
Cache-Control 中 max-age 是相對值，解決了 Expires時期 服務端與客戶端 可能出現時間差的問題

註：Expires和Cache-Control同時存在時，只有Cache-Control生效

協商緩存就是強制緩存失效後，瀏覽器攜帶緩存標識向伺服器發起請求，由伺服器根據緩存標識決定是否使用緩存的過程

協商緩存的兩種情況：
1、協商緩存生效，返回304，繼續使用緩存
過程：
瀏覽器                 瀏覽器緩存     伺服器

————————發起http請求————————>

<——該請求的緩存結果失效，只返回緩存標識——

————————攜帶該資源的緩存標識，發起http請求————————>

<—————————————304，該資源無更新————————————

——————獲取該請求的緩存結果——————>

<——————返回該請求的緩存結果——————

2、協商緩存失敗，返回200和請求結果
過程：
瀏覽器                 瀏覽器緩存     伺服器

————————發起http請求————————>

<——該請求的緩存結果失效，只返回緩存標識——

————————攜帶該資源的緩存標識，發起http請求————————>

<————————200，資源已更新，重新返回請求和結果———————

——將該請求結果和緩存標識存入瀏覽器緩存中—>

協商緩存的標識也是在響應報文的HTTP頭中和請求結果一起返回給瀏覽器的

控制協商緩存的欄位：
(1) Last-Modified/If-Modified-Since：Last-Modified是伺服器響應請求是，返回該資源文件在伺服器最後被修改的時間；If-Modified-Since再次發起請求時，攜帶上次返回的Last-Modified的值，伺服器將該欄位值與該資源最後修改時間對比，決定是否用緩存
(2)Etag/If-None-Match：Etag伺服器響應請求時，返回當前資源文件的一個唯一標識，由伺服器生成之；If-None-Match是再次發起請求時，攜帶上次返回的唯一標識Etag的值，伺服器收到後，將該欄位值與該資源在伺服器上的Etag對比，一致 則返回304，否則返回200

註：Etag/If-None-Match優先順序高於Last-Modified/If-Modified-Since，同時存在時只有Etag/If-None-Match生效

瀏覽器緩存分為：內存緩存 和 硬碟緩存

內存緩存特性：
(1)快速讀取：內存緩存會將編譯解析後的文件，存入該進程的內存中，便於下次運行時快速讀取
(2)時效性：一旦關閉進程，進程內存清空

硬碟緩存特性：
永久性：直接寫入硬碟文件中
復雜、緩慢：讀取緩存對該緩存存放的硬碟文件進行I/O操作，重新解析

from memory cache：使用內存中的緩存

from disk cache：使用硬碟中的緩存

瀏覽器讀取順序：memory ——> disk

瀏覽器將js和圖片等文件解析執行後直接存入內存緩存中，F5刷新頁面時，from memory cache(使用內存中的緩存)
css文件存入硬碟中，F5刷新頁面時，from disk cache(使用硬碟中的緩存)

參考文章
https://segmentfault.com/a/1190000017962411
https://www.cnblogs.com/chengxs/p/10396066.html

Ⅱ 瀏覽器緩存功能在使用上都有哪些類型

緩存功能的存在，讓我們在瀏覽網頁和訪問防止的時候可以更快的載入我們需要的內容，而今天北森手大青鳥就通過案例分析來了解一下，瀏覽器的緩存功能在使用上都有哪些類型。

1.ServiceWorker

ServiceWorker是運行在瀏覽器背後的獨立線程，一般可以用來實現緩存功能。使用ServiceWorker的話，傳輸協議必須為HTTPS。因為ServiceWorker中涉及到請求攔截，所以必須使用HTTPS協議來保障安全。ServiceWorker的緩存與瀏覽器其他內建的緩存機制不同，它可以讓我們自由控制緩存哪些文件、如何匹配緩存、如何讀取緩存，並且緩存是持續性的。

ServiceWorker實現緩存功能一般分為三個步驟：先需要先注冊ServiceWorker，然後監聽到install事件以後就可以緩存需要的文件，那麼在下次用戶訪問的時候就可以通過攔截請求的方式查詢是否存在緩存，存在緩存的話就可以直接讀取緩存文件，否則就去請求數據。

當ServiceWorker沒有命中緩存的時候，我們需要去調用fetch函數獲取數據。也就是說，如果我們沒有在ServiceWorker命中緩存的話，會根據緩存查找優先順序去查找數據。但是不管我們是從MemoryCache中還是從網路請求中獲取的數據，瀏覽器都會顯示我們是從ServiceWorker中獲取的內容。

2.MemoryCache

MemoryCache也就是內存中的緩存，主要包含的是當前中頁面中已經抓取到的資源,例如頁面上已經下載的樣式、腳本、圖片等。讀取內存中的數據肯定比磁碟快,內存緩存雖運春碧然讀取高效，可是緩存持續性很短，會隨著進程的釋放而釋放。一旦我們關閉Tab頁面，內存中的緩存也就被釋放了。

那麼既然內存緩存這么高效，我們是不是能讓數據都存放在內存中呢?

這是不可能的旁舉。計算機中的內存一定比硬碟容量小得多，操作系統需要精打細算內存的使用，所以能讓我們使用的內存必然不多。

Ⅲ Http協議中，用於控制緩存的Header有哪些並簡要說明

• Last-Modified(伺服器響應) 和 If-Modified-Since（瀏覽器請求）

• ETag(伺服器) 和 If-None-Match（瀏覽器）

• Expires（伺服器響應傳遞，格林威治格式的一個具體的時間點）

• Cache-Control（伺服器建議的緩存策略）

  max-age：時間長度。（瀏覽器和共享高速緩存緩存有效的時長)

  s-maxage: 時間長度。共享高速緩存的緩存有效時長（瀏覽器不進行緩存）

  no-cache：瀏覽器不從緩存讀取，必須請求伺服器。

  no-store：不緩存任何請求和響應信息。

  public：對任何緩存媒介都可緩存該響應。

  private：只允許個體客戶端緩存，不允許共享高速緩存。
  

可以看這篇文章：網頁鏈接

Ⅳ 緩存是什麼意思

緩存是指可以進行高速數據交換的存儲器，它先於內存與CPU交換數據，因此速率很快。

緩存的工作原理是當CPU要讀取一個數據時，首先從CPU緩存中查找，找到就立即讀取並送給CPU處理；沒有找到，就從速率相對較慢的內存中讀取並送給CPU處理，同時把這個數據所在的數據塊調入緩存中，可以使得以後對整塊數據的讀取都從緩存中進行，不必再調用內存。

正是這樣的讀取機制使CPU讀取緩存的命中率非常高（大多數CPU可達90%左右），也就是說CPU下一次要讀取的數據90%都在CPU緩存中，只有大約10%需要從內存讀取。這大大節省了CPU直接讀取內存的時間，也使CPU讀取數據時基本無需等待。

(4)瀏覽器緩存用到的協議擴展閱讀

緩存的狀態數據只是主數據的快照，由於數據源可能被修改，所以狀態數據就有會陳舊的特性。合理利用此特性和將數據陳舊的負面影響最小化是緩存狀態數據的一個重要任務。

緩存介質從技術上劃分，可以分成內存、硬碟文件、資料庫三種。將緩存存儲於內存中是最快的選擇，無需額外的I/O開銷，但是內存的缺點是沒有持久化落地物理磁碟，一旦應用異常，重新啟動數據很難或者無法復原。

緩存中可以存放的最大元素的數量，一旦緩存中元素數量超過這個值（或者緩存數據所佔空間超過其最大支持空間），那麼將會觸發緩存啟動清空策略根據不同的場景合理的設置最大元素值往往可以一定程度上提高緩存的命中率，從而更有效的時候緩存。

Ⅳ 瀏覽器採用http 協議訪問網頁的工作過程

1. 首先嘛，你得在瀏覽器里輸入要網址:

2. 瀏覽器查找域名的IP地址

導航的第一步是通過訪問的域名找出其IP地址。DNS查找過程如下：
瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時間。 有趣的是，操作系統沒有告訴瀏覽器儲存DNS記錄的時間，這樣不同瀏覽器會儲存個自固定的一個時間（2分鍾到30分鍾不等）。
系統緩存 – 如果在瀏覽器緩存里沒有找到需要的記錄，瀏覽器會做一個系統調用（windows里是gethostbyname）。這樣便可獲得系統緩存中的記錄。
路由器緩存 – 接著，前面的查詢請求發向路由器，它一般會有自己的DNS緩存。
ISP DNS 緩存 – 接下來要check的就是ISP緩存DNS的伺服器。在這一般都能找到相應的緩存記錄。
遞歸搜索 – 你的ISP的DNS伺服器從跟域名伺服器開始進行遞歸搜索，從.com頂級域名伺服器到Facebook的域名伺服器。一般DNS伺服器的緩存中會有.com域名伺服器中的域名，所以到頂級伺服器的匹配過程不是那麼必要了。
DNS遞歸查找如下圖所示：

DNS有一點令人擔憂，這就是像wikipedia.org 或者 facebook.com這樣的整個域名看上去只是對應一個單獨的IP地址。還好，有幾種方法可以消除這個瓶頸：
循環 DNS 是DNS查找時返回多個IP時的解決方案。舉例來說，Facebook.com實際上就對應了四個IP地址。
負載平衡器 是以一個特定IP地址進行偵聽並將網路請求轉發到集群伺服器上的硬體設備。 一些大型的站點一般都會使用這種昂貴的高性能負載平衡器。
地理 DNS 根據用戶所處的地理位置，通過把域名映射到多個不同的IP地址提高可擴展性。這樣不同的伺服器不能夠更新同步狀態，但映射靜態內容的話非常好。
Anycast 是一個IP地址映射多個物理主機的路由技術。 美中不足，Anycast與TCP協議適應的不是很好，所以很少應用在那些方案中。
大多數DNS伺服器使用Anycast來獲得高效低延遲的DNS查找。

3. 瀏覽器給web伺服器發送一個HTTP請求

因為像Facebook主頁這樣的動態頁面，打開後在瀏覽器緩存中很快甚至馬上就會過期，毫無疑問他們不能從中讀取。
所以，瀏覽器將把一下請求發送到Facebook所在的伺服器：
GET http://facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]
GET 這個請求定義了要讀取的URL： 「http://facebook.com/」。 瀏覽器自身定義 (User-Agent 頭)， 和它希望接受什麼類型的相應 (Accept and Accept-Encoding 頭). Connection頭要求伺服器為了後邊的請求不要關閉TCP連接。
請求中也包含瀏覽器存儲的該域名的cookies。可能你已經知道，在不同頁面請求當中，cookies是與跟蹤一個網站狀態相匹配的鍵值。這樣cookies會存儲登錄用戶名，伺服器分配的密碼和一些用戶設置等。Cookies會以文本文檔形式存儲在客戶機里，每次請求時發送給伺服器。
用來看原始HTTP請求及其相應的工具很多。作者比較喜歡使用fiddler，當然也有像FireBug這樣其他的工具。這些軟體在網站優化時會幫上很大忙。
除了獲取請求，還有一種是發送請求，它常在提交表單用到。發送請求通過URL傳遞其參數(e.g.: http://robozzle.com/puzzle.aspx?id=85)。發送請求在請求正文頭之後發送其參數。

像「http://facebook.com/」中的斜杠是至關重要的。這種情況下，瀏覽器能安全的添加斜杠。而像「http: //example.com/folderOrFile」這樣的地址，因為瀏覽器不清楚folderOrFile到底是文件夾還是文件，所以不能自動添加 斜杠。這時，瀏覽器就不加斜杠直接訪問地址，伺服器會響應一個重定向，結果造成一次不必要的握手。

4. facebook服務的永久重定向響應

圖中所示為Facebook伺服器發回給瀏覽器的響應：
HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2010 05:09:51 GMT
Content-Length: 0
伺服器給瀏覽器響應一個301永久重定向響應，這樣瀏覽器就會訪問「http://www.facebook.com/」 而非「http://facebook.com/」。
為什麼伺服器一定要重定向而不是直接發會用戶想看的網頁內容呢？這個問題有好多有意思的答案。
其中一個原因跟搜索引擎排名有 關。你看，如果一個頁面有兩個地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎會認為它們是兩個網站，結果造成每一個的搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是 什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。
還有一個是用不同的地址會造成緩存友好性變差。當一個頁面有好幾個名字時，它可能會在緩存里出現好幾次。
5. 瀏覽器跟蹤重定向地址

現在，瀏覽器知道了「http://www.facebook.com/」才是要訪問的正確地址，所以它會發送另一個獲取請求：
GET http://www.facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
Host: www.facebook.com
頭信息以之前請求中的意義相同。
6. 伺服器「處理」請求

伺服器接收到獲取請求，然後處理並返回一個響應。
這表面上看起來是一個順向的任務，但其實這中間發生了很多有意思的東西- 就像作者博客這樣簡單的網站，何況像facebook那樣訪問量大的網站呢！
Web 伺服器軟體
web伺服器軟體（像IIS和阿帕奇）接收到HTTP請求，然後確定執行什麼請求處理來處理它。請求處理就是一個能夠讀懂請求並且能生成HTML來進行響應的程序（像ASP.NET,PHP,RUBY...）。
舉 個最簡單的例子，需求處理可以以映射網站地址結構的文件層次存儲。像http://example.com/folder1/page1.aspx這個地 址會映射/httpdocs/folder1/page1.aspx這個文件。web伺服器軟體可以設置成為地址人工的對應請求處理，這樣 page1.aspx的發布地址就可以是http://example.com/folder1/page1。
請求處理
請求處理閱讀請求及它的參數和cookies。它會讀取也可能更新一些數據，並講數據存儲在伺服器上。然後，需求處理會生成一個HTML響應。
所 有動態網站都面臨一個有意思的難點 -如何存儲數據。小網站一半都會有一個SQL資料庫來存儲數據，存儲大量數據和/或訪問量大的網站不得不找一些辦法把資料庫分配到多台機器上。解決方案 有：sharding （基於主鍵值講數據表分散到多個資料庫中），復制，利用弱語義一致性的簡化資料庫。
委 托工作給批處理是一個廉價保持數據更新的技術。舉例來講，Fackbook得及時更新新聞feed，但數據支持下的「你可能認識的人」功能只需要每晚更新 （作者猜測是這樣的，改功能如何完善不得而知）。批處理作業更新會導致一些不太重要的數據陳舊，但能使數據更新耕作更快更簡潔。
7. 伺服器發回一個HTML響應

圖中為伺服器生成並返回的響應：
HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT

2b3Tn@[...]
整個響應大小為35kB，其中大部分在整理後以blob類型傳輸。
內容編碼頭告訴瀏覽器整個響應體用gzip演算法進行壓縮。解壓blob塊後，你可以看到如下期望的HTML：
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en" id="facebook" class=" no_js">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...
關於壓縮，頭信息說明了是否緩存這個頁面，如果緩存的話如何去做，有什麼cookies要去設置（前面這個響應里沒有這點）和隱私信息等等。
請注意報頭中把Content-type設置為「text/html」。報頭讓瀏覽器將該響應內容以HTML形式呈現，而不是以文件形式下載它。瀏覽器會根據報頭信息決定如何解釋該響應，不過同時也會考慮像URL擴展內容等其他因素。
8. 瀏覽器開始顯示HTML
在瀏覽器沒有完整接受全部HTML文檔時，它就已經開始顯示這個頁面了：

9. 瀏覽器發送獲取嵌入在HTML中的對象

在瀏覽器顯示HTML時，它會注意到需要獲取其他地址內容的標簽。這時，瀏覽器會發送一個獲取請求來重新獲得這些文件。
下面是幾個我們訪問facebook.com時需要重獲取的幾個URL：
圖片
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
…
CSS 式樣表
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
…
JavaScript 文件
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…
這些地址都要經歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名，發送請求，重定向等等...
但 不像動態頁面那樣，靜態文件會允許瀏覽器對其進行緩存。有的文件可能會不需要與伺服器通訊，而從緩存中直接讀取。伺服器的響應中包含了靜態文件保存的期限 信息，所以瀏覽器知道要把它們緩存多長時間。還有，每個響應都可能包含像版本號一樣工作的ETag頭（被請求變數的實體值），如果瀏覽器觀察到文件的版本 ETag信息已經存在，就馬上停止這個文件的傳輸。
試著猜猜看「fbcdn.net」在地址中代表什麼？聰明的答案是"Facebook內容分發網路"。Facebook利用內容分發網路（CDN）分發像圖片，CSS表和JavaScript文件這些靜態文件。所以，這些文件會在全球很多CDN的數據中心中留下備份。
靜態內容往往代表站點的帶寬大小，也能通過CDN輕松的復制。通常網站會使用第三方的CDN。例如，Facebook的靜態文件由最大的CDN提供商Akamai來託管。
舉例來講，當你試著ping static.ak.fbcdn.net的時候，可能會從某個akamai.net伺服器上獲得響應。有意思的是，當你同樣再ping一次的時候，響應的伺服器可能就不一樣，這說明幕後的負載平衡開始起作用了。
10. 瀏覽器發送非同步（AJAX）請求

在Web 2.0偉大精神的指引下，頁面顯示完成後客戶端仍與伺服器端保持著聯系。
以 Facebook聊天功能為例，它會持續與伺服器保持聯系來及時更新你那些亮亮灰灰的好友狀態。為了更新這些頭像亮著的好友狀態，在瀏覽器中執行的 JavaScript代碼會給伺服器發送非同步請求。這個非同步請求發送給特定的地址，它是一個按照程式構造的獲取或發送請求。還是在Facebook這個例 子中，客戶端發送給http://www.facebook.com/ajax/chat/buddy_list.php一個發布請求來獲取你好友里哪個 在線的狀態信息。
提起這個模式，就必須要講講"AJAX"-- 「非同步JavaScript 和 XML」，雖然伺服器為什麼用XML格式來進行響應也沒有個一清二白的原因。再舉個例子吧，對於非同步請求，Facebook會返回一些JavaScript的代碼片段。
除了其他，fiddler這個工具能夠讓你看到瀏覽器發送的非同步請求。事實上，你不僅可以被動的做為這些請求的看客，還能主動出擊修改和重新發送它們。AJAX請求這么容易被蒙，可著實讓那些計分的在線游戲開發者們郁悶的了。（當然，可別那樣騙人家~）
Facebook聊天功能提供了關於AJAX一個有意思的問題案例：把數據從伺服器端推送到客戶端。因為HTTP是一個請求-響應協議，所以聊天伺服器不能把新消息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下伺服器端看自己有沒有新消息。
這些情況發生時長輪詢是個減輕伺服器負載挺有趣的技術。如果當被輪詢時伺服器沒有新消息，它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新消息，伺服器就會找到未完成的請求，把新消息做為響應返回給客戶端。

Ⅵ 瀏覽器緩存的方式和類型（筆記）

瀏覽器緩存只是計算機緩存的一種

1.內存緩存
將數據存到內存
2.代理伺服器緩存
就是個自己找的中介。你拿東西先找中介，中介找房東，房東給中介，中介又給你。比如你需要房子鑰匙，房東把鑰匙放在中介那，你直接從中介那裡拿鑰匙。
3.CDN緩存
將數據存到CDN伺服器。CDN也是個中介，不過這個中介是根據中介的忙碌程度（CDN伺服器忙碌程度）、跟你的距離（CDN伺服器和你的距離）自動給你分配的。
4.瀏覽器緩存（ 我是個前端，只關注瀏覽器緩存。 ）
根據HTTP協議決定要不要緩存，以什麼方式緩存，緩存到哪（內存還是硬碟等）。

瀏覽器緩存是將瀏覽器請求過的數據（資源文件）保存到電腦上。需要再次使用的時候，直接從電腦上獲取保存的數據（資源文件），這就是瀏覽器緩存

1.減少網路請求，節省流量
2.減輕伺服器壓力
3.資源載入速度快了，前端性能就更好了

1.Server Worker
還沒搞懂，搞懂了再來寫。
2.Memory Cache
內存中的緩存，關閉頁面進程就釋放內存
3.Disk Memory
硬碟中的緩存，不主動清理就一直在

4、Push Cache
推送緩存，是HTTP/2的內容，並沒有嚴格執行HTTP頭部的緩存指令。在Server Worker、Memory Cache、Disk Cache都沒有命中的時候，它會被使用。在Session中存在，Session結束就會被釋放，緩存時間短暫。

1.先去內存查找，找到直接載入
2.內存找不到，硬碟中找，找到直接載入
3.硬碟找不到進行網路請求
4.把請求獲取的資源再緩存到硬碟和內存

1.強緩存
控制強制緩存的欄位分別是Expires和Cache-Control，Cache-Control優先順序比Expires高
-Expires設置一個絕對時間的GMT格式的時間字元串，這個是資源失效時間（ 客戶端的時間小於Expires的值，缺陷就是客戶端的時間被改變就有問題 ），在這個時間之前都直接讀取緩存。
-Cache-Control替代Expires，它利用的是相對時間，利用header信息欄位的max-age值判斷。
2.協商緩存
-Last-Modified/If-Modified-Since
Last-Modified:瀏覽器向伺服器發送資源最後的修改時間
If-Modified-Since:當資源過期時，發現響應頭具有Last-Modified聲明，則再次向伺服器請求時帶上頭if-modified-since，表示請求時間。伺服器收到請求後，發現有if-modified-since則與被請求資源的最後修改時間進行對比（Last-Modified）,若最後修改時間較新，說明資源又被改過，則返回最新資源，返回200；若最後修改時間較小，說明資源無新修改，返回304 ，使用緩存文件。
缺點:單位是秒，一秒內多次改變會認為沒過期
-ETag/If-None-Match
ETag:由伺服器生成返回給前端，幫助伺服器控制web端的緩存驗證，伺服器會生成並且返回當前資源文件的一個唯一標識
If-None-Match:當資源過期時，發現響應頭具有Etag聲明，則再次向伺服器請求時帶上頭if-none-match（唯一標識Etag值）。伺服器收到該請求後，發現有If-None-Match則根據If-None-Match的欄位值與該資源在伺服器的Etag值做對比，一致則返回304，代表資源無更新，繼續使用緩存文件；不一致則重新返回資源文件，狀態碼為200。

1.強緩存不發請求，協商緩存會發請求給伺服器確認有沒有過期
2.強緩存文件更新瀏覽器不知道，協商緩存更新瀏覽器能實時知道

1.點擊瀏覽器的刷新按鈕時，全部走緩存
2.F5或者滑鼠右鍵刷新強制緩存失效，不影響協商緩存
3.CTRL+F5影響強制緩存和協商緩存都失效

Ⅶ 以下哪些是http請求中瀏覽器緩存機制會用到的協議頭

你想下載哪一種嘛？我感覺手機用UC比較好。我一直用的UC

Ⅷ 求生之路系列（一）瀏覽器緩存機制

http可以說是現在前端領域（甚至整個互聯網）發展過程中使用最多的一個應用層協議。其傳輸層一般都是使用tcp協議來保證可靠傳輸的，由於tcp3次握手以及4次揮手的鏈接建立與斷開機制，導致每一次進行http請求所消耗的網路資源相對較大。。所以減少請求次數，合理的數據緩存成為互聯網開發的重中之重！！

尤其在前端領域，http緩存在加快網頁性能和為用戶節約網路資源。作為一名小前端，又恰好面試的時候又被問蒙蔽了。。就在這里對http緩存機制進行一個小小的總結吧~~

總的來說，瀏覽器要從伺服器上面真正的拿到數據還要通過下面幾關：

Cache-control是http響應頭的一個欄位。就是用來與客戶端約定響應的數據的緩存的有效時間。

在上圖中可以發現Cache-Control有一個max-age=691200的參數。這個就是表示該資源的最大生存時間為691200秒。 在這個時間過後才會再次向伺服器發出請求申請新的資源 ，否則直接使用本地資源。不過，就算生存時間過了，伺服器不會這么溫順地給你發新的資源（你說發就發豈不是很丟臉？？？），還會進一步的進行判斷，是否應該發送新的資源（看到後面就知道啦~）

除了max-age之外，Cache-Control還有別的參數可以選擇：

另外，瀏覽器的不同行為例如enter f5也會有不同的表現哦。（這個後面再總結吧~）

更多的介紹可以看看下面網路和幾位老哥的總結：

眼尖的盆友，可能會發現 上面的圖中還有一個Expires欄位，有些還有Pragma，其實這兩個都是個http1.0的舊產物，跟Cache-Control設置max-age是一個意思。由於Cache-Control是http1.1提出的，而且在http1.1甚至http2.0大行其道的今日，這兩個東西已經沒有作用了。當Cache-Control和上面兩個東西同時在http頭中存在時，優先使用Cache-Control。

注意：瀏覽器要發出請求必須要先在max-age時間過後（可以用ctrl+F5，來跳過這個檢查）。如果在一個時間內在發出請求，chrome的network會返回一個假200（其實是讀緩存的假請求2333333）。

一句話總結：Cache-Control是一個用於控制（告訴）客戶端，該響應的資源應該存哪裡，存多久。

當瀏覽器發現max-age（或其他）時間過後 ，瀏覽器就開始向伺服器請求獲取新的資源。但是伺服器並不會輕易的把新的資源返回給客戶端。

當瀏覽器第一次訪問某個網站，請求伺服器時，伺服器在返回的http響應頭中加入Last-Modified欄位，故名思意表示該資源最後一次修改是在某一個時間，如下圖

瀏覽器在收到了Last-Modified後，在以後的每一次請求中（請求頭）都會帶上一個欄位If-Modified-Since，這個欄位的值就是上一次收到的Last-Modified的值。

伺服器端則根據查看該資源是否在這個時間點後被修改過！！~如果沒有被修改過，則伺服器會返回304，表示資源未被修改過，使用緩存就可以了。否則如果有Etag則進行下一步判斷（後面說），沒有則200返回新資源。

Last-Modified 表面上非常靠譜，但是也存在一種情況，如果在伺服器上，一個資源被修改了，但其實際內容根本沒發生改變，會因為Last-Modified時間匹配不上而返回了整個實體給客戶端（即使客戶端緩存里有個一模一樣的資源）。

ETag是http1.1中為了解決上面問題的一個http欄位（一般是在響應頭裡面的）。這個ETag的值的什麼呢？一般是由伺服器根據資源的內容通過md5（或者其他）計算出的一個唯一標志。ok，瀏覽器得到這個東西之後，每次請求該資源的時候就會帶上這個值，這個值是放在請求頭的if-None-Match中，表示如果不匹配就給我新的吧，匹配就返回304~~

還有這個if-Match，這個我就不是很理解到底是什麼意思了。。。知道的朋友可以告訴我一下。。。
什麼是412錯誤，先決條件失敗是什麼意思。。

最後盜個圖：

另外，瀏覽器有多個刷新頁面的方法，下面來看看對緩存來說都有什麼區別吧（用chrome來測試，據說不同瀏覽器不同哦~）：

從上面圖中可以看出，這種形式的刷新頁面，是會判斷過期的（max-age）。。就是說是按整個緩存流程走下去。。

哇 好多304。。說明F5刷新頁面跳過了過期判斷（包括了max-age、expire等等），直接從ETage開始。。

全部200！！說明 這個是真·強刷·無雙！！從請求頭的圖中，可以看到瀏覽器是同配置Cache-Control: no-cache來叫伺服器重發請求的！~

第一次寫博客，各位老哥，給個面子，有錯就提出來哈~~

by the offer, of the offer, for the offer！！~~~

相關參考：