我正在阅读asp.net core app中有关Kestrel Web服务器的阅读，特别是in-process http server和reverse proxy。
作为季节性网络开发人员，我在理解背后的想法方面很难：
-
in-process http server实现在核心应用程序中的相关性？ - 在任何典型的
web server？
上，反向代理方法的重要性 - 除转发
http request以外 -
reverse proxy和Kestrel如何相关/通信(1:n或1:1(如果ASP.NET Core App打算部署在容器中？
根据官方文档：
ASP.NET Core被设计为在自己的过程中运行，以便它可以在平台上始终如一。IIS，NGINX和Apache决定了自己的启动过程和环境；要直接使用它们，ASP.NET Core必须适应每个需求。使用Web服务器实现(例如Kestrel(对ASP.NET核心对启动过程和环境进行控制。因此，您只需将这些Web服务器设置为of to Kestrel，而不是试图将ASP.NET核心调整为IIS，NGINX或APACHE，而是设置了这些Web服务器。这种安排允许您的程序。无论您在何处部署，MAIN和启动课程基本相同。
除了拥有过程中的HTTP服务器还使开发人员变得更容易。他们只是下载框架，安装它，无论使用什么操作系统(Windows，Linux或MacOS(或以后要使用的Web服务器，它都可以从开箱即用。他们只是触发 dotnet run命令，该命令启动了HTTP服务器，并在其上托管了Web应用程序。
虽然可以在应用程序准备生产开发人员时应记住有关安全性时在开发环境中运行它。Kestrel Web服务器是非常新的Web服务器，因此它没有所有安全性和其他有用的功能，例如IIS，Apache或nginx在长寿上获得的。这是MS建议在生产环境中使用逆向物质的唯一原因。反向代理的目的不仅是向过程中的HTTP服务器提出转发请求，而且还负责良好的Web服务器可能提供的安全性，压缩和其他功能。
至于容器部署，这实际上取决于您要实现的目标。有不同的情况：
- 在同一容器中运行ASP.NET核心应用程序和反向代理。在这种情况下，ASP.NET核心应用程序通常配置为在本地端口上运行，例如5000，虽然反向代理与端口80结合。通常不建议采用这种方法
- 在2个不同的容器中运行一个反向Proxy和ASP.NET Core App。在这种情况中
- 在一个容器上运行反向代理，并将其配置为多个ASP.NET核心应用程序容器的反向代理。