Asp.net Running Mechanism in IIS 6

Preface

I have always wanted to learn how the Asp.net program runs, because it is often known that the underlying things can help us better master a technology. Finally, I tried to Google a lot of blog materials last week, following the ideas and perspectives of the bloggers, I learned step by step how Asp.net runs in IIS6 (but it is far from the bottom layer ). In addition, I think that many times, to understand a knowledge point, we usually need different materials and follow the ideas or perspectives of different authors. This may make it easier to understand this knowledge point.

On the other hand, because IIS6 is used most of the time, iis7 has not changed much in the core aspect of IIS6, so the materials I read are for IIS6, and iis5 is a little outdated, moreover, Microsoft has greatly improved IIS6's iis5 deficiencies (mainly in performance and availability). Therefore, this blog describes IIS6.

 

Start

First:

[1]: In Windows Server 2003, an HTTP. sys core component is added to listen for HTTP Communication. In the past, IIS was responsible for HTTP Communication, because IIS is a Web server, and it seems reasonable to listen for HTTP Communication. However, because IIS is running in "user mode" and cannot access some system resources. the IIS (for example, iis5) before sys components communicate with the named pipepipeline and the worker (called aspnet_wp.exe in iis5) who monitors HTTP requests and uses the named pipeline (called aspnet_wp.exe in iis5. as a system driver, sys runs in kernel mode and can directly access system resources, besides, IIS6 performs better than iis5. it can communicate with workers in a more efficient way than named pipes (in IIS6, it is called "w3wp.exe. On the other hand, because HTTP. sys is no longer an integral part of IIS and is independent from IIS, even if the IIS process crashes, HTTP. sys can continue to monitor HTTP requests.

[2]:When HTTP. sys receives an HTTP request, it determines which application pool to use to process the HTTP request based on metadata in iis6. In iis5, there is only one worker process to run the Asp.net program. Different Asp.net programs run in different application domains of the worker program to ensure the independence of each program. But the disadvantage is also obvious: if the worker process crashes, it will cause all Asp.net programs to crash, even if they are in different app domains. In this way, you can avoid process crashes caused by a program exception to the maximum extent, and then be implicated in failure of other programs. By default, an application pool has only one worker process (which can be configured in IIS), but the concept of APP domain remains unchanged. Of course, IIS6 can manage multiple application pools.

 [3]:After the HTTP request is sent to w3wp.exe, w3wp.exe calls the corresponding ISAPI based on the request. For Asp.net requests, of course, it calls aspnet_isapi.dll. This is also an improvement of iis5 in IIS6. In iis5, When IIS receives an HTTP request, it calls the corresponding ISAPI and then enables (or calls) the worker process. In IIS6, A worker process receives an HTTP request and creates (or calls) a worker process.

 [4]:When the HTTP request enters aspnet_isapi.dll, it means that. NET is started to process the request. Because iis6and w3wp.exe both run in an unmanaged code environment, while Asp.net runs in a hosted code environment, communications between the hosted code environment and the unmanaged code environment are handed over to the ECB.

 [5]:The ISAPI runtime class loads CLR to run the Asp.net program and encapsulates HTTP requests into a workerrquest object. However, I have not figured out the specific significance of this object ~

 [6]:After an HTTP request is encapsulated as a workerrequest object, it is further transferred to an object of the HTTP runtime class for processing. The httpruntime object is used to further process workerrequest into an httpcontext object. The httpcontext object has all the data of the HTTP request, including the request address, host port, cookie, and session.

 [7]:In fact, the Asp.net program is the processing factory for HTTP requests: Processing (or producing) HTML content based on the customer's HTTP Request (which page is requested, and what parameters are there. The HTTP Request (here, this HTTP request has been encapsulated into an httpcontext object) is the raw material. Now that raw materials are available, you need a place where raw materials can be processed, which is the httpapplication class. The httpapplication class controls the processing logic of httpcontext.

 [8]:However, the httpapplication class does not really process and control HTTP requests. It only provides local information. What actually processes HTTP requests is called the Asp.net pipeline chain (Asp.net pipeline) logic. The Asp.net pipeline chain consists of various HTTP module modules and an HTTP handler. After an HTTP request enters the Asp.net pipeline, it triggers various events, such as beginrequest, onerror, and endrequest. Asp.net calls different modules (such as the caching module and session module) in different events to perform different processing operations on HTTP requests. This also means that we can write a module to control or process HTTP requests based on our actual needs. Typical cases include url_rewriter and image anti-leech. Url_rewriter works as follows: after an HTTP request enters the Asp.net pipeline and triggers the begin request event, the request address is converted to the actual request address according to the set method, anti-leech checks the URL Referer of the image request after the HTTP request enters the Asp.net pipeline and triggers the begin request event to determine whether the request to the image is cross-origin, if yes, the request is directed to the address of the anti-leech image.

 [9]:After the HTTP modules layer-by-layer processing is passed, the HTTP handler class is finally introduced. The HTTP handler is the place where the real service response to the HTTP request is made, generally, HTTP handler is the class in our aspx and CS files. It becomes a page class, and the page class inherits the page class, which inherits the ihttphandler interface. Here, we write code to process HTTP requests, such as querying databases, processing data, generating table tags, and finally outputting HTML to the client. Generally, an Asp.net program can have multiple HTTP modules to control requests, but only one HTTP handler can process requests.