相信熟悉 Http 協議的人都了解，在 Response Headers 中傳回 Cache-Control 的參數，可以實現客戶端的緩存，當然僅僅用客戶端緩存，大多數時候其實不能滿足要求，要更好的交互，更快的接口響應，大多數時候會在服務端加入緩存。

Nginx Module

這里以 Nginx ngx_http_fastcgi_module 為例子,具體描述下服務端使用緩存的例子。

set $cache_key $request_uri;

fastcgi_cache_path /var/tmp/nginx-cache levels=1:2 keys_zone=cache_zone:64M;

fastcgi_cache cache_zone;

fastcgi_cache_key $cache_key;

fastcgi_cache_lock on;

fastcgi_cache_lock_age 3s;

fastcgi_cache_lock_timeout 3s;

本例子是以 reqest_uri 作為 cache key。在服務端接收到相同的 request_uri 的時候，會直接在 ngx_http_fastcgi_module 這個模塊中將緩存的數據直接 return。

Vary

根據上述使用 request_uri 作為緩存的 key，很大程度可以緩解接口性能問題。但是同樣會衍生出一個問題。其實 ngx_http_fastcgi_module 這個模塊的緩存，會將整個 Response 的全部信息緩存進去，所以能預想到 Response header 的 access-control-allow-origin 這個頭部會別緩存成起來，而根據業務邏輯不同，大多數業務系統都只會對 Request 的 Origin 進行單獨簽發。

這種情況下就可能會造成同一個接口，在不同 Host 請求時，某些域名會出現跨域，而且過一段時間后又好了的玄學問題。為了解決這一情況，最快捷的做法是設置 cache_key 前綴。即改為：

set $cache_key $http_origin/$request_uri;

但是其實緩存空間是有限的，我們通過對 cache_zone 的設置為 64M，所以更改 cache_key 的快速解決方案似乎不是最優解。所以這里在 Response Header 中加入 Vary

Vary: Origin

我們在響應的時候，將 Vary 加入響應的頭部，解決了問題。

Nginx Vary 的探究

Vary 很方便地解決了服務端緩存 Origin 的問題，但是衍生出一個問題。服務端緩存的目的是為了實現更少請求到達業務層，同一個接口下，通過校驗 Origin ，不是當前緩存成功的 Origin 會擊穿緩存到達業務層，而業務層再對該請求處理，重新包裝 access-control-allow-origin 后重新被 Nginx 緩存。周而復始，似乎反而沒有起到該有的緩存效果。

為了確認 Vary 方案是否跟上述所想相同，查閱了相關文檔。

If the header includes the "Vary" field with the special value "*", such a response will not be cached (1.7.7). If the header includes the "Vary" field with another value, such a response will be cached taking into account the corresponding request header fields (1.7.7).

根據文檔,即緩存會考慮相應的請求頭字段，對緩存進行管理。那么其實原理就跟在 cache key 中加入前綴是一樣的。

總結

不管是更改 cache key 還是修改利用 Vary 都是實現一樣的效果，且會占用內存。筆者認為在單系統中，兩種方式其實都是可行的，排除掉惡意攻擊，在既定的 origin 情況下，其實內存是不會占用多少，不管是更改 cache key 前綴或者使用 Vary。

本作品采用《CC 協議》，轉載必須注明作者和本文鏈接

總結

以上是生活随笔為你收集整理的php http 缓存,HTTP 缓存中的 Vary的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。