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

Question

我正在阅读关于Kestrelweb服务器的asp.net core app具体内容in-process http server和reverse proxy.

作为季节性的Web开发人员,我无法理解背后的想法:

• in-process http server核心应用程序中实现的相关性？
• 反向代理方法的重要性超过任何典型web server？
• 除了转发之外,问题的类型是否在asp.net核心世界中进行反向代理解决http request？
• 如果要将asp.net核心应用程序部署在容器中,如何reverse proxy以及Kestrel关联/通信(1:n或1:1)？

Answer 1

根据官方文件:

ASP.NET Core旨在在其自己的进程中运行,以便它可以跨平台一致地运行.IIS,Nginx和Apache决定了他们自己的启动过程和环境; 要直接使用它们,ASP.NET Core必须适应每个人的需求.使用Kestrel等Web服务器实现可以对启动过程和环境进行ASP.NET Core控制.因此,您只需将这些Web服务器设置为代理对Kestrel的请求,而不是尝试将ASP.NET Core调整为IIS,Nginx或Apache.无论您在何处部署,这种安排都允许您的Program.Main和Startup类基本相同.

除了具有进程内http服务器使开发人员更容易使用的东西.他们只是下载框架,安装它,无论他们使用什么操作系统(Windows,Linux或MacOS)或他们想要在以后使用什么Web服务器,它都可以开箱即用.他们只是启动dotnet run命令,启动http服务器上面的Web应用程序托管.

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

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

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