ASP.NET Core Application Life Cycle

Welcome, In the previous article, we discussed the roadmap, which are the steps that we are going to take to learn ASP.NET Core, to becoming a ninja from a newbie. And now, it is the time to take the first step towards this beautiful journey. In this article, we will learn the ASP.NET Core application life cycle, so that we will be having a clear understanding of the framework from the very beginning. So, without any delay let's gets started.

Everyone has their own pattern or style of learning something, mine is something different, I start from the opposite direction, and believe me it helps. So, instead of thinking that what happens in between when a user issues a request from a browser and gets the response from the server, first we should think about the deployment, this means, consider as if you have successfully developed a web application using ASP.NET Core MVC, ASP.NET Core Razor or ASP.NET Core Blazor and now you want to deploy it on a server.

You might be knowing that ASP.NET Core is cross-platform and is not tied to windows anymore. So, what does it mean? can we host our ASP.NET Core Application on a web server like Apache or Nginx directly, on a Linux environment? well, No, you can't host an ASP.NET Core application, on Apache or Nginx directly. And, it is where the light-weight, superfast, open-source and event-driven, Kestral web server, comes into the picture. It is the Kestral web server only that enables an ASP.NET Core application to be hosted on Linux and macOS environments.

What exactly Kestral is and what are the ASP.NET Core hosting models, shown in the above pictures?

Kestral is a cross-platform web server for ASP.NET Core. So, do we need to install it explicitly on the server? well, No, Kestral is so lightweight that it is included and enabled by default in ASP.NET Core project templates, Kestrel is just an HTTP Server implementation for ASP.NET Core and Microsoft has built it as a library, Which means it will be an integral part of our ASP.NET Core application. Even if it is lightweight but don't underestimate its power, it can very well act as an internet-facing web server or better say as an edge server. Since Kestral is an integral part of ASP.NET Core application, you can say that an ASP.NET Core application can directly listen to the HTTP requests from the web and pass them to the rest of the application which is usually the HTTP request processing pipeline (Middleware pipeline) and later it can send the response back to the client when it receives the response from the pipeline.

Kestral also supports the feature like HTTPS and HTTP/2 and when it comes to performance it is many times faster than IIS.

Now, you might be thinking that what about full-blown and mature web servers like IIS or Apache? Are they of no use. If No, then what about features like GZIP Compression, Security, HTTP access logs, Port Sharing, Request Filtering & limits, IP and domain restrictions, HTTP redirect rules, response output caching, and most important process activation on system failure. Sadly, Kestral doesn't support any of these features and this is the reason Microsoft suggests always using a mature web server like IIS or Apache in front of Kestral web server for public websites.

In short, our ASP.NET Core application can directly listen to the HTTP requests from the web where Kestral behaving as an edge server as shown in the first image or it can also be used in combination with a mature web serve like IIS, Apache, or Nginx, where a mature web server faces the internet, adds another layer of configuration and security, and acting as a proxy web server, proxies the request to Kestral, and Kestral creates the HttpContext instance and passes it to the ASP.NET Core request processing pipeline, as shown in the second image.

Kestral serving as an edge server or sitting behind a proxy web server, both modes comes under the category of "OutOfProcess" hosting model. So, what does it mean, is there some other hosting model also available? well, yes, and it is an In-Process Hosting model.

InProcess hosting model is purely for Windows OS. Yes, you guessed it right If IIS hosts our application without proxying the requests to Kestral, then it is termed as InProcess hosting. A question that may come to our mind is why do the hosting models named as InProcess and OutOfProcess? well, IIS is the Microsoft product and the main web server for windows and ASP.NET for years, so IIS is considered as the landmark here. InProcess hosting simply means ASP.NET Core application is running in the same process as its IIS Worker process and OutOfProcess hosting means ASP.NET Core application is running in a process separate from IIS worker process.

What is meant by the term worker process in context of IIS and Kestral?

when we build the project and look at the bin folder, we find that the compiled web application is actually gets converted into a "dll", and a ".dll" file needs an "exe" under which it can execute, Worker processes are simply the executables, and our application executes within the boundary of such worker processes. Whenever we create an ASP.NET Core application it is actually created as a console application, containing a Main() method, which builds a host, configures Kestral as the webserver and starts it and then the Kestral starts listening to the incoming HTTP requests on a random port and from here our application becomes a web application. so, when you will look at the bin folder you will find that there is an "exe" file with the name of your application along with a DLL file of the same name. The "ApplicationName.dll" is the actual application code and the "ApplicationName.exe" is the one that hosts our application. So, for Kestral, you will always get the worker process name as the Application name.

Whenever a web application is configured on IIS, then an application pool is automatically created with the same name as your application name, however, we can also create an application pool explicitly with different settings and configurations and can easily link our web application to that app pool. The same App pool can also be used by multiple web applications.

Now, each application pool runs in its own worker process within the windows OS, so that there is a complete separation between application pools. For, IIS the worker process is w3wp.exe, which means for each app pool an instance of w3wp.exe is created. So, the process name here will be w3wp.

General flow of request for InProcess hosting

The general flow of a request is as follows:

1. The user issues a request to the ASP.NET Core application hosted over IIS on windows OS.
2. The kernel-mode HTTP.sys driver of Windows OS, catches the request.
3. The driver then routes this native request to IIS on the website's configured port, usually port 80 for HTTP or port 443 for HTTPS.
4. The ASP.NET Core Module of IIS receives the native request and passes it to IIS HTTP Server
.

ASP.NET Core Module is a native IIS Module, that plugs into the IIS pipeline to either host an ASP.NET Core Application inside of the IIS worker process (w3wp.exe) or to forward web requests to backend ASP.NET Core App running Kestral server, we need to download and install .NET Core hosting bundle to get the ASP.NET Core Module.

The IIS HTTP Server (IISHttpServer), which is an in-process server implementation for IIS converts the request from native to managed and sends it to ASP.NET Core middleware pipeline, also known as Request processing pipeline.

Each middleware in the request processing pipeline do some processing and passes the request to the next middleware as an instance of HttpContext and finally to the App's logic.

HttpContext object encapsulates all Http specific information about an individual HTTP request. The HttpContext class is present in Microsoft.AspNetCore.Http namespace.

Anytime the response is created by the middleware travels back through the same path, meaning the first middleware in the pipeline is the last middleware that gets the response and passes the response to the IIS HTTP Server.

IIS HTTP server sends the response to the client.

General flow of request for OutOfProcess hosting

The general flow of a request is as follows:

1. The user issues a request to the ASP.NET Core application hosted over IIS on windows OS.
2. The kernel-mode HTTP.sys driver of Windows OS, catches the request.
3. The driver then routes this native request to IIS on the website's configured port, usually port 80 for HTTP or port 443 for HTTPS.
4. The ASP.NET Core Module of IIS forwards the requests to Kestrel on a random port for the app. The random port can be anything except port 80 or 443.
5. After the Kestral server processes the request, the request is sent to the ASP.NET Core middleware pipeline.
6. Each middleware in the request processing pipeline do some processing and passes the request to the next middleware as an instance of HttpContext and finally to the App's logic.
7. The app's response is passed back to IIS through Kestral Server.
8. IIS sends the response to the client that initiated the request.