反向代理與重定向vs獲取url

Question

我有兩臺服務器（都可公開訪問）。第一個是圖像存儲服務器。第二個生成指向圖像存儲服務器上的圖像的鏈接（用node.js編寫的小腳本）。

我有一個前端網頁，需要從圖像存儲服務器加載照片。爲了這樣做，它需要聯繫「鏈接生成」服務器才能獲得鏈接。

有3種方式我想這樣做的：在一個data-src標籤

1. 存儲圖像ID數據爲<img>的一部分，而不是src標記，以便瀏覽器不嘗試加載它作爲一個圖像。然後讓一些javascript函數使用圖像ID來ping鏈接生成服務器，檢索實際圖像鏈接，然後將其放置在src標記中。

2. 使鏈接生成服務器重定向到適當的圖像鏈接，而不是將鏈接作爲文本返回，以便帶有圖像ID的圖像生成服務器的鏈接可以放置在src標記中，並且瀏覽器將通過重定向。 （我假設圖像可以通過重定向來解析？）

3. 使鏈接生成服務器成爲反向代理，它將自動加載生成的圖像，然後將圖像傳回，而不是將鏈接作爲文本返回。同樣，帶圖像ID的圖像生成服務器的鏈接將被放置在src標記中，並且不需要特殊的JavaScript來解析圖像。

---

我的問題是：是在圖像的加載速度和「緩存能力」方面的這些比其他更理想的任何一個？到目前爲止，我發現重定向方法更爲理想，因爲它很乾淨，並且不需要任何特殊的JavaScript。但是使用這種方法（如果它甚至可行），最終的圖像將無法緩存在瀏覽器中，以便隨後重新加載頁面，因爲瀏覽器將始終解析重定向以實際獲得最終圖像鏈接？

非常感謝！

Answer 1

既然你大概控制了圖像服務器和鏈接生成器，我會建議將它們組合成一個單一的網絡服務。基本上，就像選項＃3一樣，無論是通過使用反向代理還是將兩個服務器應用程序組合到一個應用程序中，這可能會更具性能（每個圖像負載的HTTP請求少一個）。在我看來，這是一個更優雅的解決方案，創建一個簡單的圖像Web服務，而不涉及客戶端/瀏覽器中的重定向和多個HTTP請求。

關於圖片src的URL，是的，他們可以通過重定向來解決，如果緩存頭是正確的，瀏覽器會緩存重定向URL的圖像。 301重定向也可緩存，並使用正確的緩存標頭。再一次，這種方法似乎更像是一項服務，但業務成本最終可能會受到影響。

總之，我會遠離＃1，因爲它會在客戶端上正確使用映像服務。無論你選擇2號還是3號，都應該取決於立即開發成本和長期維護成本。