清漆+靜態HTML頁面

Question

我最近遇到了一個名爲Varnish的http網絡加速器。從我讀過的內容看，Varnish通過使用反向代理配置優化與HTTP服務器的每個HTTP通信過程來加速網站的交付。

我的問題是，如果您有一個網站的緩存機制一直配置爲靜態html文件，那麼Varnish會對此產生多大影響？反向代理是否減少了HTTP服務器執行的處理請求的工作？如果你已經在服務器端廣泛地緩存了所有內容（HTTP標頭，Etags，Expires Headers，Database Caching，Fragment和Page caching），那麼HTTP加速器會做些什麼來改進呢？ HTTP緩存和服務器端緩存：

Answer 1

首先，我們應該在一個正常的網絡系統走在兩個不同類型的緩存之間進行區分。

HTTP緩存由HTTP報頭的控制，特別是當你指出ETag和各種期滿機制（包括Expires和Cache-Control各個方面）。這全部包含在RFC 2616 (HTTP), section 13中，並且允許HTTP 高速緩存返回來自客戶端的HTTP請求的響應，而無需返回到原始服務器。實際上，在某些情況下，HTTP緩存機制允許客戶端和服務器之間的另一臺機器充當服務器的角色。這實際上就是清漆的功能，正如我們稍後會看到的;許多人熟悉的另一個常見用途是當ISP在其網絡中提供HTTP緩存時，它們通常可以比其網絡外的原始服務器更快地對其訂戶作出響應（並因此提高感知性能）。

服務器端緩存包括數據庫高速緩存，以及片段和頁面緩存，這是真正的Web服務器，避免做一些昂貴的操作都只是方式（比如，數據庫查詢，或使一個模板的特定部分）做一次，然後將結果保存在緩存中一段時間​​。

我剛纔說清漆是一個HTTP緩存，這意味着即使是靜態文件，它也可以比Web服務器更有效。考慮一下Web服務器必須做：

1. 解析HTTP請求
2. 的URI（以及任何相關的請求頭，如Accept-Encoding）映射到一個文件
3. 拉起關於建立文件信息響應中的HTTP標頭;這些公知爲實體頭（RFC 2616 section 7.1，其包括諸如Content-Length，Content-Type和在HTTP緩存使用的Expires和Last-Modified頭）
4. 弄清楚什麼額外響應頭（RFC 2616 section 6.2;這些包括ETag和Vary， （）HTTP緩存的兩個重要份）和一般報頭字段RFC 2616 section 4.5需要
5. 寫入HTTP狀態行和首部到網絡
6. 寫該文件的內容到網絡

通過比較，清漆是所有這一切的上游，因此，所有它必須要做的是：

1. 解析HTTP請求
2. 映射URI （和任何相關的請求標頭）到其內部緩存中的條目上
3. 查看是否有條目;如果有，請將其寫入網絡; HTTP標頭將被存儲在緩存中

如果沒有一個條目，清漆做一些更多的工作：

連接到Web其背後的服務器將通過在第一個列表1-6生成響應

寫入網絡的響應，其中包括所有的HTTP報頭中的所有步驟來運行

存儲在其高速緩存中的響應

特別是因爲HTTP頭和實體主體（整個響應）可以通過varnish進行緩存，所以如果它可以從緩存中提取，那麼它的工作量就會減少。當您在服務器中動態生成響應時，差異會變得更加明顯：假設您有一個需要5秒鐘生成的頁面，但每個用戶點擊您的網站都是一樣的，清漆應該能夠在從緩存中取出大部分毫秒（加上通過網絡向HTTP客戶端獲取響應所需的時間），並且有一個簡潔的機制（grace period），因此它可以在一次點擊後端服務器的同時繼續執行以刷新緩存的頁面版本。

當然，您可以引入服務器端緩存來提高Web服務器處理請求的速度，但是如果您有響應，則可以緩存清漆，但通常會更快。 （有各種各樣的東西難以在清漆中緩存，特別是如果您使用的是Cookie或具有根據用戶查看的頁面而改變的頁面。雖然在這些情況下可以繼續使用清漆，除非您需要真正令人難以置信速度，據我所知大多數人開始優化這些案件之前使用服務器端緩存和其他技術，然後點擊清漆。）

（請注意，清漆也可以編輯標題以及進出緩存的數據，這會使事情變得複雜化，但主要觀點仍然存在，即使在飛行清漆上進行編輯的速度也非常快）。