asp.net http Runtime composition of the detailed

Asp.net| Detailed Introduction

Regardless of the underlying platform, reliability and performance are the main requirements for all WEB applications, although in a sense the two requirements are conflicting. For example, to build a more reliable and robust application, you might want to detach your WEB server from a specific application and make your application work out-of-process. However, if you work in a memory environment that is different from the WEB server process, the application slows down. Therefore, there is a need to take reasonable steps to ensure that out-of-process code runs as quickly as possible.

In building Microsoft? The ASP.net runtime environment is based on the design principle that takes full account of reliability and performance. The resulting ASP.net process model contains two system elements-an in-process connector that exists in the WEB server process, an external worker process. In addition, the ASP.net runtime structure is scalable enough to automatically use any processor selected in multiprocessor hardware. This pattern is called "Web Garden", which enables multiple worker processes to run concurrently, and each process is in a separate processor.

To sum up, the ASP.NET runtime has three main properties:

Complete separation between the application and the ASP.net worker process. The lifetime of the application is never affected by the life of the worker process that provides the service. In other words, when the application starts and is running, the worker process can terminate at any time.
Although ASP.net applications never run in-process within a WEB server, in most cases their overall performance is still close to the performance of an in-process application.

Provides built-in and configurable support for the Web Garden architecture. By simply checking the settings in the configuration file, the worker process can clone itself to take advantage of all CPUs that are closely related to the process. Therefore, in most cases, the scalability you get on a multiprocessor computer will grow linearly. (This is covered in more detail later in this article.) ）

This article describes the elements of the ASP.net runtime environment, and then steps through the "long and tortuous" process of turning URL requests into plain HTML text.

Unless otherwise stated, the following descriptions refer to the default process model for ASP.net, Microsoft? The only model in Internet information Services (IIS) 5.x.
Components of a ASP.NET structure

Executing the asp.net application requires the support of the hosting Web server. At Microsoft? Windows? Server platform, the WEB server is represented by an IIS executable file named Inetinfo.exe. The Windows 2000 and above versions of the operating system itself provide a WEB server. But you need to be aware that at Microsoft? In Windows server™2003, IIS and asp.net are not installed by default and must be added to the system by clicking the Add or Remove Programs applet in Control Panel.

IIS is an unmanaged executable program that provides an extensible model based on ISAPI extension modules and filter modules. By writing such modules, developers can directly manage requests for a specific resource type and receive the current request in each predefined step. Extensions and filters are some DLLs that can export functions with known names and signatures. These plug-in components are registered and configured in the IIS configuration database.
　
Only a handful of resource types that are requested by the client are processed directly by IIS. For example, incoming requests for HTML pages, text files, JPEG, and GIF images are handled by IIS. Requests for Active Server Page (*.asp) files are resolved by invoking an ASP-specific extension module called Asp.dll. Similarly, requests for ASP.net resources (for example, *.aspx, *.asmx, *.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 a variety of resource types, including WEB services and HTTP handler calls.

The asp.net ISAPI extension is a Win32 DLL and does not integrate managed code. It is the control center that receives and assigns requests for various asp.net resources. By design, the module exists in the IIS process and runs under the SYSTEM account with administrator privileges. This account cannot be modified by developers and system administrators. The asp.net ISAPI extension is responsible for invoking the ASP.net worker process (aspnet_wp.exe), which is also responsible for controlling the execution of the request. In addition to scheduling requests, the ASP.net ISAPI monitors the operation of the worker process and cancels the process when performance is reduced to a certain extent.

A worker process is a small piece of Win32 shell code that integrates the common language runtime (CLR) and runs managed code. It is responsible for processing requests for ASPX, ASMX, and ASHX resources. In general, this process has only one instance on a given computer. All currently activated ASP.net applications are running in them, and each application is in a separate AppDomain. However, as mentioned earlier, the worker process supports Web Garden mode, where the same copy of the process runs in a CPU that is closely related to the process. (For more information, see the "Web Garden Model" section later in this article.) ）

Communication between ISAPI and worker processes is done using a set of named pipes. Named pipes are a Win32 mechanism for transferring data across process boundaries. As the name suggests, named pipes work the same way as pipelines: enter data at one end and output the same data on the other end. A pipe is established to connect to a local process or to a process running on a remote computer. For local interprocess communication, pipelines are the most efficient and flexible tool in Windows.

To ensure optimal performance, ASPNET_ISAPI uses an asynchronous named pipe to forward requests to the worker process and get a response. On the other hand, the worker process uses a synchronous 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 pipes and uses overlapping operations to handle connections at the same time through a small thread pool. When the data exchange operation through the pipeline is finished, the completion routine disconnects the client and uses the pipe instance again to service the new client. Thread pooling and overlapping operations ensure that the performance of the ASP.net ISAPI is at a satisfactory level. However, the ASPNET_ISAPI extension will never handle HTTP requests.

The processing logic of the ASP.NET request can be summed up as the following steps:

When the request arrives, IIS checks the resource type and invokes the asp.net ISAPI extension. If the default process model is enabled, ASPNET_ISAPI queues the request and assigns the request to the worker process. All request data is sent through asynchronous I/O. If the IIS 6 process model is enabled, the request is automatically queued in a worker process (w3wp.exe), which is used to process the IIS application pool to which the application belongs. The IIS 6 worker process does not know anything about ASP.net and managed code, it simply handles *.aspx extensions and loads ASPNET_ISAPI modules. When ASP.net ISAPI runs in the IIS 6 process model, it works differently, loading the CLR only in the context of the W3wp.exe worker process.

When a request is received, the ASP.net worker process notifies the ASP.net ISAPI that it will service the request. Notifications are implemented through synchronous I/O. The synchronization model is used because the request is marked as "executing" in the ISAPI internal request table before the worker process can begin processing it. If a request has been processed by a special worker process, it cannot be assigned to another process unless the original process has been canceled.
Executes the request in the context of the worker process. Sometimes, a worker process may need to recall the ISAPI to complete the request, which is to say enumerate the server variables. In this case, the worker process uses the synchronization pipeline, because it keeps the order of the request processing logic.

When finished, the response is sent to the ASPNET_ISAPI that opened the asynchronous pipe. The requested status is now changed to "done" and will then be deleted from the request table. If the worker process crashes, all requests that are being processed remain "executing" and persist for a period of time. If ASPNET_ISAPI detects that the worker process has been canceled, it automatically terminates the request and releases all the associated IIS resources.

The description above refers to the default ASP.net process model, which is the working model that runs in IIS 5.x. The default mode of work for IIS 6 (provided by Windows Server 2003) also has an impact on the ASP.net process model. When integrated in IIS 6.0, ASP.net 1.1 automatically adjusts its way of working to accommodate the hosting environment. At this point, you no longer need to use the ASPNET_WP worker process, and some of the configuration parameters defined in the Machine.config file are ignored. From a asp.net point of view, the biggest change in IIS 6 is that everything about the request is under ASPNET_ISAPI control and is in the context of the W3wp.exe worker process. The account for the worker process is the account that is set up for the application pool to which the Web application belongs. By default, the account is networkservice-, which is a built-in weak account that is functionally equivalent to the ASPNET.

[1] [2] [3] Next page