緩存動態內容的反向代理

Question

我正在考慮詢問軟件建議 ，但后來我發現它可能是一個太奇怪的請求，它需要先澄清一些。

我的觀點是：

• 每個回復都包含一個etag
  • 這是內容的哈希
  • 哪個是全球唯一的（有足夠的概率）
• 內容（大部分）是動態的，並且可能隨時更改（此處的expires和max-age標頭無用）。
• 內容部分依賴於用戶，由權限（有時本身會改變）給出。

基本上，代理應包含將etag映射到響應內容的緩存。 etag從服務器獲得，在最常見的情況下，服務器根本不處理響應內容。

它應該如下所示：代理總是向服務器發送請求然后

• 1服務器僅返回etag ，代理根據它進行查找
  • 1.1關於緩存命中，
    • 它從緩存中讀取響應數據
    • 並向客戶發送回復
  • 1.2關於緩存未命中，
    • 它再次詢問服務器
    • 服務器返回帶有內容和etag的響應，
    • 代理將其存儲在緩存中
    • 並向客戶發送回復
• 2或服務器返回帶有內容和etag的響應，
  • 代理將數據存儲在其緩存中
  • 並向客戶發送回復

為簡單起見，我省略了if-none-match標頭的處理，這很明顯。

我的理由是，最常見的情況1.1可以在服務器中非常有效地實現（使用其緩存映射請求到etags ;內容不緩存在服務器中），這樣大多數請求都可以在沒有服務器處理的情況下處理與響應內容。 這應該比首先從側緩存獲取內容然后提供它更好。

在案例1.2中，有兩個對服務器的請求，這聽起來很糟糕，但並不比服務器要求側緩存和錯過更糟糕。

Q1：我想知道，如何將第一個請求映射到HTTP。 在案例1中，它就像一個HEAD請求。 在案例2中，它就像GET。 兩者之間的決定取決於服務器：如果它可以在不計算內容的情況下為etag服務，那么它就是情況1，否則就是情況2。

Q2：是否有反向代理做這樣的事情？ 我讀過有關nginx，HAProxy和Varnish的內容，但似乎並非如此。 這讓我想到Q3：這是個壞主意嗎？ 為什么？

問題4：如果沒有，那么哪個現有代理最容易適應？

一個例子

來自用戶U1 /catalog/123/item/456的GET請求與一些內容C1和etag: 777777 。 代理存儲C1下的關鍵777777 。

現在相同的請求來自用戶U2 。 代理轉發它，服務器只返回etag: 777777並且代理很幸運，在其緩存中找到C1 （情況1.1 ）並將其發送到U2 。 在此示例中，不是代理的客戶端都不知道預期結果。

有趣的是，服務器如何在不計算答案的情況下知道etag 。 例如，它可以有一條規則，聲明此表單的請求為所有用戶返回相同的結果，假設允許給定用戶查看它。 因此，當來自U1的請求到來時，它計算出C1並將etag存儲在key /catalog/123/item/456 。 當同一個請求來自U2 ，它只是驗證了允許U2查看結果。

Answer 1

Q1 ：這是一個GET請求。 服務器可以使用“304未修改”來回答沒有正文。

Q2 ： openresty （帶有一些額外模塊的nginx）可以做到，但你需要自己實現一些邏輯（參見下面的更多詳細說明）。

問題3 ：鑒於您問題中的信息，這聽起來是一個合理的想法。 只是一些值得思考的東西：

• 您還可以將頁面拆分為可以獨立緩存的特定於用戶和通用的部分。

• 您不應期望緩存永遠保留計算的響應。 因此，如果服務器返回304 not modified使用etag: 777777 304 not modified的304 not modified etag: 777777 （根據您的示例），但緩存不知道它，您應該有一個選項強制重新構建答案，例如使用另一個請求自定義標題X-Force-Recalculate: true 。

• 不完全是您的問題的一部分，但是：確保設置正確的Vary標頭以防止緩存問題。

• 如果這只是關於權限，您也可以使用簽名cookie中的權限信息。 緩存可以在不詢問服務器的情況下從cookie中獲取權限，並且由於簽名，cookie是防篡改的。

Q4 ：我會使用openresty，特別是lua-resty-redis模塊 。 將緩存的內容放入redis鍵值存儲中，並將etag作為鍵。 你需要在Lua中編寫查找邏輯代碼，但它不應該超過幾行。