反向代理与重定向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号，都应该取决于立即开发成本和长期维护成本。