asp.net - Asp.Net Core 中的反向代理和进程内 HTTP 服务器

Question

我正在阅读有关asp.net core应用程序中的Kestrel Web服务器，特别是进程内http服务器和反向代理.

作为一名季节性网络开发人员，我很难理解背后的想法:

• 进程内 http 服务器 实现与核心应用程序的相关性？
• 反向代理方法相对于任何典型网络服务器的重要性？
• 除了转发 http 请求之外，反向代理还可以在 ASP.NET Core 世界中解决哪些类型的问题？
• 反向代理和Kestrel如何关联/通信(1:n 或 1:1) asp.net core 应用程序应该部署在容器中吗？

Answer 1

根据official documentation :

ASP.NET Core was designed to run in its own process so that it can behave consistently across platforms. IIS, Nginx, and Apache dictate their own startup process and environment; to use them directly, ASP.NET Core would have to adapt to the needs of each one. Using a web server implementation such as Kestrel gives ASP.NET Core control over the startup process and environment. So rather than trying to adapt ASP.NET Core to IIS, Nginx, or Apache, you just set up those web servers to proxy requests to Kestrel. This arrangement allows your Program.Main and Startup classes to be essentially the same no matter where you deploy.

此外，拥有进程内 http 服务器使开发人员的工作变得更加容易。他们只需下载框架，安装它，无论他们使用什么操作系统(Windows、Linux 或 MacOS)或以后想要使用什么 Web 服务器，它都可以开箱即用。他们只是触发 dotnet run 命令，该命令启动 http 服务器并在其上托管 Web 应用程序。

虽然当应用程序准备好用于生产时可以在开发环境中运行它，但开发人员应该记住安全性。 Kestrel Web 服务器是非常新的 Web 服务器，因此它不具备 IIS、Apache 或 Nginx 在其漫长生命周期中获得的所有安全性和其他有用功能。这是 MS 建议在生产环境中使用反向代理的唯一原因。反向代理的目标不仅是将请求转发到进程内的http服务器，而且还负责安全、压缩和一个好的Web服务器可能提供的其他功能。

至于容器部署，这实际上取决于您想要实现的目标。有不同的场景:

• 在同一个容器中运行 ASP.NET Core 应用和反向代理。在这种情况下，ASP.NET Core 应用程序通常配置为在本地端口上运行，例如5000，而反向代理绑定(bind)到端口 80。通常不推荐这种方法，因为最佳实践表明“每个容器应该只有一个关注点”
• 在 2 个不同的容器中运行反向代理和 ASP.NET Core 应用。在这种情况下，您必须将这些容器相互链接，以便将请求从反向代理转发到网络应用。
• 在一个容器上运行反向代理，并将其配置为多个 ASP.NET Core 应用容器的反向代理。