How IIS Handles ASP.

English Original: Beginner ' s guide:how IIS Process ASP.

Objective

Each time the server accepts a request, it is processed by IIS first. This is not an article describing the asp.ne life cycle, just about IIS operations. Before we begin, it will help to understand the full text and welcome feedback and suggestions.

What is Web Server?

Whenever we run an ASP. NET Web site through VS, the VS Integrated ASP. WebDev.WebServer.exe responds to a variety of requests, the name of which is called "a".

When we configure a Web program, there is always a word "Web Server", and its function is to respond to all requests.

What is IIS?

IIS (Internet Information Server) is a Microsoft Web server that is used to configure an ASP. IIS has its own ASP. NET processing engine to process requests, so when a request arrives, IIS receives and processes the request and then returns the content.

Request Handling Process

Now, you should be able to figure out the difference between Web server and IIS. Now let's take a look at the core section. Before you go on, you need to understand two concepts:

1, the work process (worker process)

2. Application pools (application pool)

Worker process: In IIS, the worker process (w3wp.exe) runs an ASP. NET application, manages and responds to all requests, and all of the functions of ASP. Run under the worker process, and when the request arrives, the worker processes generate request and response related information. In short, the work process is the heart of the ASP.

Application pools: Application pools are containers for worker processes and are typically used to separate worker processes from different configurations. Programs in other pools are not affected when a program error or process resource is reclaimed.

Note: When an application pool contains multiple worker processes, it is called "Web garden".

If we look at the structure of IIS 6.0, we'll find that it can be divided into two parts:

1. Kernel module (Kernel Mode)

2 module (user Mode)

The kernel mode is introduced from IIS 6.0, which contains a file called HTTP. sys, which, whenever requested, triggers the response of the file first.

HTTP. SYS file is responsible for passing requests to the appropriate application pool. But how does http. sys know which application pool should be passed to? Of course not randomly extracted, whenever an application pool is created, the ID of the pool is generated and registered in the HTTP. sys file, so the file can determine where the request will be sent.

The above is the first step in IIS processing requests. Next, let's look at how the request is passed in to the application pool from HTTP. sys.

In the user module of IIS, requests are received from HTTP. sys through Web Admin Services (was) and passed in to the appropriate application pool.

When the application pool receives the request, it is then passed to the worker process (w3wp.exe), which examines the requested URL suffix to determine which ISAPI extension to load. Asp. NET is loaded with its own ISAPI extension (Aspnet_isapi.dll) for mapping in IIS.

Note: If you install ASP. NET before you install IIS, you will need to register the ISAPI extension in ASP. NET by using the aspnet_regiis command.

Once the worker process loads the aspnet_isapi.dll, a httpruntime class is constructed that is the portal to the application and processes the request through the ProcessRequest method.

Once this method is called, an instance of HttpContext is generated. This instance can be obtained through httpcontent.current, and the instance will survive the entire life cycle, where we can get some common objects, such as Request,response,session.

HttpRuntime will then load a HttpApplication object through the HttpApplicationFactory class. Each request passes through a heap of HttpModule to reach HttpHandler to be responded to. And these HttpModule are configured in HttpApplication.

There is a concept called "HTTP Pipeline", which is called a pipeline because it contains a series of HttpModule that HttpModule intercept requests and direct them to the corresponding HttpHandler. We can also customize the HttpModule to do some special processing between request responses.

The HttpHandler is the endpoint of the HTTP pipeline. All requests pass through the HttpModule to arrive at the corresponding HttpHandler, and then HttpHandler generate and output the content according to the requested resource. As a result, we ask any ASPX page to get a response to the HTML content.

Conclusion

Whenever some information on the Web server is requested, the request first arrives at HTTP. Sys. HTTP. Sys then sends it to the appropriate application pool, the application pool is passed to the worker process, and the ISAPI extension is loaded, then the HttpRuntime object is created and the request is processed through HttpModule and HttpHandler.

Finally, ASP. NET page life cycle begins.

