All geek questions in one place

Reverse Proxy and Embedded HTTP Server in Asp.Net Core

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

As a seasonal web developer, I am having trouble understanding the idea:

  • Relevance of implementing in-process http server in the main application?
  • The importance of the reverse proxy approach for any typical web server ?
  • Does a reverse proxy solve the type of problems in the asp.net kernel world, except for sending http request ?
  • How can reverse proxy and Kestrel correlate / share ( 1:n or 1:1 ) if the main asp.net application is intended to be deployed in a container?
+5
source share
1 answer

According to the official documentation :

ASP.NET Core was designed to run in its own process so that it can behave sequentially across platforms. IIS, Nginx, and Apache define their own startup process and environment; to use them directly, ASP.NET Core would have to adapt to the needs of each. Using a web server implementation such as Kestrel provides ASP.NET Core control over the startup process and environment. So instead of trying to adapt ASP.NET Core to IIS, Nginx, or Apache, you simply configure these web servers to proxy requests for Kestrel. This layout allows your Program.Main and Startup classes to be pretty much the same no matter where you deploy.

In addition, having an HTTP server in the process makes things easier for developers. They simply download the framework, install it, and it works out of the box no matter which OS they use (Windows, Linux or MacOS) or the web server that they want to use later. They simply run the dotnet run command, which launches the HTTP server with web hosting on it.

While it works, to run it in the development environment, when the application is ready for release, developers should be aware of security. Kestrel web server is a very new web server, so it does not have all of these security features and other useful features like IIS, Apache or Nginx received over their long life. This is the only reason MS recommends using a reverse proxy in a production environment. The purpose of the reverse proxy server is not only to redirect requests to the processed HTTP server, but also to be responsible for the security, compression and other functions that a good web server can provide.

As for container deployment, it really depends on what you want to achieve. There are various scenarios:

  • Launch the ASP.NET Core application and reverse proxy in the same container. In this case, the main ASP.NET application is usually configured to work on the local port, for example. 5000, and a reverse proxy server communicates with port 80. This approach is usually not recommended because, as best practices show, "each container should have only one problem"
  • Run the reverse proxy and the ASP.NET Core application in two different containers. In this case, you need to bind these containers to each other in order to redirect requests from the reverse proxy to the web application.
  • Launch the reverse proxy in one container and configure it as a reverse proxy for several main ASP.NET application containers.
+4
source

Source: https://habr.com/ru/post/1267140/

More articles:


All Articles