Comparison of ASP.net request processing process of IIS5 IIS6 IIS7 (1)

ASP.NET is a very powerful platform for building Web applications. It provides great flexibility and capabilities so that you can use it to build all types of Web applications.

Most people are only familiar with high-level frameworks such as WebForms and WebServices -- these are at the top of the ASP.NET hierarchy.

The information in this article is collected and compiled from various Microsoft public documents. By comparing the request processing processes of the three generations of IIS, IIS5, IIS6, and IIS7, we can become familiar with the underlying mechanism of ASP.NET and understand how requests are processed from the Web. The server communicates to the ASP.NET runtime. By understanding the underlying mechanism, we can have a deeper understanding of ASP.net.

A notable feature of IIS 5.x is the separation of Web Server and real ASP.NET Application. As a Web Server, IIS runs on a process called InetInfo.exe. InetInfo.exe is a Native Executive and is not a managed program. Our real ASP.NET Application runs on a Worker Process called aspnet_wp. Above, the CLR is loaded when the process is initialized, so this is a managed environment.

ISAPI: refers to applications that can handle various suffixes. ISAPI is the abbreviation of the following words: Internet Server Application Programe Interface, Internet Server Application Programming Interface.

1. First, only one aspnet_wp process can be run on the same host at the same time. Each ASP.NET Application based on the virtual directory corresponds to an Application Domain, which means that each Application runs on the same In Worker Process, the isolation between Applications is based on Application Domain, not Process.

2. Secondly, ASP.NET ISAPI is not only responsible for creating the aspnet_wp Worker Process, but also for monitoring the process. If it is detected that the Performance of aspnet_wp drops to a certain set lower limit, ASP.NET ISAPI will be responsible for ending the process. When aspnet_wp ends, subsequent Request will cause ASP.NET ISAPI to re-create a new aspnet_wp Worker Process.

3. Finally, since IIS and Application run in their own processes, the communication between them must use a specific communication mechanism. Essentially, the communication between the InetInfo process where IIS is located and the Worker Process is communication between different processes on the same machine (local interprocess communications). For performance considerations, a communication mechanism based on Named pipe is used between them. The communication between ASP.NET ISAPI and Worker Process is implemented through a set of Pipes between them. Also for Performance reasons, ASP.NET ISAPI transmits the Request to the Worker Process in an asynchronous manner and obtains the Response, but the Worker Process obtains some Server-based variables from the ASP.NET ISAPI in a synchronous manner.

IIS 5.x monitors Request through InetInfo.exe and distributes Request to Work Process. In other words, the monitoring and distribution of Requests in IIS 5. : http.sys is responsible.

Note: In order to prevent user applications from accessing or modifying critical operating system data, Windows provides two processor access modes: User Mode and Kernel Mode. Generally, user programs run in User mode, while operating system code runs in Kernel Mode. Kernel Mode's code allows access to all system memory and all CPU instructions.

In User Mode, http.sys receives an aspx-based http request, and then it will check which Application Pool the Application based on the Request belongs to according to the Metabase in IIS. If the Application Pool does not exist, create it. Otherwise, the request is sent directly to the Queue corresponding to the Application Pool.

Each Application Pool corresponds to a Worker Process: w3wp.exe, which is undoubtedly running in User Mode. The Mapping of Application Pool and worker process is maintained in IIS Metabase. Based on such a mapping, WAS (Web Administrative service) passes the request that exists in an Application Pool Queue to the corresponding worker process (if not, create such a process). When the worker process is initialized, ASP.NET ISAPI is loaded, and ASP.NET ISAPI then loads the CLR. The final process is the same as IIS 5.x: Create an Application Domain for Application through the Create method of AppManagerAppDomainFactory; process the Request through ISAPIRuntime's ProcessRequest, and then enter the process into the ASP.NET Http Runtime Pipeline.