ASP. net http runtime Composition [Post]

Introduction

No matter which underlying platform is used, the reliability and performance are for all web applications.ProgramIn a sense, these two requirements are mutually contradictory. For example, to build a more reliable and robust application, you may need to separate the Web server from a specific application so that the application can work outside the process. However, if you work in a memory environment different from the Web server process, the application slows down. Therefore, reasonable measures must be taken to ensure thatCodeRun as quickly as possible.

When building Microsoft? When ASP. NET is running, the reliability and performance are fully considered. The obtained ASP. NET process model contains two system elements: one in-process connector in the Web server process and one external auxiliary process. In addition, the ASP. NET runtime architecture is highly scalable and can automatically use any processor selected in the multi-processor hardware. This mode is called "Web Garden". It allows multiple auxiliary processes to run simultaneously, and each process is in an independent processor.

In summary, ASP. NET runtime has three attributes:

The application and the ASP. NET auxiliary process are completely separated. The life of the auxiliary process that provides services will never affect the life of the application. In other words, the secondary process can be terminated at any time when the application is started and running.
Although ASP. NET applications never run in the process on the Web server, the overall performance of ASP. NET applications is close to that of in-process applications in most cases.

Provides built-in and configurable support for the Web garden architecture. You only need to check the settings in the configuration file, and the secondary process can clone itself to take advantage of all CPU resources that are closely related to the process. Therefore, in most cases, the scalability you obtain on a computer with a multi-processor will grow linearly. (This article will be detailed later .)

This article introduces the components of the ASP. NET runtime environment, and then describes the process of changing from a URL request to a pure HTML text one by one.

Unless otherwise specified, the default Process Model of ASP. NET, Microsoft? The unique model in Internet Information Services (IIS) 5.x.

ASP. NET Component

The execution of ASP. NET applications requires the support of the host web server. In Microsoft? Windows? The Web server is represented by an IIS Executable File named inetinfo.exe. Windows 2000 and later versions provide Web servers. But note that in Microsoft? In Windows Server 2003, IIS and ASP. NET are not installed by default. You must add them to the system by clicking the add or delete programs Applet in the control panel.

IIS is an unmanaged executable program that provides an extensible Model Based on the ISAPI extension module and filter module. By writing such a module, developers can directly manage requests for a specific resource type and receive the current request in each predefined step. Extensions and filters are some DLL that can be used to export functions with known names and signatures. These plug-in components are registered and configured in the IIS configuration database.

Only a few types of resources requested by the client are directly processed by IIS. For example, IIS processes incoming requests to HTML pages, text files, JPEG and GIF images. Requests to the Active Server Page (*. asp) file are parsed by calling the ASP extension module named ASP. dll. Similarly, requests for ASP. NET Resources (for example, *. aspx, *. asmx, and *. ashx) are passed to the ASP. net isapi extension. The system component is a Win32 DLL named aspnet_isapi.dll. ASP. NET extensions can handle multiple resource types, including Web Services and HTTP processing program calls.

ASP. net isapi extension is a Win32 DLL that is not integrated with managed code. It is the control center for receiving and distributing requests from various ASP. NET Resources. According to the design, this module exists in the IIS process and runs under the system account with administrator permissions. Developers and System Administrators cannot modify this account. ASP. net isapi extension is responsible for calling the ASP. NET auxiliary process (aspnet_wp.exe) and controlling the execution of requests. In addition to request arrangement, ASP. net isapi also monitors the running status of the auxiliary process and cancels the process when the performance is reduced to a certain extent.

