Total votes: 7
Print: Print Article
Please login to rate or to leave a comment.
Published: 02 May 2007
In this series of articles I'm going to tackle and describe the life cycle of a web request from the early stages of its life, when it's accepted by the web server, through its processing into the ASP.NET pipeline and up to the generation of a response by the endpoints of the pipeline.
Microsoft Active Server Pages, also known as
ASP, since its first release in late 1996
provided web developers with a rich and complex framework for building web applications. As years passed its
infrastructure evolved and improved so much that what is now known as
ASP.NET is no longer something
which resembles its predecessor.
ASP.NET is a framework for building web applications, that is, applications that run over
the web, where the client-server paradigm is represented mostly by a browser forwarding requests for resources of
different kinds to a web server. Before the advent of dynamic server-side resource generation techniques like
ASP, all web servers had to do was accept
client’s requests for static resources and forward them to the requestor. When dynamic technologies started to
grow up web servers became invested of greater responsibility, since they had to find a way to generate those
dynamic resources on their side and return the result to the client, a task they were not formerly built for.
From a bird’s eye view, the interaction between client and server is very simple. Communications over
the web occur via
HTTP (Hyper Text Transfer Protocol), an application level protocol which relies on
TCP and IP to transmit data between two nodes connected to the heterogeneous network known as World Wide Web.
Each dynamic server-side technology essentially leans on a particular web server implementation, and
ASP.NET is tightly coupled with Microsoft’s Internet Information Server, aka
Different servers chose different ways to generate and serve dynamic resources and what we’re going to
examine is how
IIS does that, together with the path a request follows once on the server and back
to the client.
IIS and ISAPI Extensions
As mentioned, static resources needn’t to be processed by the server; once a request for such a
resource arrives, the server just retrieves its contents from the file system and sends it back to the client as
a stream of byte flowing on the
style sheets or plain old html pages. It’s clear that the server needs to know how to distinguish between static
and dynamic resource, whereas the second need to be processed somehow and not just sent back to the client.
ISAPI extensions appear, where
ISAPI stands for Internet Server
Application Programming Interface.
ISAPI extensions are modules implemented as plain old Win32 .dll,
IIS relies to process specific resources. Mappings between
and files are configured via the
IIS snap-in and stored in the
IIS metabase, where each
file extension can be associated with a particular
ISAPI extension, that is, when a request for such
a file arrives,
IIS handles it to the corresponding
ISAPI extension, confident that it
will be able to handle it.
Figure 1: Configuring ISAPI extensions mappings on IIS 5.0
ISAPI extensions obviously need to respect a common interface through which they can be
IIS and provided the necessary data to elaborate the request and generate a response.
As Figure 1 illustrates, the .asp extension is mapped to the
extension; at the time of
ASP this component was in charge of performing all the tasks required to
generate a response, that is, collecting information about the request, made available into the
page via the Request, Response and other common
ASP intrinsic objects, parsing and executing the
ASP page and returning the resulting HTML.
Actually, that was a big improvement compared to a technology like CGI, but
this approach much further and introduces abstractions which totally shield the developers from having to care
about what happens at this stage.
IIS to redirect requests for
ASP.NET specific files to a new
ISAPI extension called
What this extension does is somewhat different then the former
asp.dll extension, which was
essentially responsible just for parsing and executing the requested
ASP page. The steps taken by a
ISAPI module to process a request are totally hidden from
ISAPI extension may follow different paradigms in order to process requests.
Table 1: IIS Application Mappings for aspnet_isapi.dll
||ASP.NET application files. Usually global.asax.
||ASP.NET user control files.
||HTTP handlers, the managed counterpart of ISAPI extensions.
||ASP.NET web services.
||ASP.NET web pages.
||ASP.NET internal HTTP handlers.
As well as the file extensions listed in Table 1, the
extension manages other file extensions which are usually not served to web browsers, like Visual Studio project
files, source code files and config files, for example.
The ASP.NET Process Model
So far we’ve seen that when a request for an
ASP.NET file is picked up by
IIS, it is passed to the
aspnet_isapi.dll, which is the main entry point for
ASP.NET related processing. Actually, what the
ISAPI extension does depends sensibly on
the version of
IIS available on the system, and thus the process model, which is the sequence of
operations performed by the
ASP.NET runtime to process the request and generate a response, may vary
quite a bit.
When running under
IIS 5.X, all ASP.NET-related requests are dispatched by the
ISAPI extension to an external worker process called
ISAPI extension, hosted in the
inetinfo.exe, passes the control to
aspnet_wp.exe, along with all the information
concerning the incoming request. The communication between the two is performed via named pipes, a well known
mechanism for IPC (Inter Process Communication). The
ASP.NET worker process performs a considerable
number of tasks, together with the
ISAPI extension. They are the main authors of all the stuff that
happens under the hoods of an
ASP.NET request. To introduce a topic which will be discussed later,
take note of the fact that each web application, corresponding to a different virtual directory hosted on
IIS, is executed in the context of the same process, the
ASP.NET worker process. To
provide isolation and abstraction from the execution context the
ASP.NET model introduces the
concept of Application Domains, in brief AppDomains. They can be considered as lightweight processes. More on
If running under
IIS 6, on the other side, the
aspnet_wp.exe process is not
used, in favour of another process called
inetinfo.exe is no
longer used to forward
HTTP requests to
ISAPI extensions, although it keeps running for
serving other protocols requests. A lot of other details change compared to the process model used by previous
IIS 6 is capable of running in compatibility mode and emulate
the behavior of its predecessor. A big step forward, compared to the process model used when running on top of
IIS 5, is that incoming requests are in the former handled at a lower – Kernel – level and then
forwarded to the correct
ISAPI extension, thereby avoiding inter process communication techniques
which may represent an expensive operation under a performance and resource consumption point of view. We’ll
delve deeper into this topic in the following paragraphs.
IIS 5.0 Process Model
This is the default process model available on Windows 2000 and XP machines. As mentioned it consists
inetinfo.exe process listening by default on the TCP port 80 for incoming
HTTP requests and queuing them into a single queue, waiting to be processed. If the request is
ASP.NET, the processing is delegated to the
aspnet_isapi.dll. This, in turn, communicates with the
aspnet_wp.exe via named pipes and finally is the worker process which takes care of
delivering the request to the
HTTP runtime environment. This process is
graphically represented in Figure 2.
Figure 2: The IIS 5.0 Process Model
In Figure 2 is represented an additional element we didn’t mention yet, the
HTTP Runtime Environment. It’s not topic of this article and will eventually be explained in a
follow up article, but for the sake of this discussion the
HTTP Runtime Environment can be
considered as a black box where all the
ASP.NET specific processing takes place, all the managed
code lives and developers can actually put their hands on, from the HttpRuntime straight to the HttpHandler who
will finally process the request and generate the response. This is even referred to as the
HTTP Runtime pipeline.
One of the interesting points of this process model is that all the requests, once handled by the
ISAPI extension, are passed to the
ASP.NET worker process. Only one instance of this
process is active at a time, with one exception, discussed later. Therefore all
applications hosted on
IIS are actually hosted inside the worker process, too. However, this doesn’t
mean that all the applications are run under the same context and share all their data. As mentioned,
ASP.NET introduces the concept of AppDomain, which is essentially a sort of managed lightweight
process which provides isolation and security boundaries. Each
IIS virtual directory is executed in
a single AppDomain, which is loaded automatically into the worker process whenever a resource belonging to that
application is requested for the first time. Once the AppDomain is loaded – that is, all the assemblies required
to satisfy that request are loaded into the AppDomain – the control is actually passed to the
ASP.NET pipeline for the actual processing. Multiple AppDomains can thus run under the same process,
while requests for the same AppDomain can be served by multiple threads. However, a thread doesn’t belong to an
AppDomain and can serve requests for different AppDomains, but at a given time a thread belongs to a single
For performance purposes the worker process can be recycled according to some criteria which can be
specified declaratively in the machine.config file placed in the directory
C:\windows\microsoft.net\Framework\[framework version]\CONFIG. These criteria are the age of the process, number
of requests served and queued, time spent idle and consumed memory. Once one of the threshold value of these
parameters is reached, the
ISAPI extension creates a new instance of the worker process, which will
we used from then on to serve the requests. This is the only time when multiple copies of the process can be
running concurrently. In fact, the old instance of the process isn’t killed, but it is allowed to terminate
serving the pending requests.
IIS 6.0 Process Model
IIS 6 process model is the default model on machines running Windows 2003 Server
operating system. It introduces several changes and improvements over the
IIS 5 process model. One
of the biggest changes is the concept of application pools. On
IIS 5.X all web applications, that
is, all AppDomains, were hosted by the
ASP.NET worker process. To achieve a finer granularity over
security boundaries and personalization, the
IIS 6 process model allows applications to run inside
different copies of a new worker process,
w3wp.exe. Each application pool can contain multiple
AppDomains and is hosted in a single copy of the worker process. In other words, the shift is from a single
process hosting all applications to multiple processes hosting each an application pool. This model is also
called the worker process isolation mode.
Another big change from the previous model is the way
IIS listens for incoming requests.
IIS 5 model, it was the
inetinfo.exe, who was
listening on a specific TCP port for
HTTP requests. In the
IIS 6 architecture, incoming
requests are handled and queued at kernel level instead of user mode via a kernel driver called http.sys; this
approach has several advantages over the old model and is called kernel-level request queuing.
Figure 3: The IIS 6.0 process model
Figure 3 illustrates the principal components taking part in the request processing when using the II
6 model. Once a request arrives the kernel level device driver http.sys routes it to the right application pool
queue. Each queue belongs to a specific application pool, and thus to a specific copy of the worker process,
which next receives the request from the queue. This approach highly reduces the overhead introduced by named
pipes used in
IIS 5 model since no inter process communication is taking place, but the requests are
headed to the worker process directly from the kernel level driver. This has many advantages concerning
reliability, too. Since running in kernel mode, the request dispatching isn’t influenced by crashes and
malfunctions happing at user level, that is, in the worker processes. Thereby, even if a worker process crashes,
the system is still capable of accepting incoming requests and eventually restarts the crashed process.
It’s the worker process who is in charge of loading the
extension, which, in turn, loads the CRL and delegates all the work to the
w3wp.exe worker process, differently from the
aspnet_wp.exe process used
IIS 5 model, isn’t
ASP.NET specific, and is used to handle any kind of requests. The
specific worker process then decides which
ISAPI modules to load according to the type of resources
it needs to serve.
A detail not underlined in Figure 3 for simplicity reasons is that incoming requests are forwarded
from the application pool queue to the right worker process via a module loaded in
IIS 6 called Web
Administration Service (WAS). This module is responsible for reading worker process – web application bindings
IIS metabase and forwarding the request to the right worker process.
Sorry, no bio is available
This author has published 10 articles on DotNetSlackers. View other articles or the complete profile here.
Other articles in this category
IIS FTP User Isolation - Week 46
This week we walk through the five isolation modes to gain a full understanding of the IIS FTP metho...
FTP Firewall settings, Active vs. Passive, and FTPS Explicit vs. Implicit Week 47
Understanding Active and Passive mode for FTP is useful for troubleshooting and ensuring that the fi...
Q&A. DNS Load Balancing, Google and Geo-location, CDNs-Week 50
This week answers two Q&A questions from viewers. DNS Load Balancing and then some discussion and a ...
Q&A. What’s new in IIS8, Perf, Indexing Service–Week 49
This week I'm taking Q&A from viewers, starting with what's new in IIS8, a question on enable32BitAp...
IIS FTP Troubleshooting - Week 48
This lesson covers ways to troubleshoot IIS FTP. When it works, it works well, but if you run into i...
You might also be interested in the following related blog posts
Spec Explorer: A Model-Based Testing tool
Web Deployment Tool released to web (RTW)
RELEASED ASP.NET MVC 2 Preview 2
Html Encoding Code Blocks With ASP.NET 4
Auto-Start ASP.NET Applications (VS 2010 and .NET 4.0 Series)
Microsoft StreamInsight and BizTalk Server - Preliminary Thoughts
How do ASP.NET Application_ Events Work
IIS7 Resource Kit Rocks!
Binding in ASP.NET MVC
How to completely process and filter all bounced e-mail messages and get a notification via email when it's completed!
Please login to rate or to leave a comment.