HTTP stands for Hypertext Transfer Protocol. It is an application-level protocol. Whenever you visit a website in your browser, it uses the HTTP protocol to communicate with the server. Let’s investigate how ASP.NET Core handles an HTTP request.
An HTTP request consists of a verb, such as GET, a POST, PUT, Delete, etc. The verb indicates the type of HTTP request. The request also contains the path of the resource that it’s trying to access. In addition, all HTTP requests provide one or more headers in the key-value format to provide additional data to the server. Finally, a request can contain the body, which might represent the form content.
When the server receives an HTTP request, it processes that request and responds to the client. The response tells the client if the request was successful or not.
ASP.NET Core is a web application framework that runs on the server. When a browser makes an HTTP request to the server, the framework intercepts that request. Then it uses routing to route that request to the method that’s written to handle that specific type of request. Once the code executes and creates the result, the framework sends the response to the browser that requested the web page.
ASP.NET Core provides all the functionality to handle a request. It includes ensuring that the request is valid, routing the request, managing authentication and authorization, and generating a response to the browser.
When an HTTP request arrives at the server, Kestrel, the default built-in web server in ASP.NET Core, receives it. It processes the request and builds an HTTPContext object representing the request, which your application code can use to create the response for the request. You can send either an HTML response or JSON/XML data.
Once the application has processed the request and has generated the response, it returns the response to Kestrel, the web server. Kestrel converts the response, which might be an object, to a raw HTTP response, and sends it to the browser over the network. Thich completes a request-response lifecycle.
Now, you can expose the ASP.NET Core web server directly to the outside traffic, and it can handle it. However, the best practice is to add another layer of indirection (a reverse proxy) between the external network and your web server hosting the application.
A reverse proxy is simply server software that receives incoming requests and forwards them to the web servers. You expose the reverse proxy to the external traffic, i.e. the internet, and keep the web servers safely behind the firewall, only exposed to the reverse proxy. No outside traffic can directly communicate with the web servers.
IIS is the most popular reverse proxy on Windows servers, whereas you can use Nginx, Apache, or HAProxy on Mac or Linux servers.
A reverse proxy provides two important benefits.
As the traffic to your application grows, you can add as many web servers to handle the traffic without changing the IP address of the web servers. Because the external traffic only talks to the reverse proxy, it doesn’t need to know the addresses of the web servers.
Because the reverse proxies are exposed to the external network, they are designed with security in mind than a typical web server. Your web servers can stay behind the firewall. You can also terminate the SSL connections on the reverse proxy and transmit data unencrypted between the web servers and the reverse proxy. In addition, reverse proxies handle other tasks such as restarting the web servers when they crash or caching static files, etc.