web優化是http緩存（上）

緩存做用

• 緩存能夠減小冗餘代碼數據傳輸，節省網絡費用

• 緩解網絡瓶頸問題。不須要更多寬度就能加載頁面

• 下降原始服務器請求。服務器能夠更快響應，避免過載出現

• 下降距離延遲。從較遠地方加載頁面更快一些
  總結：從網絡費用，寬帶，過載，距離幾方面改善優化。

冗餘代碼

解決在同時擁有不少客戶對同一資源請求，服務器反覆發送相同的東西，壓力會很大，可是若是作了緩存，就會保留一份副本。這樣減小了重 複流量。

寬帶瓶頸

寬帶瓶頸，不少網絡爲本地網絡客戶端提供寬帶比原車的服務器寬帶要寬。而客戶端呢會以路徑最慢的網速訪問服務器，其實就是按最小的瓶頸。

若是有了緩存備份，那就不須要通過小口徑，直接大口徑用吧。這對於傳輸大文件很是有利，好比一個pdf大文件，若是每次都須要去服務器下載，那消耗是很大的。

距離問題

我老家從上海服務器下載個5mb庫存文件可能要花幾十秒，可是若是作了緩存，下次訪問只須要幾秒。本地以太網牛逼啊。距離越長寬帶傳輸延遲越長。

每臺路由都會增長流量延遲，就算沒有路由，光速自己也有延遲。緩存能夠很好的環境這種問題。
世界上最遙遠的距離不是生與死，而是想上廁所卻找不到廁所。

瞬間擁塞

多數由於爆炸性新聞，視頻啊，熱門的消息，不少人一塊兒訪問這個文檔，就可能會出現瞬間擁塞。這個峯值達到最高時候，服務器可能會直接崩潰。 好比當年克林頓被調查的新聞，服務器在當時以每小時收到超過三百萬的請求量，是其平均值50倍，能不癱瘓嗎，頭皮發麻。就像這汽車堵塞同樣，看到就心煩，壓根動不了了。

緩存命中和未命中

緩存沒法保存世界上每一份文件的副本，那麼能夠用已有的副原本達到緩存請求服務的，這種叫作緩存命中，而相反的沒用副本可用，進而轉發到原始服務器的，叫作緩存未命中。

在驗證

原始服務器內容可能會更新，發生變化，這時候就要進行更新緩存，因此緩存要不時的進行檢測。爲了有效的進行在驗證，http定義了一些特殊請求，不用從服務器獲取完整對象，就能夠快速檢測是否是最新的。在緩存對緩存副本在驗證時候，向原始服務發送一次請求，若是內容沒有變化，服務器返回一個304表示副本仍然有效。這種在驗證命中比直接未命中仍是要快一些。

對已緩存對象進行在驗證的工具

http 中 If-Modified-Since 首部。將這個首部信息添加到get裏，就能夠告訴服務器若是內容更新了，纔像客戶端返回此對象。

• 服務器內容未修改 304未修改
• 服務器內容修改 200以修改而且發送完整內容 更新緩存副本
• 服務器資源以刪除 刪除 404 緩存副本以刪除

命中率

緩存命中率是說緩存比例，40%的命中率比較合理。

字節命中率

此標準是數據很能反應一個服務的緩存性能優劣

緩存我的和共享

• 我的專業緩存稱爲私人緩存，私有緩存不須要多少存儲空間，瀏覽器有內建緩存，或者我的電腦磁盤內存。
• 數千名用戶共享團體緩存稱爲共享緩存，共有的被稱爲緩存代理服務器或者叫作代理緩存。

代理緩存的層級結構

核心思想就是在靠近客戶端的地方使用小型廉價緩存，而高層次中，距離服務器越近的地方使用更大功能更強緩存更多用戶共享的文檔。因此若是url請求過程當中可能要經歷幾級緩存的查找。若是一級沒有命中緩存，那麼二級查找可能會有。以此類推。這種層級有好處也有壞處，層級過深，那麼可能每次查找信息，若是正好在最後一級纔有命中文件，那就慘了，若是最後都沒有，那更慘了。

網狀緩存，內容路由以及對等緩存

網狀緩存比層級緩存更復雜，下半部分在寫，腦子有點累。

緩存的處理步驟

• 接收-緩存從網絡中讀取抵達的請求報文。
• 解析-對保溫進行解析，提取url和各類首部
• 查詢-查詢是否有本地副本可用，若是有獲取副本
• 新鮮度檢測-緩存是否新鮮的檢查若是不是九更新
• 建立想要-緩存用新的首部和以緩存的主體來構建一條響應報文、
• 發送-經過網絡響應發揮給客戶端
• 日誌-建立一個日誌文件夾來描述本次事務

