ASP. NET insider-IIS Processing Model

Introduction
Microsoft's Active serverpages, namely 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 applicationprogramming 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.
All requests related to asp.netare sent to an external working process called aspnet_wp.exe by isapiextension when iis5.xis running. The asp.netisapiextension running in the iisprocess inetinfo.exetransfers the 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 processcommunication) 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 IIS 6 or 6, you will not use aspnet_wp.exe, but another process called w3wp.exe is used. 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, many details have changed compared with iis5. One major improvement is that, compared with the processing model running on iis5, 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 port tcp80 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. netisapi 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 yet, ASP. nethttp 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. netweb 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 worker process may be recycled based on certain conditions, from the machine in the c: \ windows \ microsoft.net \ framework \ [frameworkversion] \ 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 iis5 processing model, one of the biggest changes is the introduction of the application pool concept. . 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 processisolation mode ).
Another major change compared to the previous mode is the way in which IIS listens for requests. In the iis5 model, the iisimport inetinfo.exe listens to specific TCP ports and receives HTTP requests. In the IIS6 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 IIS6 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 the iis5 mode, because inter-process communication is no longer required, and requests are directly transferred from the kernel-level driver to the working process. This has many advantages, for example, 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.