ASP. NET insider-IIS Processing Model

Original article address: ASP. NET Internals-IIS and the Process Model

2007.05.03
Simone Busoli
ASP. NET is a beautiful framework for developing Web applications and building them. However, it is difficult for most people to understand every detail of ASP. NET. Although there are many books and online articles, I always feel that there is not enough information to understand its infrastructure, such as understanding its working principles and some necessary basic information for high-level design trade-offs. In this series of articles, I will describe the lifecycle of Web requests, starting from the initial stage of Web requests, and then accepted by the server, and then processed into ASP.. NET pipeline, which generates Web response output on the terminal of the pipeline.

Introduction

Microsoft's Active Server Pages (ASP) has provided a rich and complex framework for Web developers to build Web applications since its first release in 1996. Over the past few years, its infrastructure has developed so rapidly that it has become an ASP. NET concept that everyone knows and is no longer like its predecessor. ASP. NET is a framework for building Web applications. That is to say, the application runs on the Web, and the client-server mode shows that the browser sends various resource requests to the Web server. Before dynamic server-side resource generation technologies such as CGI, PHP, JSP, and ASP appeared, all Web servers must accept static client resource requests and send them to the requestor. With the development of dynamic technology, Web servers begin to assume more responsibilities, because they must generate dynamic resources on the server side and return the results to the client, this is a different task from the previous one.

From cainiao's point of view, the interaction between the client and the server is very simple, that is, the use of HTTP (Hypertext Transfer Protocol) Web communication. HTTP is an application layer protocol that relies on TCP/IP to transmit data between two connection nodes in a heterogeneous network, that is, the World Wide Web.

Every dynamic server technology fully understands the implementation of specific Web servers. ASP. NET is closely integrated with Microsoft's Internet Information Server (IIS.

Different servers use different methods to generate dynamic resources. We need to check how IIS processes a request path on the server and returns the result to the client.

IIS and ISAPI extensions

As mentioned above, static resources do not need to be processed by the server. Once a static resource request is received, the server only needs to obtain its content from the file system and send the byte stream of content to the client according to the HTTP protocol. Static resources can be images, script files, css style sheets, or html pages. Obviously, the server needs to know how to differentiate static and dynamic resources, because the latter needs to be processed rather than directly sending it to the client. This is why ISAPI appears. ISAPI indicates the Internet Server Application Programming Interface ). ISAPI extension is implemented using Win32. dll. IIS uses it to process specific resources. The ing between ISAPI extensions and files is configured by the IIS plug-in and stored in the IIS metadata. Each file extension can be associated with a specific ISAPI extension, that is, when a request for such a file arrives, IIS delivers it to the corresponding ISAPI extension and considers it to be capable of processing.

Figure 1: Configure ISAPI extension ing in IIS 5.0

Obviously, ISAPI needs to implement a public interface. IIS can call the request using the data described in detail to generate a response.

1. asp extension is mapped to the ISAPI extension of asp. dll. For ASP pages, this form is responsible for processing all Request tasks, generating output, including collecting Request information, and passing this information to ASP pages through requests, Response, and other common ASP built-in objects, parse and execute the ASP page and return the result HTML.

In fact, this is a great improvement compared with CGI technology, but ASP. NET has taken a further approach to introduce abstract methods to prevent developers from paying attention to what happened in this process.

After installation, ASP. NET configures IIS to redirect specific ASP. NET file requests to an ISAPI extension called aspnet_isapi.dll. The processing of This ISAPI extension is a little different from the previous asp. dll extension. asp. dll extension is only responsible for parsing and executing the ASP page of the request. The steps for the common ISAPI module to process requests are completely hidden by IIS. Therefore, to process requests, the ISAPI extension can adopt different modes.
Table 1: IIS application ing of aspnet_isapi.dll

