反向代理，重定向，获取url

Reverse proxy vs redirect vs fetch url

本文关键字：获取 url 重定向代理更新时间：2023-09-26

我有两个服务器(都可以公开访问)。第一个是映像存储服务器。第二个生成链接(用node.js编写的小脚本)，这些链接将指向图像存储服务器上的图像。

我有一个前端网页，需要从图像存储服务器加载照片。为了做到这一点，它需要联系"链接生成"服务器以获得链接。

我想有三种方法来做这件事:

将图像ID数据存储在data-src标记中，作为<img>的一部分，而不是src标记，因此浏览器不会尝试将其作为图像加载。然后让一些javascript函数用图像ID ping链接生成服务器，检索实际的图像链接，然后将其放在src标记中。
使链接生成服务器重定向到适当的图像链接，而不是以文本形式返回链接，以便将带有图像ID的图像生成服务器链接放置在src标记中，浏览器将通过重定向解析图像。(我假设图像可以通过重定向解决?)
使链接生成服务器成为一个反向代理，它将自己加载生成的图像，然后将图像传递回来，而不是将链接作为文本返回。同样，带有图像ID的到图像生成服务器的链接将放在src标签中，不需要特殊的javascript来解析图像。

我的问题是:在图像加载速度和"缓存能力"方面，其中任何一个比另一个更可取吗?到目前为止，我认为重定向方法是更可取的，因为它干净，不需要任何特殊的javascript。但是有了这样的方法(如果它甚至工作)，最终的图像将无法在浏览器中缓存，以便随后重新加载页面，因为浏览器将始终解析重定向以实际获得最终的图像链接?

非常感谢!

既然您可能已经控制了图像服务器和链接生成器，我建议将它们合并到一个web服务中。本质上，就像选项#3一样，无论是通过使用反向代理，还是通过将两个服务器应用程序合并为一个应用程序，这将潜在地提高性能(每次图像加载减少一个HTTP请求)。在我看来，这是一个更优雅的解决方案，创建一个单一的、简单的图像web服务，而不涉及客户端/浏览器中的重定向和多个HTTP请求。

关于图像src URL，是的，它们可以通过重定向来解析，如果缓存头正确，重定向URL的图像将被浏览器缓存。301重定向也是可缓存的，使用正确的缓存头。同样，作为一种服务，这种方法似乎更复杂，但业务成本可能最终会决定。

总而言之，我将完全避免第1条，因为它将正确使用图像服务的负担放在了客户机上。你是选择第2条还是第3条，可能取决于选择其中一条的直接开发成本和长期维护成本。