concept reverse proxy in category asp.net
This is an excerpt from Manning's book ASP.NET Core in Action.
A reverse proxy is software responsible for receiving requests and forwarding them to the appropriate web server. The reverse proxy is exposed directly to the internet, whereas the underlying web server is exposed only to the proxy. This setup has several benefits, primarily security and performance for the web servers.
The request is forwarded from the reverse proxy to your ASP.NET Core application. Every ASP.NET Core application has a built-in web server, Kestrel by default, which is responsible for receiving raw requests and constructing an internal representation of the data, an HttpContext object, which can be used by the rest of the application.
Figure 16.1. The hosting model for ASP.NET Core. Requests are received by the reverse proxy and are forwarded to the Kestrel web server. The same application can run behind various reverse proxies without modification.
In this book, we’ve focused on the lower half of figure 16.1—the ASP.NET Core application itself—but the reality is that you’ll generally want to place your ASP.NET Core apps behind a reverse proxy, such as IIS on Windows, or NGINX or Apache on Linux. The reverse proxy is the program that listens for HTTP requests from the internet and then makes requests to your app as though the request had come from the internet directly.
In Linux, the reverse proxy might be running on the same server as your app, but it’s also common for it to be running on a different server entirely, as shown in figure 16.9. This is similarly true if you choose to deploy your app to Docker; your app would typically be deployed in a container without a reverse proxy, and a reverse proxy on a server would point to your Docker container.
Figure 16.9. On Linux, it’s common for a reverse proxy to be on a different server to your app. The reverse proxy forwards incoming requests to your app, while the process manager, for example systemd, monitors your apps for crashes and restarts it as appropriate.
As the reverse proxies aren’t necessarily on the same server as your app, they can’t be used to restart your app if it crashes. Instead, you need to use a process manager such as systemd to monitor your app. If you’re using Docker, you’d typically use a container orchestrator such as Kubernetes (https://kubernetes.io) or Apache Mesos (http://mesos.apache.org) to monitor the health of your containers.