A helper process is a short Win32 shell code that integrates the Common Language Runtime Library (CLR) and runs managed code. It processes requests to aspx, asmx, and ashx resources. Generally, this process has only one instance in a given computer. All currently activated ASP. NET applications run in it, and each application is located in an independent appdomain. However, as mentioned above, the secondary process supports the Web garden mode, that is, the same copies of the process run on the CPU closely related to the process. (For more information, see "Web garden model .)

Communication between ISAPI and auxiliary processes is performed using a set of named pipelines. A named pipe is a Win32 mechanism used to transmit data across process boundaries. As the name implies, a named pipe works in a similar way as a pipe: It inputs data at one end and outputs the same data at the other end. The created MPs queue can connect both local processes and processes running on a remote computer. For communications between local processes, pipelines are the most effective and flexible tools in windows.

To ensure optimal performance, aspnet_isapi uses an asynchronous naming pipeline to forward requests to the secondary process and obtain responses. On the other hand, the auxiliary process uses the synchronization pipeline when it needs to query information about the IIS environment (that is, the server variable. The aspnet_isapi module creates a fixed number of named pipelines and uses overlapping operations to process connections at the same time through a small thread pool. After the data exchange operation is completed through the pipeline, the completion routine will disconnect the client and re-use the pipeline instance as the new client service. The thread pool and overlapping operations can ensure that the performance of ASP. net isapi can reach a satisfactory level. However, the aspnet_isapi extension will never process HTTP requests.

The processing logic of ASP. NET requests can be summarized as follows:

When the request arrives, IIS checks the resource type and calls ASP. net isapi extension. If the default process model is enabled, aspnet_isapi queues requests and assigns them to the secondary process. All request data is sent through asynchronous I/O. If the IIS 6 process model is enabled, requests are automatically queued in the secondary process (w3wp.exe), which is used to process the IIS application pool to which the application belongs. The IIS 6 auxiliary process does not understand ASP. NET and the managed code in any situation. It only processes *. aspx extensions and loads the aspnet_isapi module. When ASP. net isapi is run in the IIS 6 process model, it works in different ways. It only loads CLR in the context of the w3wp.exe auxiliary process.

After receiving the request, the ASP. NET auxiliary process notifies ASP. net isapi that it will serve the request. Notifications are implemented through synchronous I/O. The synchronous model is used because the secondary process can process a request only when it is marked as "executing" in the ISAPI internal request table. If a request has been processed by a special auxiliary process, it cannot be specified to another process unless the original process has been canceled.
Execute the request in the context of the auxiliary process. Sometimes, the Helper process may need to call back ISAPI to complete the request, that is, to enumerate server variables. In this case, the secondary process uses a synchronization pipeline because it can maintain the order of request processing logic.

After completion, the response is sent to the aspnet_isapi that opens the asynchronous pipeline. Now, the Request status changes to "done" and will be deleted from the request table. If the secondary process crashes, all the requests being processed will remain in the "executing" status for a period of time. If aspnet_isapi detects that the secondary process has been canceled, it will automatically terminate the request and release all related IIS resources.

The above description refers to the default ASP. NET process model, that is, the working model running in IIS 5.x. The default working mode of IIS 6 (provided by Windows Server 2003) also affects the ASP. NET process model. When integrated in IIS 6.0, ASP. NET 1.1 automatically adjusts its work mode to adapt to the host environment. In this case, you no longer need to use the aspnet_wp auxiliary process. Some configuration parameters defined in the machine. config file are also ignored. From the ASP. NET perspective, the biggest change in IIS 6 is that all requests are under the control of the aspnet_isapi and are in the context of the w3wp.exe auxiliary process. The account of the secondary process is the account set for the application pool to which the web application belongs. By default, this account is NetworkService-, which is a built-in weak account and is functionally equivalent to ASPnet.

A secondary process is controlled by the recycling function. Process recycling has the aspnet_isapi function. When the existing process consumes too much memory, the response is too slow, or the new process can be started automatically. In this case, the new request will be processed by the new instance, and the new instance will become a new active process. However, all requests specified for the old process remain suspended. If the old process stops the pending request and enters the idle state, the process is terminated. If the secondary process crashes or stops processing requests for other reasons, all pending requests will be re-assigned to the new process.

Although ASP. net isapi and auxiliary processes are the main components of the ASP. NET runtime structure, some other executable files also play a role. The following table lists all these components.

Table 1: executable files that constitute the ASP. NET Runtime Environment

Name type account?
Aspnet_isapi.dll Win32 DLL (ISAPI extension) local system?
Aspnet_wp.exe Win32 EXE ASPnet
Aspnet_filter.dll Win32 DLL (ISAPI filter) local system?
Aspnet_state.exe Win32 NT Service ASPnet

The aspnet_filter.dll component is a small Win32 ISAPI filter used to back up the cookieless session Status of ASP. NET applications. In Windows Server 2003, when the IIS 6 process model is enabled, aspnet_filter.dll also filters out requests for non-executable Resources in the bin directory.

The role of aspnet_state.exe is more important to Web applications because it is used to manage session states. This service is optional and can be used to store session status data outside the memory space of Web applications. This executable file is an NT service that can be run locally or remotely. After the service is activated, you can configure the ASP. NET application to save all session information in the memory of the process. A similar solution is to provide a more reliable data storage method, which is not affected by process recovery and ASP. NET application faults. This service runs under the Local Account of ASPnet, but can be configured using the Service Control Manager interface.

Another executable file to be introduced is aspnet_regiis.exe, although strictly speaking, it does not belong to the ASP. NET runtime structure. The utility can be used to configure the environment to execute different versions of ASP. NET in parallel on a computer, and can also be used to repair corrupted configurations of IIS and ASP. NET. This utility is used to update the script ing stored in the root directory and subdirectory of the IIS configuration database. Script ing is an association between resource types and ASP. NET modules. Finally, you can use this tool to display the status of installed ASP. NET versions and perform other configuration operations, such as granting NTFS permissions to specific folders and creating client script directories.

Web garden Model

The Web garden model can be configured through the <processmodel> section in the machine. config file. Note that the <processmodel> section is the configuration section that cannot be placed in the application-specific web. config file. This means that the Web garden mode can be applied to all applications running on the computer. However, by using the <location> node in the machine. config source file, you can adjust the computer settings for each application.

The <processmodel> section has two attributes that affect the Web garden model: webgarden and cpumask. The webgarden attribute accepts a Boolean value, indicating whether multiple auxiliary processes are used (one CPU corresponds to one process ). By default, the value of this attribute is false. The cpumask attribute stores a DWORD value. The binary representation of this value provides bitwise shielding for CPUs that can run ASP. NET auxiliary processes. The default value is-1 (0 xffffff), indicating that all available CPUs can be used. If the webgarden attribute is false, the content of the cpumask attribute is ignored. The cpumask attribute also sets an upper limit for the number of running copies of aspnet_wp.exe.

It is often said that "Not all the flash is gold", which is suitable for use here. The Web garden mode allows multiple secondary processes to run simultaneously. However, you must note that all processes have their own application status, in-process session Status, ASP. NET cache, static data, and other content required to run the application. After the Web garden mode is enabled, Asp. net ISAPI will start as many auxiliary processes as possible based on the number of cpus. Each auxiliary process is a complete clone of the next process (each process is closely related to the corresponding CPU ). To balance the workload, incoming requests are divided between running processes in a single loop. Auxiliary processes are recycled just as they are in a single processor. Note that ASP. Net inherits all the CPU usage restrictions of the operating system and does not include the custom semantics of the restrictions.

In short, the Web garden model does not apply to all applications. The more States an application has, the more performance loss it has. The work data is stored in the shared memory block so that the input changes of a process can be immediately known to other processes. However, when processing the request, the work data is copied to the context of the process. Therefore, each auxiliary process processes its own work data, and the more states the application, the larger the performance loss. Given this, careful and Wise application benchmarking is absolutely necessary.

Changes made to the <processmodel> section of the configuration file take effect only after IIS is restarted. In IIS 6, parameters in Web garden mode are stored in the IIS configuration database, and the attributes of webgarden and cpumask are ignored.

HTTP Pipeline

After the ASP. net isapi extension starts the auxiliary process, it will pass some command line parameters. The auxiliary process uses these parameters to execute the tasks that need to be executed before the CLR is loaded. The passed values include the authentication level required for the security of COM and DCOM, the number of named pipelines that can be used, and the IIS Process Identity. The name of the named MPs queue is randomly generated using the IIS process identifier and the number of allowed MPs queues. The secondary process does not receive the name of an available MPs queue, but can receive the information required to identify the MPs queue name.

COM and DCOM Security and Microsoft? What is the relationship between. NET Framework? Actually, CLR is provided as a COM object. More accurately, CLR itself is not composed of COM code, but the interface pointing to CLR is a COM object. Therefore, the method used by the auxiliary process to load CLR is the same as that used to load COM objects.

When An ASPX request encounters IIS, the web server assigns a token based on the selected authentication model (Anonymous, windows, basic, or Digest. When the secondary process receives the request to be processed, the token is passed to the secondary process. Requests are obtained by threads in the auxiliary process. This thread gets the identity token from the IIS thread that originally passed in the request. In aspnet_wp.exe, the actual account responsible for processing the request depends on how the simulation is configured in a special ASP. NET application. If the simulation is disabled (set by default), the thread runs under the account of the auxiliary process. By default, this account is ASPnet in the ASP. Net Process Model and NetworkService in the IIS 6 process model. Both accounts are "weak" accounts and provide limited functions to effectively defend against revert-to-self attack attacks ). (A reply attack is a token that returns the Security token of the simulated client to the parent process. Allocating a weak account to a secondary process can defeat such attacks .)

In summary, a major task completed by the ASP. NET auxiliary process is to send requests to a series of managed objects called HTTP pipelines. To activate the HTTP pipeline, you can create a new instance of the httpruntime class and call its processrequest method. As mentioned above, ASP. NET always runs only one auxiliary process (unless the Web garden model is enabled), which manages all web applications in an independent appdomain. Each appdomain has its own httpruntime class instance, that is, the input point in the pipeline. The httpruntime object initializes a series of internal objects that help implement the request. The helper object includes the cache manager (Cache object) and the internal file system monitor (used to detect changes to the source files that make up the application ). Httpruntime creates a context for the request and fills the context with HTTP information related to the request. The context is represented by an instance of the httpcontext class.

Another helper object created at the beginning of the HTTP runtime setting is a text writer that contains the browser's response text. The text writer is an instance of the httpwriter class. This object caches the text sent programmatically by PAGE code. After the HTTP Runtime is initialized, it searches for the application objects that implement the request. The application object is an instance of the httpapplication class, which is the class behind the global. asax file. Global. asax is optional for programming, but is required for building structures. Therefore, if no build class exists in the application, the default object must be used. The ASP. Net runtime contains several intermediate factory classes that can be used to find and return valid handler objects to process requests. The first factory class used throughout the process is httpapplicationfactory. Its main task is to use URL Information to find the matching relationship between the URL virtual directory and the collection of httpapplication objects.

Application factory behaviors can be summarized as follows:

The factory class maintains the httpapplication Object pool and uses them to process application requests. The life of the pool is the same as that of the application.

The factory class extracts information about the application type (Global. asax class), set the file used to monitor changes, create application status, and trigger the application_onstart event.

The factory class obtains an httpapplication instance from the pool and puts the requests to be processed into the instance. If no available object exists, a new httpapplication object is created. To create an httpapplication object, you must first compile the global. asax application file.

Httpapplication starts to process the request and can only process the new request after the request is completed. If a new request from the same resource is received, other objects in the pool are processed.

The application object allows all registered HTTP modules to pre-process requests and find the type of processing program most suitable for processing requests. This is done by finding the extension of the requested URL and the information in the configuration file.

The HTTP handler is a class that implements the ihttphandler interface .. Net Framework provides some predefined processing programs for common resource types, including aspx pages and Web services. The

The ihttphandler interface provides two methods: isreusable and processrequest. The former returns a Boolean value indicating whether the handler can be pooled. (Most predefined handlers are collected, but you can define the handler that requires a new instance each time .) The processrequest method contains all the logic required to process specific types of resources. For example, the ASPX page handler is based on the following pseudo code:

Private void processrequest ()
{
// Determine whether the request is PostBack)
Ispostback = determinepostbackmode ();

// Trigger aspxSource codePage_init event
Pageinit ();

// Load viewstate to process sent values.
If (ispostback ){
Loadpageviewstate ();
Processpostdata ();
}

// Trigger the page_load event of the aspx source code
Pageload ();

// 1) process the sent value again (when
// When dynamically creating controls)
// 2) upgrade server-side events with attribute changes to input-driven
// Control (that is, the status of the check box changes)
// 3) execute all Code related to the send-back event
If (ispostback ){
Processpostdatasecondtry ();
Raisechangedevents ();
Raisepostbackevent ();
}

// Trigger the page_prerender event of the aspx source code
Prerender ();

// Save the current status of the control to viewstate.
Savepageviewstate ();

// Present the page content to HTML
Rendercontrol (createhtmltextwriter (response. Output ));
}

Regardless of the resource type called, the model based on the HTTP handler is the same. The only element that changes with the resource type is the handler. The httpapplication object is responsible for finding which handler should be used to process requests. The httpapplication object is also responsible for detecting changes made to the dynamically created assembly that represents resources (such as the. ASPX page or. asmx Web Service. If changes are detected, the application object will ensure that the latest source of the requested resource is compiled and loaded.

Temporary files and page assembly

To fully understand ASP. net http runtime, let's analyze the changes in the file system layer when requesting ASP. NET pages. Next, you will learn about a group of dynamically created temporary files managed and monitored by HTTP MPs queue objects.

Although the core code of the page can be isolated from the C # or Microsoft? Visual Basic? . Net class, but you can write and deploy web pages as. aspx text files. For pages to be displayed as URLs, The. aspx file must always be available in the web space of the application .. The actual content of the aspx file determines the Assembly (or multiple Assembly) to be loaded by the Application object ).

According to the design, the httpapplication object will look for a class named according to the requested aspx file. If the page is named sample. aspx, the corresponding class to be loaded is named ASP. sample_aspx. Application objects search for such classes in all Assembly folders of the Web application, including the Global Assembly Cache (GAC), Bin subfolders, and temporary ASP. NET files folders. If such a class is not found, the HTTP structure will be analyzed. source code of the aspx file, create a C # Or Visual Basic.. Net class. the language set on the ASPX page), and compile it at the same time. The name of the newly created assembly is randomly generated and located in the application-specific subfolders. The path is as follows: C: \ WINDOWS \ Microsoft. net \ framework \ v1.1.4322 \ temporary ASP.. Net files.

Subfolders v1.1.4322 are specific to ASP. NET 1.1. If you are using ASP. NET 1.0, the sub-Folder version will be different, that is, the sub-Folder name is v1.0.3705. When you access the page again, the Assembly already exists and does not need to be created again. However, how does the httpapplication object determine whether the page-specific Assembly exists? Does it scan a large number of folders each time? No, not like this.

The application object only displays the content of a special folder in the temporary ASP. NET Files folder. The specific path (application-specific path) is returned by the httpruntime. codegendir attribute. If this is the first time you access the. aspx file (that is, the page assembly has not been created), there will be no XML file starting with the ASPX page name in this folder. For example, the sample. ASPX page with dynamic assembly should have the following entries:

Sample. aspx. XXXXX. xml

The XXXXX placeholder is a hash code. By reading the content of the XML file, the application object can understand the name of the assembly to be loaded and the class to be obtained in it. The following code snippet is a typical content of this helper file. The Assembly name that contains the ASP. sample_aspx class is mvxvx8xr.

<Preserve assem = "mvxvx8xr" type = "ASP. sample_aspx">
<Filedep name = "C: \ Inetpub \ wwwroot \ vdir \ sample. aspx"/>
</Preserve>

Of course, this file is created only when the source code of the filedep file is analyzed to generate a dynamic assembly. Any changes made to the filedep file will invalidate the Assembly and must be re-compiled in the next request. Note that the implementation process may change significantly in future versions of the ASP. NET architecture. For whatever reason, you must be very careful as long as you decide to use it in the current application.

ASP. NET verifies whether the old assembly can be deleted to create a new assembly for the page due to updates. If the old Assembly only contains the modified page class, ASP. NET will try to Delete and replace the modified assembly. Otherwise, a new assembly will be created while the old assembly is retained.

During the deletion process, ASP. NET may find that the Assembly file has been loaded and locked. In this case, you can add a ". Delete" extension for the old assembly to rename it. (Note: All Windows files can be renamed during use .) As long as the application is restarted (for example, due to changes to an application file such as Global. asax and web. config), these temporary. delete files will be deleted. However, ASP. NET does not delete these files when processing the next request.

Note that by default, each ASP. NET application can recompile up to 15 pages before the entire application restarts, and some session and application data will be lost. When the number of recent compilations exceeds the threshold set in the numrecompilesbeforeapprestart attribute of the

Summary

ASP. NET applications have two main features: Process Model and Page Object Model. ASP. NET uses some features of IIS 6.0 in advance, while IIS 6.0 is a brand new and groundbreaking Microsoft Web Information Service provided in Windows Server 2003. It is particularly worth mentioning that ASP. NET Applications Running in independent auxiliary processes behave the same as all applications in IIS 6. In addition, although exceptions, memory leaks, or program errors occur during ASP. NET running, auxiliary processes can still be automatically reclaimed to ensure excellent performance. This function has become a system function of IIS 6.0.

In this article, I have summarized the basic knowledge of the default ASP. Net Process Model and the interaction between IIS-level code (ASP. NET ISAPI extension) and auxiliary processes. The latest differences between the process model and IIS 6 are also introduced.