The essence of ASP. NET, IIS and process mode

Asp.net is a good framework for compiling web applications and components. However, due to its scalability, it seems impossible for many people to understand every detail of Asp.net, I have always thought it is necessary to understand the working principles of the grass-roots structure to achieve higher performance during design. In the next series of articles, I will describe the Web lifecycle, from when the request is accepted by the server, it is transferred to the Asp.net pipeline for processing until the delivery information (such as HTML) is generated.

Introduction

Microsoft Active Server Pages (Microsoft Dynamic Web Service), also known as ASP, was first released at the end of 1996, provides programmers with a framework to build a rich and complex web application. A few years later, his infrastructure development has improved a lot. That is, what we know now is that asp.net.asp.net is a framework used to build Web applications. That is to say, it must run on Web Services, generally, the browser sends different types of resource requests to the web server. When dynamic server resource generation technologies (such as CGI, PHP, JSP, and Asp) emerge, all web services can only accept static resource requests from the customer service end and send them back to the customer service end.

On the surface, the interaction between the server and the client is very simple. The session is performed through the HTTP protocol. It is established on both TCP and IP protocols (used to exchange data between two network endpoints connected to different types, as we know about WWW World Wide Web) application-level protocol.

Essentially, any dynamic server technology needs to run on a specific web service. Similarly, Asp.net works closely with Microsoft Internet Information Service, also known as IIS.

Select different methods for different services to generate dynamic resources... We will explain how IIS achieves this when a request information arrives at the server and finally returns it to the client.

IIS and ISAPI extensions

As mentioned above, static resources do not need to be processed by the server; once such resource requests arrive at the server, the server only needs to find its content from the file system and send it to the client in byte stream form through http protocol. Static resources can be images, JavaScript, CSS, or common HTML pages. Obviously, the server needs to know how to differentiate static and dynamic resources, and how dynamic resources need to be processed rather than directly sent back to the client. As a result, the ISAPI extension is introduced. ISAPI is an interface for programming Internet service applications. ISAPI is executed as a module. For example, early win32.dll. IIS relies on ISAPI to process specific resources. By ing ISAPI extensions and files through IIS, each file extension type is associated with a specific ISAPI extension, that is, when a request for a file arrives, IIS processes the request and transfers it to the corresponding ISAPI extension to confirm that the request can be processed.

Figure 1: configure the ISAPI extension ing in iis5.0

　　

ISAPI extensions obviously need to conform to a common interface so that they can be called by IIS and provide necessary data to process requests and generate replies.

1 ,. ASP extension is mapped to ASP. dll ISAPI extension. During the ASP processing period, this component is responsible for executing all required tasks to generate a send-back request. That is, by collecting request information and making it available on the ASP page, other ASP internal objects, parse and execute ASP pages, and finally return results in HTML format.

Although this is a great improvement over CGI technology, Asp.net is more powerful.

After installing Asp.net, Asp.net configures IIS to redirect the file request specified by Asp.net to a new ISAPI extension aspnet_isapi.dll. This extension is somewhat different from the previous ASP. dll extension.

Table I: aspnet_isapi.dll ing in IIS applications

Extensionresource type

. Asaxasp. NET application files. Commonly Used global. asax.

. Ascxasp. Net user control file.

. Ashxhttp handlers, the managed counterpart of ISAPI extensions.

. Asmxasp. NET web services.

. Aspxasp. NET web pages.

. Axdasp. net internal HTTP handlers.

In addition to the file extensions listed in Table 1, the Asp.net ISAPI extensions also manage other file extension types that are not typically accessible to browsers, such as Visual Studio project files, resource files, and configuration files.

ASP. NET Processing Model

So far, we have understood that when a request for an Asp.net file is sent to IIS, it is transferred to aspnet_isapi.dll, which is the main entry point for Asp.net processing. In fact, this extension is obviously dependent on the IIS version on the system. Therefore, the processing model processes the request and generates a send-back request through the sequential operation when Asp.net is running, which may change a little.

