ASP. NET Process Model: IIS and ASP. NET ISAPI

I. IIS 5.x based Process Model

A notable feature of IIS 5.x is the separation of Web Server and real ASP. NET Application. Iisworking as Web server is running in a process named inetinfo.exe. inetinfo.exe is a Native Executive, not a hosted program, but our real ASP. NET Application runs on a Worker Process called aspnet_wp. It loads CLR during initialization, so it is a managed environment. Let's take a look at the creation of aspnet_wp, how aspnet_wpcommunicates with inetinfo.exe, and how to import requests to ASP. NET Rutime Pipeline in aspnet_wp.

We create a virtual directory to Host the resources under IIS. In principle, we can access all resources placed under the virtual directory through IIS. This file only contains some static Resource files, such as Html files, CSS files, and JS files that require dynamic execution, such as aspx and asmx. We can also mount Remoting and WCF Service Host to IIS. For these static files, IIS directly extracts the corresponding files and returns them to the Client as Http Response. However, for these files that need further processing, IIS must pass the Request to the corresponding handler. After the handler is executed, the final Http Response is returned to the Client through IIS. For IIS, these handlers are embodied through ISAPI Extension. For ASP. NET-based resources, the corresponding ISAPI Extension is ASP. net isapi, which is carried by an aspnet_isapi.dll. The IIS Metadata database maintains a data table called ISAPI Extension Mapping, which is responsible for copying different types of resources to the corresponding ISAPI Extension.

First, the user requests An aspx page through Browser, Brower to the IIS for the Web Server, that is, the target host. After reading this article, iisruns in a process called inetinfo.exe. inetinfo.exe is a Native Executive, not a hosted program. IIS analyzes the Extension of the target resource file for the Request (here it is aspx). Through ISAPI Extension Mapping, it obtains that the corresponding ISPAI is ASP. net isapi, and loads aspnet_isapi.dll. So far, the Request is processed by ASP. net isapi. ASP. NET isapiwill create a Worker process(called as aspnet_wp.exe (if the process does not exist, the CLR will be loaded during the initialization of aspnet_wp.exe, thus being ASP.. NET Application creates a managed runtime environment. During CLR initialization, two important dll values are loaded: AppManagerAppDomainFactory and ISAPIRuntime. Create an Application Domain for the Application through the Create method of AppManagerAppDomainFactory; process the Request through the ProcessRequest of ISAPIRuntime, and then drag the process to ASP. NET Http Runtime Pipeline category, ASP. NET Http Runtime Pipeline is a relatively complex process for processing Http requests. The relevant introduction documents are placed in the next part of this article. Here we can regard it as a black box, which takes over the Request and finally generates Html.

This is basically the entire processing process, which is very simple. However, there are several points that need to be pointed out here.

1. first, only one aspnet_wp process can be run on the same host at a time, and each ASP. NET Application corresponds to an Application Domain, that is to say, each Application runs in the same Worker Process. Application Isolation is based on Application Domain rather than Process.

2. second, ASP. net isapi is not only responsible for creating the aspnet_wp Worker Process, but also responsible for monitoring the Process. If the Performance of aspnet_wp is detected to a lower limit, ASP. net isapi is responsible for killing the process. When aspnet_wp is terminated, subsequent requests will cause ASP. net isapi to re-create a new aspnet_wp Worker Process.

3. Finally, since IIS and Application are running in their respective processes, the communication between them must adopt a specific communication mechanism. Essentially, the communication between the InetInfo Process of IIS and the Worker Process is the communication between different processes of the same machine (local interprocess communications), which is considered for Performance, they use Named pipe-based communication mechanisms. Communication between ASP. net isapi and Worker Process is implemented through a set of Pipe between them. ASP. net isapi uploads the Request to the Worker Process asynchronously and obtains the Response. However, the Worker Process is synchronized to ASP. net isapi to obtain some Server-based variables.

Ii. IIS 6 based Process Model

Reliability and Performance are never the same theme as we are engaged in software development. As a Host based on Http Application IIS, these two aspects are particularly important. From the evolution of IIS 5.x to IIS 6, it is not difficult to see that the improvements made by IIS 6 in the previous version are also based on these two aspects. Before introducing the processing model of IIS 6, let's look at the defects of IIS 5.x:

1. first of all, from the Performance perspective, IIS and application run in different processes, although they use Named Pipe-based Asynchronous communication methods, however, the impact of inter-process-based communication on performance cannot be fundamentally solved.

2. secondly, in terms of Reliability, only one worker process can be run on one machine, and each Application runs in the same process. Although Application Domain-based isolation can provide a certain degree of Reliability, however, once a process crashes, all applications will be affected. Therefore, we sometimes need to provide Process-based isolation.

Based on the Reliability Improvement, IIS 6 introduces the Application Pool. As the name suggests, Application Pool is an application container. in IIS 6, we can create several Application pools. When creating a Web Application, we specify an established application Pool for it. At runtime, an Application corresponds to a Worker Process: w3wp.exe. That is to say, different from the previous version of IIS, for IIS 6, multiple Worker processes can be run on the same machine at the same time, and each Application domain in each Worker Process corresponds to one Application. In this way, not only Application Domain-level isolation can be provided between applications, but you can also place different applications in different Application pools to implement Process-level isolation. For some important applications of Host, this method can provide good Reliability.

In terms of Performance, IIS 5.xlistens to requests through inetinfo.exe and distributes requests to Work Process. In other words, in IIS 5. in User Mode, Request listening and distribution are performed. In IIS 6, this kind of work is transplanted to the kernel Mode. All of this is done through a new component: http. sys.

Note: To prevent users' applications from accessing or modifying critical operating system data, windows provides two processor access modes: User Mode and Kernel Mode ). Generally, the User program runs in User mode, while the operating system code runs in Kernel Mode. The Kernel Mode code allows access to all system memory and all CPU commands. For details about the User Mode and Kernel Mode and some underlying Windows systems, we recommend that you take A look at Microsoft Windows Internal Four Edition, Authored by Mark E. Russinovich & David A. Solomon.

In User Mode, http. sys receives an http request based on aspx, And then it checks which Application Pool the Request-based Application belongs to based on Metabase in IIS. If the Application Pool does not exist, it is created. Otherwise, the request is directly sent to the Queue of the corresponding Application Pool. As I have mentioned above, each Application Pool corresponds to a Worker Process: w3wp.exe, which is undoubtedly running in User Mode. The Application Pool and worker process Mapping are maintained in IIS Metabase. Based on such a ing, the WAS (Web Administrative service) transmits requests that exist in an Application Pool Queue to the corresponding worker process (if not, such a process is created ). When the worker process is initialized, ASP. net isapi and ASP. net isapi are loaded to load CLR. The final process is related to IIS 5. x is the same: Create an Application Domain for the Application through the Create method of AppManagerAppDomainFactory; process the Request through the ProcessRequest of ISAPIRuntime, and then enter the process to ASP. NET Http Runtime Pipeline.