By Massimiliano Peluso "PeluSoft Limited" | 21 Dec 2010 | Unedited contribution

Introduction

In this article we will able to understand what’s happen when the user submit a request to ASP.NET web app. There are lots of article that explain this topic but no one shows in a clear way what really happens in depth during the request. After reading this article you will be able to
undestand :

• What is a web server
• HTTP - TCP/IP Protocol
• IIS
• Web communication
• Application Manager
• Hosting Environment
• Application Domain
• Application Pool
• How many app domain are created against a client request
• How many HttpAppllication are created against a request and how I can affects this behaviour
• What is the work processor and how many of it are running Against a request
• What it happens in depth between a request and response

Start from scratch

All the article I have read usually begin with “The user sends a request to IIS...bla bla bla” . Anyone know the IIS is a web server where we host our web application(and much more) but what is a web server?

Let start from really begin J

A Web Server (like Internet Information Server/Apache/etc.) is a piece of software that enables a website to be viewed using HTTP.We can abstract this concept saying that a web server is a piece of software that allow resources(web page,images,etc) the be requested over HTTP protocol. I ‘m sure many of you thought that a web server is just a special super computer but It’s just the software that runs on it that makes the difference between a normal computer and a web server.

As everyone knows in a Web Communication there are two main actor : the Client and the Server.

Client and server of course need a connection to be able to communicate each other and a common set of rules to be able to understand each other. The rules they need to communicate are called protocol. Conceptually when we speak to someone we are using a protocol.The protocols in human communication are rules about appearance, speaking, listening and understanding. These rules, also called protocols of conversation, represent different layers of communication. They work together to help people communicate successfully. The need for protocols also applies to computing systems. A communications protocol is a formal description of digital message formats and the rules for exchanging those messages in or between computing systems and in telecommunications.

HTTP know all the "grammar" but it doesn't know anything about how send a message or open a connection. That's why HTTP is built on the top of the TCP/IP. Below you can see the conceptual model of this protocol with on the top the HTTP protocol

 

TCP/IP is in charge to manage the connection and all the low level operation needed to deliver the message exchanged between the client and the server.

In this article I won’t explain how the TCP/IP works because I should write a whole article on it but it's good to know it is the engine that allows the client and the server to have messages exchanges.

HTTP is a connectionless protocol but it doesn’t mean that client and server don’t need to establish a connection before start to communicate each other but It means that the client and the server don’t act any prearrangements before start the communicate.

 

Connectionless means the client doesn’t care if the server is ready to accept a request and on the other hand the server doesn’t care if the client is ready to get the response but a connection is still needed.

In connection-oriented communication the communicating peers must first establish a logical or physical data channel or connection in a dialog preceding the exchange of user data.

Now let's see what’s happen when a user put an address into browser address bar.

·         The browser broke the URL into three parts:

 

                 The protocol ("http")

 

                 The server name (www.Pelusoft.co.uk)

 

       The file name (index.html)

 

 

·         The browser communicated with a name server to translate the server name "www.Pelusoft.co.uk" into an IP Address, which it uses to connect to the server machine.

·         The browser then formed a connection to the server at that IP address on port 80. (We'll discuss ports later in this article.)

·         Following the HTTP protocol, the browser sent a GET request to the server, asking for the file "http://www.pelusoft.co.uk.com/index.htm." (Note that cookies may be sent from browser to server with the GET request -- see How Internet Cookies Work for details.)

·         The server then sent the HTML text for the Web page to the browser. Cookies may also be sent from server to browser in the header for the page.)

·         The browser read the HTML tags and formatted the page onto your screen.

 

 

The current practice requires that the connection be established by the client prior to each request and closed by the server after sending the response. Both clients and servers should be aware that either party may close the connection prematurely, due to user action, automated time-out, or program failure, and should handle such closing in a predictable fashion. In any case, the closing of the connection by either or both parties always terminates the current request, regardless of its status”

At this point you should have an idea about how the HTTP – TCP/IP protocol works.

Of course there is a lot more to say about them but the scope of this article is just provide a very high view of those protocols just to better understand all the steps that occurs since the user start to browse a web site.

Now it’s time to go ahead moving the focus on what’s happen when the web server receives the request and how it can get the request itself.

As I showed earlier a web server is a “normal computer” that is running a special software that makes it a Web Server. Let’s suppose that on our web server is runnins IIS.

