在webkaka的網(wǎng)站速度診斷性能優(yōu)化里有一項叫指定“Vary:Accept-Encoding”標(biāo)頭,可能很多人不太明白這是什么意思,不知道它對網(wǎng)站的影響有多大,不知道如何進(jìn)行優(yōu)化,為此,本文將給大家闡述下“Vary:Accept-Encoding”標(biāo)頭的意義以及設(shè)置方法。
指定“Vary:Accept-Encoding”標(biāo)頭
指定“Vary: Accept-Encoding”標(biāo)頭的意義
指定“Vary: Accept-Encoding”標(biāo)頭,用一句話來說明它的意義,就是“告訴代理服務(wù)器緩存兩種版本的資源:壓縮和非壓縮,這有助于避免一些公共代理不能正確地檢測Content-Encoding標(biāo)頭的問題。”不過我想很多人都不理解這句話是什么意思,所以需要更詳細(xì)的解釋。
先來看看下面這幅圖:
網(wǎng)頁從請求到響應(yīng)的過程
這個圖顯示了一個網(wǎng)頁從請求到響應(yīng)的過程。正常情況下,“Response”的結(jié)果是可讀文本,但并不是所有的服務(wù)器端都返回這樣的正常的結(jié)果到用戶端,有的返回一堆亂碼,這顯然是不正常的。
當(dāng)瀏覽器發(fā)出一個請求時,會包含一些HTTP頭信息,服務(wù)器會根據(jù)這些頭信息決定返回什么樣的東西(這是一個移動客戶端嗎?它能否處理壓縮內(nèi)容?它是否需要特定的語言支持?)。
直接訪問是好的,但現(xiàn)在網(wǎng)絡(luò)使用了中間高速緩存(cache)和內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)。這就產(chǎn)生了一個問題,緩存如何使用頭信息決定返回什么?它能否復(fù)制服務(wù)器端的決策邏輯?
“Vary”解決了這個問題,“Vary”頭描述什么信息“唯一地”標(biāo)識一個請求——傳入的請求只有完全匹配緩存的“Vary”信息,緩存才被使用。
假如沒有“Vary”頭,那么如果由于某種原因,客戶端有一個未壓縮的版本在其緩存中的文件,它會不知道隨后再次要求它的壓縮版本,而不是只從緩存中使用未壓縮的文件。——這就很好的解釋了“Vary”頭信息的重要意義。
設(shè)想有兩個客戶,一個使用的舊瀏覽器不支持壓縮,一個使用新的瀏覽器支持壓縮,如果他們都請求同一個網(wǎng)頁,那么取決于誰先請求,壓縮或非壓縮版本便存儲在CDN上。這樣問題就出現(xiàn)了,舊瀏覽器請求常規(guī)網(wǎng)頁但獲得緩存的壓縮版本,而新瀏覽器會獲得緩存的非壓縮版本但嘗試去“解壓”它。無論哪種方式都是壞消息。解決方法是,源服務(wù)器回送“Vary: Accept-Encoding”。
現(xiàn)在的中間CDN會存儲獨(dú)立的緩存條目,一個是Accept-encoding: gzip ,而如果你沒有發(fā)送header,則存儲另一個。
標(biāo)頭“Vary:Accept-Encoding”指定方法
現(xiàn)在的新瀏覽器都支持壓縮了,因此如果網(wǎng)站啟用了GZip,可以無需再指定“Vary: Accept-Encoding”標(biāo)頭,不過指定“Vary: Accept-Encoding”標(biāo)頭會有更高的保險,而它并不需要你額外的開銷,為什么不指定呢?下面是設(shè)置方法:
Apache/.htaccess
<IfModule mod_headers.c>
<FilesMatch ".(js|css|xml|gz|html)$">
Header append Vary: Accept-Encoding
</FilesMatch>
</IfModule>
Nginx
gzip_vary on
IIS
在web.config里加上如下配置,web.config位置在:%windir%\Microsoft.NET\Framework\.net版本號\CONFIG\Web.config 。
<system.webServer>
<httpProtocol>
<customHeaders>
<remove name="Vary"></remove>
<add name="Vary" value="Accept-Encoding"></add>
</customHeaders>
</httpProtocol>
</system.webServer>
指定“Vary:Accept-Encoding”標(biāo)頭,網(wǎng)站需要啟用GZip,才變得有意義。網(wǎng)站如何啟用GZip?可以看看如下的教程:
相關(guān)文章
IIS啟用GZip失敗之原因:臨時目錄權(quán)限沒設(shè)好