Extension	Resource Type
. Asax	ASP. NET application files. Usually global. asax.
. Ascx	ASP. NET user control files.
. Ashx	HTTP handlers, the managed counterpart of ISAPI extensions.
. Asmx	ASP. NET web services.
. Aspx	ASP. NET web pages.
. Axd	ASP. NET internal HTTP handlers.

In addition to the file extension list in Table 1, ASP. net isapi extensions also manage other file extensions that do not support browser requests, such as Visual Studio project files, source code, and configuration files.

ASP. NET Processing Model

So far, we have learned that when IIS receives an ASP. NET file request, it will pass it to the ASP. NET-related processing master entry point aspnet_isapi.dll. In fact, how to process ISAPI extensions depends on the IIS version of the operating system. The processing models of different versions may be very different. The processing model refers to the Operation Sequence of ASP. NET runtime to process requests and generate responses.

When IIS 5.xis running, all asp.netrelated requests are sent to an external working process called aspnet_wp.exe by isapiextension. ASP. NET isapiextension running in iisimport inetinfo.exe transfers control to aspnet_wp.exe and transmits all request-related information. Communication between them is implemented through the named pipeline, that is, the well-known IPC (Inter-Process Communication Inter Process Communication) mechanism. Together with ISAPI extensions, ASP. NET workers execute a certain number of tasks, which are the principal owners behind ASP. NET requests. This topic will be discussed later. Note that every web application corresponding to different virtual directories on IIS is executed in the context of the same process, that is, ASP. NET workflow. To provide isolation in the execution context, the ASP. NET model introduces the application domain concept, abbreviated as AppDomain. They can be seen as lightweight processes. More discussions will be discussed later.

On the other hand, if you run on IIS 6, you will not use aspnet_wp.exe, but use another process called w3wp.exe. In addition, inetinfo.exe no longer sends HTTP requests to ISAPI, but it still processes other request protocols. Although IIS 6 can run in compatible mode and simulate the behavior of the previous version of IIS, a lot of details on the processing model have changed compared with IIS 5. One major improvement is that, compared with the processing model running on IIS 5, incoming requests are processed at a lower kernel level and then passed to the appropriate ISAPI extension. This avoids inter-process communication technology. From the perspective of performance and resource consumption, inter-process communication is an expensive operation. We will discuss this in depth in the following chapter.

IIS 5.0 Processing Model

This is the default processing model on Windows 2000 and XP machines. As mentioned above, it is located in the IIS inetinfo.exe process. By default, it listens to TCP port 80 to receive HTTP requests and arranges the requests in a queue for processing. If the request is of the ASP. NET type, this processing is delegated to ASP. net isapi extension, that is, aspnet_isapi.dll. Access the aspnet_wp.exe communication between the life-name pipeline and asp.netjob, and the work process finally delivers the request to the ASP. net http runtime environment. Figure 2 shows the processing process graphically.

Figure 2: IIS 5.0 Processing Model

Figure 2 shows an additional element that we have not mentioned before, the ASP. net http runtime environment. This is not the topic of this article and will be explained in detail in subsequent articles. However, for the purpose of this article, we can regard the HTTP runtime environment as a black box, ASP. NET-related processing is completed here, and all the managed code is located here. developers can process it here, from direct HttpRuntime to HttpHandler, and then process the request and generate a response. This is also known as an ASP. NET pipeline or an HTTP runtime pipeline.

One interesting aspect of this processing model is that once all requests are extended by ISAPI, they are transmitted to the ASP. NET workflow. At the same time, only one ASP. NET process instance is active, but there is one exception, which will be discussed later. Therefore, all ASP. NET web applications running in IIS actually run in the working process. However, this does not mean that all applications run in the same context and share all data. As mentioned above, ASP. NET introduces the concept of AppDomain, which is actually a managed lightweight process that provides isolation and security boundaries. Each IIS virtual directory is executed in an independent AppDomain. When any resource belonging to this application is requested for the first time, this AppDomain is automatically loaded into the working process. After the AppDomain is loaded, all the assembly required to process the request is loaded into the AppDomain, and the control is passed to the ASP. NET pipeline for actual processing. Multiple AppDomains can run in the same process. Requests from the same AppDomain can be processed by multiple threads. However, a thread does not belong to the AppDomain and can serve requests from different AppDomains, however, a thread only belongs to one AppDomain at a given time.