From a very high view IIS is just a process who is listening on a particular port (usually 80). Listening means it is ready to accept connection from clients on the port 80.

A very important thing is: IIS is not ASP.net. It means that IIS doesn’t know anything about Asp.net, it can work itself. We can have a web server that is hosting just html pages or images or any other kind of web resource. The web server, as I explained earlier, has to just return the resource the browser is asking for.

 

 

 

 

Asp.Net and IIS

The web server can support also server scripting (as ASP.NET). What I show in this paragraph is what's happen when on the server web is running Asp.net and how IIS can "talk" with the Asp.net engine. When we install Asp.net on a server web the installation update the script map of an application to the corresponding ISAPI extensions to process the request given to the IIS. For example, “aspx” extension will be mapped to aspnet_isapi.dll and hence request for an aspx page to IIS will be given to aspnet_isapi (the Asp.net registration can be done also using Aspnet_regiis). The script map is showed below:

 

 

The Isapi filter is a plug-in that can access the HTTP data stream before IIS gets to see it. Without the Isapi filter the IIS could not redirect the request to the Asp.net engine (in the case of an .aspx page). From a very high point of view we can think at the Isapi filter as a router for the IIS request: every time there is requested a resource which the file extension is present on the Map table (the one showed earlier) it redirect the request to the right place. In the case of an .aspx page it redirect the request to the .Net runtime that know how elaborate the request. Now let's see how it works.

When a request comes in:

·         IIS create/run the work processor (w3wp.exe) if it is not running

·         The aspnet_isapi.dll is hosted into the w3wp.exe processIIS checks for the script map and routes the request to the aspnet_isapi.dll.

·         The request is passed to .Net runtime that is hosted into the w3wp.exe as well

 

 

 

 

 

Finally the request get into the Runtime

This paragraph focus on how the runtime handle the request and shows all the objects involved in this process.

First of all let’s have a look to see what’s happen when the request get the runtime.

·         When ASP.NET receives the first request for any resource in an application, a class named ApplicationManager creates an application domain. (Application domains provide isolation between applications for global variables and allow each application to be unloaded separately).

·         Within an application domain, an instance of the class named Hosting Environment is created, which provides access to information about the application such as the name of the folder where the application is stored.

·         After the application domain has been created and the Hosting Environment object instantiated, ASP.NET creates and initializes core objects such as HttpContext, HttpRequest, and HttpResponse.

·         After all core application objects have been initialized, the application is started by creating an instance of the HttpApplication class.

·         If the application has a Global.asax file, ASP.NET instead creates an instance of the Global.asax class that is derived from the HttpApplication class and uses the derived class to represent the Application.

 

 

 

Those are the first steps that happened against one client request. Most of the article doesn’t say anything about those steps except the above

In this article we will analyze in depth what happens at each step.

Below you can see all the steps the request has to pass though before it is elaborated.

 

 

Application Manager

The first object we have to talk about is the Application Manager.

Application Manager is actually an object that sits on top of all running ASP.NET AppDomains and can do things like shut them all down or check for idle status.

For example when you change the configuration file of your web application the Application Manager is in charge to restart the AppDomain to allow all the running Application Instance (your web site instance) to be create again for loading the new configuration file you may have changed.

Any requests that are already in the pipeline processing will continue to run through the existing pipeline, while any new requests coming in get routed to the new AppDomain. To avoid the problem of "hung requests," ASP.NET forcefully shuts down the AppDomain after the request timeout period is up even if requests are still pending

Application Manager is the "manager" but the Hosting Environment contains all the "logic" to manage the Application instance.

It's like when you have a class that use an interface: within the class methods you just call the interface method.

In this case the method are called within the application manager but are executed into the Hosting Environment (let's suppose the hosting environment is the class the implement the interface)

At this point you should have a question:

How is it possible the Application Manager can communicate with the Hosting Environment since it lives into an AppDomain?

(we said the AppDomain creates kind of boundary around the application to isolate the application itself)

In fact the Hosting Environment has to inherit from MarshalByRefObject class to use remoting to communicate with the Application Manager.

Application Manager so creates a remote object (the Hosting Environment) and call method on it :-)

So we can say the Hosting Environment is the "remote interface" that is used by the Application Manager but the code is "execute" within the Hosting Environment object