This is just an article that outlines the process of IIS processing, and if you want to learn more about the details, please click on the link below to learn more.

A low-level look at the ASP. Architecture

IIS Architecture

This article translated from: Beginner ' s guide:how IIS Process ASP.

Small bet after translation:

1, if IIS configured the site but do not see the "w3wp.exe" process, as long as the browser to open one of the station's pages, the "w3wp.exe" process will appear.

2, in order to save time, directly quoted the original, English poor, small check the dictionary should be no problem.

An overview of the HTTP request processing process

Think "Why do I enter www.tracefact.net in the address bar to see Zhang Ziyang's personal space?" "It's like thinking," Why is the apple falling to the ground or not going up the sky? ”。 For ordinary visitors, it is just as natural that the sun rises to the west in the east of the day, and for many programmers, it is only the responsibility of the system administrator or network Manager to think that this has nothing to do with it. After all, IIS is a component of Windows and not a part of ASP. In fact, the IIS and. Net framework have done a lot of behind-the-scenes work from the moment you flick the carriage return to the page rendered within one-tenth seconds of your eyes.

You may find it irrelevant to understand how these behind-the-scenes work works, and as programmers you just have to ensure that the programs you develop can run efficiently. However, in the development process, you find that you often need to use classes such as HttpContext. At this time, have you ever thought about the composition of these classes and how the entities of the class were created? You may simply answer: HttpContext represents a context for the current request. But you know how IIS, the framework, and ASP. How do you work together to process each HTTP request, how to differentiate between different requests, IIS, the framework, and how does the data flow between ASP.

To answer these questions, you first need to understand how IIS handles page requests, which is the basis for understanding the form validation pattern and the Windows validation pattern.

When the HTTP request just arrived at the server

When the server receives an HTTP request, IIS first needs to decide how to handle the request (note: The server handles an. htm page and an. aspx page must be different). What does IIS do with it? --According to the file's suffix name.

The server Gets the requested page (note: It can also be a file, such as Jimmy.jpg), the next step is to look for applications on the server that can handle such suffixes if IIS cannot find an application that can handle such a file, and the file is not protected by the server side (note: A protected example is APP_ The file in code, an unprotected example is your JS script), then IIS will return the file directly to the client.

Applications that can handle various suffix names are commonly referred to as ISAPI applications (note:internet server application programe Interface, Internet Server application interfaces). Although this ISAPI sounds very stylish, but also a "application", but carefully look at its full name to understand: it is actually just an interface, acting as a proxy, its main work is to map the requested page (file) and the prefix name corresponding to the actual handler.

Let's take a closer look at the ISAPI and see what it looks like, follow these steps:

1. Open IIS.
2. Select Random site, right mouse button, "Properties".
3. Select the Home Directory tab.
4. Select Configure.

You should see the following screen:

Figure 1. Application Configuration

It is clear that all IIS can handle, or that the file type that the ISAPI provides the proxy service, and its corresponding actual spooler, are clearly listed here.

We find the application handler for the. aspx and then click "Edit" and the following screen appears:

Figure 2. editing handlers for. aspx files

As you can see here, all the. aspx files are actually handled by the Aspnet_isapi.dll program, and IIS submits a request for the. aspx page to aspnet_ After Isapi.dll, it was no longer concerned about how the request was subsequently handled. Now we should know that ASP. NET is just one component of the server (IIS), which is an ISAPI extension.

Here are two points to note:

• When you modify limit to, you can restrict pages (files) to access only in a certain way
• "Confirming the existence of a file" is a key option for implementing URL mapping, which I'll talk about later.

Understanding the hosting environment (Hosting)

In essence, ASP. NET is mainly composed of a series of classes, the main purpose of which is to translate the HTTP request to the client's response. The HttpRuntime class is a primary entry for ASP. It has a method called ProcessRequest, which takes a HttpWorkerRequest class as a parameter. The HttpRuntime class contains almost all the information about a single HTTP request: The requested file, server-side variables, QueryString, Http header information, and so on. ASP. NET uses this information to load, run the correct file, and convert the request to the output stream, in general, the HTML page.