For performance reasons, the working process may be recycled based on certain conditions, from the machine in the C: \ windows \ microsoft.net \ Framework \ [framework version] \ CONFIG directory. the config file displays these descriptive conditions, including the process survival time, number of requests being processed, number of requests in the queue, idle time, and memory consumption. Once a preset value is reached, the ISAPI extension creates a new instance for the Worker Process and uses it to process requests. Only at this time can multiple worker processes run concurrently. In fact, the old process instance is not terminated and allows it to process the remaining requests.

IIS 6.0 Processing Model

The IIS 6 processing model is the default model on machines running Windows 2003 Server operating system. It introduces several improvements based on the IIS 5 Processing Model, one of the biggest changes is the introduction of the application pool concept. On IIS 5.x, all web applications, that is, all AppDomains, run in ASP. NET workflows. To achieve better security boundary granularity and customization capabilities, the IIS 6 processing model allows applications to run in different workflows, namely w3wp.exe. Each application pool can contain multiple AppDomains and run in an independent worker process. In other words, it switches from a single process to all applications to each worker process to run an application pool. This mode is also called the worker process isolation mode ).

Another major change compared to the previous mode is the way in which IIS listens for requests. In the IIS 5 model, the iisprocess inetinfo.exe listens to specific TCP ports and receives HTTP requests. In the IIS 6 architecture. the kernel driver of sys processes and queues requests in the kernel level instead of the previous user mode. This method has some advantages over the old mode, it is called the kernel-level request queuing ).

Figure 3: IIS 6.0 Processing Model

Figure 3 shows the main components used to process requests in IIS 6 mode. After the request arrives, the kernel-level device driver http. sys passes it to the correct application pool queue. Each queue belongs to a specific application pool, that is, it belongs to a specific working process. Then, the working process receives requests from the queue. This method greatly reduces the overhead of the named pipeline introduced in IIS 5 mode, because inter-process communication is no longer required, and requests are directly transmitted to the worker process from the kernel-level driver, this has many advantages, such as reliability. In kernel mode, request distribution is not affected by user mode, that is, downtime and failure in the working process. Therefore, even if the working process is down, the system can still receive requests, restart the downtime process.

The worker is responsible for loading ASP. net isapi extensions, which load CLR in sequence and delegate all work to HTTP runtime.

The w3wp.exe worker process is different from the aspnet_wp.exe process in the IIS 5 model. It is irrelevant to ASP. NET. It is used to process any type of requests, and then the worker process determines which ISAPI modules to load Based on the Resource Type it needs to process.

For the sake of simplification, the details in Figure 3 are not marked. A module called Web Management Service (WAS) is loaded in the request via IIS 6, from the application pool queue to the correct worker process. This module reads the state information of the working process and web application from the IIS metadata, and passes the request to the correct working process.

Reference

Simone Busoli-ASP. NET
Internals-The bridge between ISAPI and Application Domains

BrainBell.com-ASP. NET Application Fundamentals

Dino Esposito-Programming Microsoft ASP. NET 2.0 Core Reference

Dino Esposito-Programming Microsoft ASP. NET 2.0 Applications Advanced Topics

George Shepherd-IIS 6.0: New Features Improve Your Web Server's Performance,
Reliability, and Scalability

Fritz Onion-ASP. NET Pipeline: Use Threads and Build Asynchronous Handlers in
Your Server-Side Web Code

Tim Ewald and Keith Brown-HTTP Pipelines: Securely Implement Request Processing, Filtering,
And Content Redirection with HTTP Pipelines in ASP. NET