ASP.NET 核心上真的需要反向代理吗？

Posted 2023-02-25

【中文标题】ASP.NET 核心上真的需要反向代理吗？

【英文标题】：Is reverse proxy actually needed on ASP.NET core?

【发布时间】：2019-09-25 09:26:37

【问题描述】：

我们想知道大多数用例是否真的需要反向代理，希望能提供更多信息。

Kerstel/nginx 文档声称： “Kestrel 非常适合从 ASP.NET Core 提供动态内容。但是，Web 服务功能不如 IIS、Apache 或 Nginx 等服务器功能丰富。反向代理服务器可以卸载诸如提供静态内容之类的工作，缓存请求、压缩请求和来自 HTTP 服务器的 HTTPS 终止。反向代理服务器可能驻留在专用机器上，也可能与 HTTP 服务器一起部署。 https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-2.2

如果这在当今确实相关，任何人都可以分享一些见解吗？

在我们的用例中，我们使用带有外部负载平衡 (AWS ALB) 的 Docker 实例。 每个 docker 实例都运行着 Nginx 和我们的 ASP.NET Core 应用程序。 我们无法弄清楚使用 Nginx 的确切好处。

提供静态内容 由于我们使用的是外部 CRN (AWS CloudFront)，我认为静态缓存并没有任何实际好处，是吗？

缓存请求 我相信这与提供静态内容相同，因为在大多数场景（在我们的用例 - 所有场景）上都不会缓存动态内容。

压缩请求 然而，ASP.NET Core 有一个响应压缩中间件——它声称“中间件的性能可能与服务器模块的性能不匹配。HTTP.sys 服务器服务器和 Kestrel 服务器目前不提供内置的压缩​​支持。 ”。 也许可以创建一些基准来验证这一说法。 https://docs.microsoft.com/en-us/aspnet/core/performance/response-compression?view=aspnetcore-2.2

来自 HTTP 服务器的 HTTPS 终止 我假设大多数拥有负载均衡器的客户端都可以跳过这一部分，因为如果需要，可以在负载均衡器上完成 HTTPS 终止。

谢谢！ 艾菲

【问题讨论】：

在 nginx 后面运行应用程序通常更实用，因为如果您运行的应用程序不止一个，则不必两次配置相同的东西。像加密证书和自动重写到 https 之类的东西在 nginx 中非常实用，所以你不必在你的应用程序中这样做

感谢 Johan，我们使用的是单一应用程序架构（单一 SaaS 解决方案）。也可以在 ASP.NET 核心上配置加密证书。自动重写到 HTTPS 很棒，但我们实际上是在 CDN (AWS CloudFront) 上这样做的。

不，您不再需要反向代理。

谢谢大卫，我们会考虑停止使用 Nginx。

嗨@davidfowl，您有关于使用 ASP.NET Core 与 nginx 进行压缩的任何信息吗？根据 Microsoft 文档 (docs.microsoft.com/en-us/aspnet/core/performance/…)，应避免响应压缩，似乎首选 Nginx。那些文档过时了吗？感谢您的帮助！

【参考方案1】：

本文档并未告诉您“应该”在反向代理后面运行 ASP.NET Core / Kestrel，只是因为 Kestrel 没有其他 Web 服务器可能具有的某些功能，因此高级场景可以从中受益。

如果您不需要额外的 nginx 反向代理，那么您不必使用。

例如Kestrel 最近才采用 API 来即时更改某些连接参数，而无需重新启动 - 这有助于切换通过 ACME 获得的证书（例如 Let’s Encrypt 服务）。

是否需要反向代理很大程度上取决于系统架构，但如果您不需要特定功能，则不必部署。

【讨论】：

感谢 Martin，我们实际上已经停止使用反向代理，在进行过程中没有遇到任何问题。

这么想，只是不想看到这个问题仍未得到答复 :)

@EffyTeva 自从停止使用 Nginx 后，您是否注意到任何性能下降？您是否对您的应用程序进行了任何负载测试并比较了结果？

@SohailAhmed，不，自从移除 Nginx 以来，我们没有遇到任何性能问题。我们进行了一些特定的负载测试，但没有发现任何重大差异。