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

Question

I was reading about Kestrel web server in asp.net core app specifically the in-process http server and reverse proxy .

Being a seasonal web developer, I have trouble in understanding the idea behind:

• The relevance of a in-process http server implementation in core application ?
• The importance of reverse proxy approach over any typical web server ?
• The type of issues does a reverse proxy solve in asp.net core world other than forwarding http request ?
• How reverse proxy and Kestrel correlate / communicate ( 1:n or 1:1 ) if the asp.net core app is meant to be deployed in a container?

Answer 1

According to 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.

Besides that having the in-process http server makes stuff really easier for developers. They just download the framework, install it and it works out of the box no matter what OS they are using (Windows, Linux or MacOS) or what web server they want to use later. They just fire dotnet run command which starts the http server with a web app hosting on it.

While it's OK to run it in a development environment when an app is ready for production developers should remember about security. The Kestrel web server is very new web server so it doesn't have all that security and other useful features as IIS, Apache or Nginx obtained during their long lives. This is the only reason why MS recommends to use reverse-proxy in production environment. The goal of reverse proxy is not only forward requests to in-process http server, but also be responsible for security, compression and other features a good web server may provide.

As for container deployments it really depends on what you want to achieve. There are different scenarios:

• Run ASP.NET Core app and reverse proxy in the same container. In this case ASP.NET core app is usually configured to run on a local port eg 5000, while a reverse proxy binds to port 80. This approach is not generally recommended because as best practices say "Each container should have only one concern"
• Run a reverse-proxy and ASP.NET Core app in 2 different containers. In this case you have to link these containers to each other in order to forward requests from a reverse-proxy to a web app.
• Run a reverse proxy on one container and configure it to be a reverse proxy for multiple ASP.NET core app containers.