1.1 緩存解釋
緩存通常是基於鍵值對來緩存的，鍵通過hash計算後，存放於內存某個空間，所以鍵可以理解爲索引。而值是存放在內存空間或是磁盤空間上。
當用戶的用戶請求送達至Web服務器，Web服務器會對URL進行hash計算，然後比對緩存（hash表）中的鍵。如若命中，則根據與之對應的值找到數據存放的位置（這裏的值可以理解爲指針，指着對應數據存放的位置），從而獲取到緩存的結果。
1.2 工作原理
1.2.1 緩存命中
① 客戶端請求某個Web數據，會先送至緩存服務器中，緩存服務器本身會監聽80號端口接收用戶請求
② 當Web緩存服務器收到用戶請求之後，會將這個請求送達至代理進程中
③ 進程拆除用戶請求報文中的應用層首部，TCP首部，IP首部等，從而獲取到請求報文中的URL
④ 對URL進行hash計算，然後和緩存服務器中hash表中的緩存鍵進行比對，若一致則緩存命中
⑤ 在對應的值所指向的內存或硬盤空間上找到對應的內容數據
⑥構建成響應報文，直接返回給客戶端
1.2.2 緩存未命中
① 客戶端請求某個Web數據，會先送至緩存服務器中，緩存服務器本身會監聽80號端口接收用戶請求
② 當Web緩存服務器收到用戶請求之後，會將這個請求送達至代理進程中
③ 進程拆除用戶請求報文中的應用層首部，TCP首部，IP首部等，從而獲取到請求報文中的URL
④ 對URL進行hash計算，然後和緩存服務器中hash表中的緩存鍵進行比對，不一致則緩存未命中
⑤ 代理服務器會自行封裝成請求報文，把自己當做http的客戶端，向上遊服務器發起請求
⑥ 若內容存在，上游服務器會構建成響應報文，返回給代理服務器。
⑦ 當代理服務器收到響應之後，會檢查該對象是否可以緩存，如若可以，會對URL進行hash之後生成一個鍵，存放到對應的hash表中
⑧ 在相應的內存或磁盤空間上存儲對應的內容數據
⑨ 當操作完成之後，會將數據構建成相應報文，然後響應給客戶端
1.3 擴展
在用戶自己內部的瀏覽器會有自己的緩存(私有緩存），當用戶請求一個首頁的時候，會向代理服務器請求，之後緩存在本地的一些鏈接或者圖片，如果在本地存在緩存，那麼就直接響應給用戶，而無需再向代理服務器請求。所以我們的緩存是有存在多級的
二、緩存失效
現在存在一個問題，那就是如果我們的緩存失效了應該如何處理，正常而已如果緩存過期了，我們應該不再使用此緩存。所以緩存是具有TTL（生命時間值）值的，當這個TTL值過期之前，我們可以正常使用此緩存對象，一旦過期，請求一方就只能到比他更高一級的下一層緩存中的後端服務器去請求資源。
假設某個緩存對象可以緩存7天，但是在第2天，後端服務器已經修改了此對象，那麼此時應該如何處理。所以用戶如果直接從緩存中獲取到的數據就已經不是最新的了。這樣可能會導致緩存有效期過期之前用戶將無法獲取有效的結果。那麼如果處理呢？
2.1 緩存的方式
基於絕對時間緩存
在http 1.0時使用的是絕對時間來緩存，可以理解精準的時間算法
基於條件式緩存
到 1.1版本以後，對其緩存功能進行了擴展，引入了幾種功能
1、引入相對時長過期時間
2、引入強大可緩存對象控制功能（哪些數據能緩存以及不能緩存）
3、引入條件式緩存
2.2 基於絕對時間
比方說，此次緩存時爲中國時區的2016年7月3日9:00 緩存的，緩存的TTL值爲7天，那麼過期時間應該就是 7天之後（2016年7月10日）9:00 過期，但是如果是在美國，或者歐洲，因爲時區的不同，使用絕對時間將會導致緩存緩存不
2.3 基於條件式緩存
基於最後一次緩存時間後詢問式驗證請求
當用戶訪問同一個URL時，會發現在自己的緩存空間中存在一個相同的緩存對象，此時他不會了立即使用此緩存，而是去向上游服務器去驗證這個緩存是否過期。主動向服務器發起驗證請求，去請求一個URL，而且會發一個獨特的請求首部（If-Modified-Sinces：time），詢問在此時間之後（也就是緩存對象建立的時間之後），你是否發生了修改。如果後端服務器發現此資源未修改，會響應304（原始數據未修改）的響應碼，由於資源未改變，所以此處發送的僅僅是響應碼，數據無需發送。當客戶端接收到響應後，就會直接使用本地的緩存。
如果後端服務器發現此資源已經修改，那麼會找到對應的資源，然後發一個200（原始數據已修改）的響應碼，並將資源發送給客戶端。當客戶端接收到後，會替換原先緩存下來的結果，並在瀏覽器上進行顯示。
但是基於時間來記錄判定其實並不理想，假設用戶發驗證時，而你的服務器時間並未到那個時間，那麼就會無法驗證緩存時間了。
基於標籤(tag)進行條件式請求
在服務器端，每一個文件、或者是資源，每次版本修改之後都會附帶一個tag（這個tag可能是一個隨機生成的數，所以可以理解具有唯一性）。當用戶請求資源後，會發送一個獨特的請求首部（If-None-Match：tag），會將本地緩存的tag發送給服務器端，詢問資源的tag是否匹配，匹配則資源未改變，響應304響應碼，否則資源已改變，響應200響應碼。
所以這樣就不會擔心基於時間記錄時所產生的各種問題。
三、HTTP的緩存工作模式
3.1 基於緩存過期時間
1、當用戶第一次訪問資源時，緩存服務器不存在對應的緩存對象，那麼此時緩存服務器會向後端服務器請求數據，後端服務器會數據響應給緩存服務器，並附帶Cache-Control首部信息，表示緩存的時間。然後緩存服務器會將數據緩存於本地，然後將數據響應給客戶端。
2、當客戶端再次請求同一個資源時，如果緩存時間未到期，那麼此時緩存服務器會直接將用戶請求的資源直接響應給客戶端。
3、如果當客戶端請求資源時發現緩存服務器裏的緩存週期已過期，那麼此時緩存服務器會向後端請求資源，並將信息資源緩存於本地，而此時也更新了緩存的TTL值，然後響應給客戶端。
3.2 基於條件式緩存
1、當客戶端第一次請求資源時，由於緩存服務器並沒有響應的緩存資源，那麼此時緩存服務器會向後端服務器發起資源請求。當後端服務器收到請求後，會響應緩存服務器的請求，並附帶Last-Modified：time的首部信息，緩存服務器會將資源及Last-Modified信息緩存於本地，然後一同也將這些信息響應給客戶端。
2、客戶端發起資源請求，如果緩存服務器有對應的資源緩存條目，但是此時客戶端不會直接使用，而是發送了If-Modified-Since：time請求首部給後端服務器，來詢問是否數據未修改。如數據未修改，會返回304的響應碼，那麼此時客戶端會直接使用緩存服務器裏的資源。
3、類似上面的方法，但是如果後端服務器響應的是200（數據已修改）的響應碼時，那麼緩存服務器會接受下這段響應信息，並將數據緩存於本地，然後再講資源 + Last-Modified響應信息發回給客戶端。
3.3 組合應用HTTP首部
根據上面的介紹，我們知道，如果基於時間來判斷，可能會導致數據不準確的情況。而使用基於條件式的緩存可以彌補基於時間的不足，但是它自身還有一個缺點，那就是需要不斷的去詢問後端服務器的數據。這樣就消耗佔用了後端服務器的資源以及帶寬。所以我們可以使用基於兩種方式的合併來完成緩存失效判斷。
1、第一次用戶訪問，那麼類似前面介紹的方法，不同的是，此時緩存服務器會記錄 Etag信息和 Cache-Control信息。
2、如果客戶端請求的相同的資源，如果緩存未過期，那麼此時使用的仍然是緩存服務器上的資源。
3、當緩存服務器的資源已失效，那麼客戶端會向後端服務器發起If-None-Match：Etag請求首部，向後端服務器確認資源是否已被修改，如果資源未修改，此時服務器會響應304（資源未修改）的響應碼，那麼緩存服務器會更新TTL值，並響應給客戶端。