. Communication between two processes is established through the named pipeline (we all know that IPC [internal process communication] mechanism. ASP. NET workers execute most tasks of ISAPI extension. Note the essence of each web application and the communication with different virtual directories in IIS. They are executed in the context of the same process of Asp.net. In order to read the context Asp.net introduced the concept of application domains in their respective executions, AppDomains can be considered as a lightweight process. More information will be introduced later.

Callback is no longer used to transmit HTTP requests to ISAPI extensions, although it still serves requests of other protocols. Although IIS6 can run in compatible mode and simulate previous behavior, there are many changes compared to the previous iis5 processing model. During the most recent changes, when the processing model runs on iis5, incoming requests are passed in the form of lower-kernel-level and then passed to the correct ISAPI extension, this avoids excessive operations on internal information processing. In the following section, we will conduct more in-depth research.

Iis5.0 Processing Model

This is the default processing model on Windows and Windows XP systems. As mentioned above, the IIS inetinfo.exe process listens to incoming HTTP requests on TCP port 80 by default and pushes them to the queue for processing. If the request type is Asp.net, the processing will be delegated to Asp.net ISAPI extension aspnet_isapi.dll. In this way, the naming pipeline will communicate with the Asp.net Working Process in turn, and the final working process will process and pass requests to the Asp.net HTTP runtime environment. Chart 2 describes the process.

Figure 2: iis5.0 Processing Model

　　

Figure 2 shows an element we have not mentioned-ASP. net http runtime environment. Currently, he is not the topic of this article. He will be resolved in the following article. HTTP runtime can be regarded as a black box, all ASP.. Net specifies that processing occurs here. All the controlled code runtime sites, from HTTP runtime till httphandler finally processes the request and generates a response, are processed here. This also involves the Asp.net pipeline or the HTTP runtime pipeline.

One interesting thing about this model is that all requests are passed to the Asp.net workflow once extended by ISAPI. Each activity has only one instance and one exception, which will be discussed later. Therefore, the Asp.net web application running on IIS actually runs on the worker process. However, this does not mean that all applications run in the same context and share all their data. It is worth mentioning that Asp.net introduces the appdomain concept, which is essentially a lightweight process that provides independent and secure boundaries. Each IIS virtual directory is executed in an appdomain and will be automatically loaded to the worker process as long as the resource is the application of the first request. Once the appdomain is loaded, in other words, all the required assembly of the current request is loaded to the appdomain-actually passed to the Asp.net pipeline for processing. Several AppDomains can run in the same process in this way, when multiple requests for the same appdomain can come out in multiple threads. Even so, a thread does not belong to one appdomain. It can process multiple requests for multiple different appdomians, but a thread belongs to one appdomain at the same time.

For performance purposes, the worker thread can be recycled according to some standards (configured through the machince. config file. These standards include process lifecycle, number of requests and queues, idle time, and memory allocation. Once the critical value of these parameters is reached, the ISAPI extension will generate a new worker process instance to process the request. In fact, the previous process instance is not closed, but it is the request to terminate the service.

 

Iis6.0 Processing Model

IIS6 is the default in Windows2003. There are several changes and improvements to the iis5 processing model. One of the biggest changes is the application pool concept. In the iis5 series of applications, that is, all AppDomains-run on the Asp.net workflow. To better define security and features, the IIS6 processing model allows applications to run on different copies of the same workflow. Each application pool can contain multiple AppDomains (running on a single worker copy ). in other words, this change is from a single process running all programs to multiple processes running every application pool. This model is also called the work process Isolation Mode.

The exception is a big change compared to the previous model in terms of IIS listening for all incoming data. Inetinfo.exe listens to the specified TCP port in iis5. In IIS6, incoming requests are processed and the queue replaces the previous HTTP call with the core driver at the core level. sys user mode; this method has several advantages over the previous mode called the kernel-level Request queue.

Figure 3 IIS6 Processing Model

　　

Figure 3 consists of request processing. Once a request arrives at the core-level device driver HTTP. sys, it is sent to the corresponding application pool queue. Each queue belongs to a specified application pool.

Worker processes are responsible for loading Asp.net ISAPI extensions, and loading CRL in turn to delegate all work to HTTP runtime.

The process of w3wp.exeis different from the aspnet_wp.exe in iis5. it is not unique to Asp.net and can be used to process any type of requests. The type of ISAPI module to be loaded depends on the type of the required service resource.