1. 接收
   在第一步中，緩存檢測到一條網絡鏈接上的活動，讀取輸入數據。 高性能的緩存會同時從多條輸入鏈接上讀取數據，在整條報文抵達以前開始對事務進行處理。
2. 解析
   緩存將請求報文解析爲片段，將首部的各個部分放入易於操做的數據結構中。這樣，緩存軟件就更容易處理首部字段並修改它們了。 解析程序還要負責首部各部分的標準化，將大小寫或可替換數據格式之類不過重要的區別都看做等效的。並且，某些請求報文中包含有完整的絕對 URL，而其餘一些請求中包含的則是相對 URL 和 Host 首部，因此解析程序一般都要將這些細節隱藏起來。
3. 查詢
   緩存獲取了 URL，查找本地副本。本地副本可能存儲在內存、本地磁盤，甚至附近的另外一臺計算機中。 專業級的緩存會使用快速算法來肯定本地緩存中是否有某個對象。若是本地沒有這個文檔，它能夠根據情形和配置，到原始服務器或父代理中去取，或者返回一條錯誤信息。 已緩存對象中包含了服務器響應主體和原始服務器響應首部，這樣就會在緩存命中時返回正確的服務器首部。 已緩存對象中還包含了一些元數據(metadata)，用來記錄對象在緩存中停留了多長時間，以及它被用過多少次等。 複雜的緩存還會保留引起服務器響應的原始客戶端響應首部的一份副本，以用於 HTTP/1.1 內容協商。
4. 新鮮度檢測
   HTTP 經過緩存將服務器文檔的副本保留一段時間。在這段時間裏，都認爲文檔是「新鮮的」，緩存能夠在不聯繫服務器的狀況下，直接提供該文檔。 一旦已緩存副本停留的時間太長，超過了文檔的新鮮度限值(freshness limit)，就認爲對象「過期」了，在提供該文檔以前，緩存要再次與服務器進行確認，以查看文檔是否發生了變化。 客戶端發送給緩存的全部請求首部自身均可以強制緩存進行再驗證，或者徹底避免驗證，這使得事情變得更加複雜了。 HTTP 有一組很是複雜的新鮮度檢測規則，緩存產品支持的大量配置選項，以及與非 HTTP 新鮮度標準進行互通的須要則使問題變得更加嚴重了。
5. 建立響應
   咱們但願緩存的響應看起來就像來自原始服務器的同樣，緩存將已緩存的服務器響應首部做爲響應首部的起點。而後緩存對這些基礎首部進行了修改和擴充，以便與客戶端的要求相匹配。 好比：服務器返回的多是一條 HTTP/1.0 響應(甚至是 HTTP/0.9 響應)，而客戶端期待的是一條 HTTP/1.1 響應，在這種狀況下，緩存必須對首部進行相應的轉換。 緩存還會向其中 插入新鮮度信息(Cache-Control、Age 以及 Expires 首部)，並且一般會包含一個 Via 首部來講明請求是由一個代理緩存提供的。 注意：緩存不該該調整 Date 首部。Date 首部表示的是原始服務器最初產生這個對象的日期。
6. 發送
   一旦響應首部準備好了，緩存就將響應回送給客戶端。 和全部代理服務器同樣，代理緩存要管理與客戶端之間的鏈接。 高性能的緩存會盡力高效地發送數據，一般能夠避免在本地緩存和網絡 I/O 緩衝區之間進行文檔內容的複製。
7. 日誌
   大多數緩存都會保存日誌文件以及與緩存的使用有關的一些統計數據。 每一個緩存事 務結束以後，緩存都會更新緩存命中和未命中數目的統計數據(以及其餘相關的度量值)，並將條目插入一個用來顯示請求類型、URL 和所發生事件的日誌文件。 最多見的緩存日誌格式爲 Squid 日誌格式和網景的可擴展通用日誌格式，但不少緩存產品都容許用戶建立自定義的日誌文件。
8. 緩存處理流程圖
   以簡化形式顯示了緩存是如何處理請求以 GET 一個 URL 的：

   

參考：http權威指南，本着學習的目的記錄下來，有時候寫這些也是迫於常常有人問，而本身記憶又不好，不少時候確實想不起來了，本着之後能夠翻翻看的想法記錄下來。