Note: Two like, can also be a picture.

When the content of the Web. config file changes or the. aspx file changes, in order to be able to unload applications running in the same process (note: Uninstallation is also for reloading), HTTP requests are placed in isolated application domains.

Note: You may have heard the application domain before, but you don't know what's going on, the application domain is the AppDomain.

For IIS, it relies on one called HTTP. SYS's built-in driver to listen for HTTP requests from outside. When the operating system starts, IIS first registers its own virtual path in HTTP. sys.

Note: This is actually the equivalent of telling HTTP. sys which URLs are accessible and inaccessible. A simple example: Why do you get 404 errors when you access files that don't exist? is determined in this step.

If the request is an accessible url,http. SYS will hand this request to the IIS worker process.

note:iis6.0 called w3wp.exe,iis5.0 in the name of aspnet_wp.exe.

Each worker process has an identity and a series of optional performance parameters.

Note: Optional performance parameters refer to settings such as the recycle mechanism, time-out settings, and so on.

The next thing to do is the ISAPI described in the previous section.

Note: This part of the content correlation is strong, in order to let everyone good understanding, I finally decided to put the ISAPI in front, maybe the full series will be adjusted when finished.

In addition to mapping files and their corresponding handlers, the ISAPI needs to do some other work:

1. Gets the current HTTQ request information from HTTP. SYS and saves the information to the HttpWorkerRequest class.
2. Load httpruntime in a mutually isolated application domain appdomain.
3. Call the ProcessRequest method of httpruntime.

Then the code that the programmer typically writes is done, and then IIS receives the returned data stream and returns it back to HTTP. SYS, and finally, HTTP. SYS then returns this data to the client browser.

OK, now you see Zhang Ziyang's Space homepage.

Figure 3. The hosting environment for ASP.

Understanding Pipelines (Pipeline)

In the previous two chapters, we discussed the things that IIS and the Framework did in the ephemeral one-tenth seconds of sending an HTTP request to seeing the browser output in a relatively low level. But we have overlooked one detail: How the code written by the programmer is cohesive in this process, and we'll look at this in this chapter.

When an HTTP request enters the ASP. NET runtime, its pipeline consists of a managed module (note:managed Modules) and a handler (Note:handlers), and the pipeline handles the HTTP request.

Figure 4. Understanding Http Pipelines

Let's take a look at how the data in this picture is flowing.

1. httpruntime the HTTP request to Httpapplication,httpapplication, which represents the Web application created by the programmer. HttpApplication creates HttpContext objects for this HTTP request, which contain many other objects about the request, mainly HttpRequest, HttpResponse, HttpSessionState, and so on. These objects can be accessed through the page class or the context class in the program. 、

2. The next HTTP request passes through a series of module, which has full control over the HTTP request. These module can do some things before doing some actual work.

3. After the HTTP request passes through all the module, it is HttpHandler processed. In this step, you perform some actual operations, usually the business logic that is done by the. aspx page. You may feel that you have not experienced this process in creating an. aspx page, but you must know that the. aspx page inherits from the page class, and we look at the signature of the page class:

public class Page:templatecontrol, ihttphandler{
Code omitted
}

As you can see, the page class implements the IHttpHandler interface, and HttpHandler is the lowest level of HTTP request processing.

After the 4.HttpHandler is processed, the HTTP request returns to module once again, when module can do something that has already been completed.

Note: Notice the words I marked in red, and then recall: Is there a large number of Inserting, Inserted, and other paired events in ASP. In fact, here is why ASP. NET can divide an insert operation into two parts, and then separate the behind-the-scenes principle of event interception.

If we focus only on HTTP requests, HttpHandler and HttpModule, and do not consider HttpContext and HttpApplication, then Figure 4 can be simplified as follows:

Figure 5. The flow direction of HTTP requests in HttpHandler and HttpModule

This link is from: http://blog.csdn.net/linux7985/article/details/44079993

How IIS Handles ASP.