comImpersonationLevel="Default|Anonymous|Identify|
Impersonate|Delegate"
responseDeadlockInterval="hrs:mins:secs|Infinite"
responseRestartDeadlockInterval="hrs:mins:secs|Infinite"
autoConfig="true|false"
maxWorkerThreads="num"
maxIoThreads="num"
minWorkerThreads="num"
minIoThreads="num"
serverErrorMessageFile=""
pingFrequency="Infinite"
pingTimeout="Infinite"
maxAppDomains="2000"
/>

 

 

With maxWorkerThreads and minWorkerThreads you set up the minimum and maximum number of HttpApplication.

 

For more information have a look at: ProcessModel Element

Just to clarify what we have said until now, we can say that against one request to a WebApplication we have:

·         One worker Process w3wp.exe is started (if it is not running)

·         One instance of ApplicationManager is created

·         One ApplicationPool is create

·         One Instance of Hosting Environment is created

·         A pool of HttpAplication instance is created (defined with the machine.config)

Until now we have talked about just one WebApplication,let's say WebSite1, under IIS.

What does it happen if we create another application under IIS for WebSite2 ?

·         We are going to have again the same process explained above

·         Website2 will be executed within the existing worker processor w3wp.exe (where is running website1)

·         The same Application Manager instance will manage WebSite2 as well. There is always one instance per work processor w3wp.exe

·         WebSite2 will have its own AppDomain and Host Environment

·         Within a new AppDomain will be run instances of WebSite2 (HttpApplication instances)

 

It's very important notices that each web application is run into a separate AppDomain so that if one fails or does something wrong it won't affected the other WebApp (WebSite1) that can carry on to work. At this point we should have another question:

What would happen if one Web Application, let's say WebSite1, does something wrong affecting the working process(even if it's quite difficult) ?

What if I want recycle the application domain?

To summarize what we have said, an AppPool consists of one or more processes. Each web application that you are running consists of (usually, IIRC) one application domain. The issue is when you assign multiple web applications to the same AppPool, while they are separated by the application domain boundary they are still in the same process(w3wp.exe). This can be less reliable/secure than using a separate AppPool for each web application. On the other hand, it can improve performance by reducing the overhead of multiple processes.

An Internet Information Services (IIS) application pool is a grouping of URLs that is routed to one or more worker processes. Because application pools define a set of Web applications that share one or more worker processes, they provide a convenient way to administer a set of Web sites and applications and their corresponding worker processes. Process boundaries separate each worker process; therefore, a Web site or application in one application pool will not be affected by application problems in other application pools. Application pools significantly increase both the reliability and manageability of a Web infrastructure.

I want better understand the difference between AppDomain and Application Pool

Just for better understanding let’s say you are working with internet explorer. As you know on IE you can open more than one tab for browsing more the one web site on the same instance of IE.

Let' say you open 4 tabs browsing different web site so that each tab will show a different web site.

After lot of pint of beer Let’s assume that each tab is running within a different App domain and each web site we are browsing is a different web app under IIS.

All the web sites we are browsing are sharing the same instance of IE (iexplorer.exe).

In this example let’s compare the IE instance (iexplorer.exe) to the Asp.net working process (w3wp.exe)

If one tab stuck for any reason (as sometime happen :-)) it's going to affect all the other tabs running under the same iexplorer.exe instance(some time IE stuck and it doesn’t respond to any interaction anymore showing Not responding) so you are forced to kill the process to carry on to work .

Killing the process you will not able to browse any of the web sites you were browsing even if it was just one that make IE stuck.

So what can I do if I want isolate the web site browsing at process level so that if one web site does something wrong I can carry on browsing the other web sites ?

Simple you can open two instance of IE and open two tabs on each instance

In this case two iexplore.exe instances will be running and they will be completely independent each other: if one tab stuck on one instance of internet explorer you can kill that process but the other one will carry on to work.

 

 

 

 

 

At this point you should have an idea of what’s happened in depth against a web request.

Of course we should say lots more regarding this topic but the scope of this article is just to give you an idea of what’s really happen internally IIS/Asp.net and all the object that are created to satisfy a web request

 

 

References

ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.0

What ASP.NET Programmers Should Know About Application Domains

A low-level Look at the ASP.NET Architecture

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)