Understanding the ASP.net architecture from the bottom

(translate) understand asp.net architecture from the bottom

Objective

As for the underlying working mechanism of ASP.net, the garden has recently been hotly debated. I'm sure a lot of people have seen a classic of Mr. Rick Strahl: A low-level looking at the asp.net architecture, with the consent of Mr. Rick Strahl, I translated his article into Chinese, I hope I can give a little help to a friend who wants to know more about ASP.net working mechanism.

Summary: Asp. NET is a powerful platform for building web programs, providing great flexibility and capability so that it can build any Web program. Many people are only familiar with the ASP.net high-level framework such as: WebForms and webservices, so in this article I will explain the basics of asp.net comparison, and will be explaining how to move requests from the Web The server is handed over to the ASP.net runtime and then processed by the ASP.net HTTP pipeline.

For me, understanding the internal working mechanism of a platform always makes me feel some satisfaction and comfort, like insight, can help me write a better program. Knowing what the tools are for and how they are assembled as part of a complex framework will make it easy for you to find solutions to problems and to be very important when you modify and debug errors. The purpose of this article is to understand asp.net from the bottom and to help you understand how the request flows into the ASP.net processing pipeline. At the same time, you will understand the core of the ASP.net engine and how a Web request ends here. Much of the knowledge here is something you don't need to know about in your daily work, but if you understand how ASP.net can route requests to the code of your application (usually at a higher level), this will be very useful to you.

Note: The entire ASP.net engine is completely built into managed code, and all extensibility is built through managed code.

Most of the asp.net are more familiar with WebForms and webservices. These high-level implementations make it very easy to build Web programs. Asp. NET is designed as a driving engine that provides the underlying interfaces to Web servers and provides routing services to the front-end and end of high-level web applications. WebForms and WebServices are based on the ASP.net framework, two of the most common ways to deal with HTTP.

In fact, at a lower level, ASP. NET also provides plenty of flexibility. The HTTP runtime and the request pipeline provide the same capability to build implementations similar to those of WebForms and webservices, which are, of course, already in use. NET managed code implemented. If you need to build a custom HTTP processing platform that is a bit lower than the WebForms level, you'll use all of these similar features.

Building most web interfaces, using WebForms is undoubtedly the easiest way to do it, but if you want to customize a content processor, or you need to do something special with the inflow and outflow, or you need to customize an application server interface for an application, Then use these low-level processes or modules to get better performance and gain more control over real request processing. Although those high-level implementations, such as WebForms and webservices, have provided similar functionality, they have added too much control to the request (resulting in degraded performance). So you can do it all at a lower level to handle these requests.

 

asp.net is what.

 

Let's start with the simplest definition, ASP. NET is what. I usually like to use the following statement to describe ASP.net.

Asp. NET is a mature engine platform that completely uses managed code to process Web requests. It's not just webforms and webservices.

Asp. NET is a request processing engine. It obtains the client request and then passes the request to a destination through its built-in pipeline, at which point the developer can add the logical code to process the request. In fact, this engine is completely separate from HTTP or Web server. In fact, the HTTP runtime is a component that you can host on an application other than IIS. Can even be combined with other services altogether. For example, you can host the HTTP runtime in a Windows desktop application (for details, see: http://www.west-wind.com/presentations/aspnetruntime/aspnetruntime.aspx).

By using the built-in pipeline routing requests, HTTP runtime provides a complex, but elegant, mechanism. Many objects are involved at every level of processing a request, but most objects can be extended by derivation or by an event interface. Therefore, this framework has a very high scalability. With this set of mechanisms, it is possible to enter lower-level interfaces such as caching, authentication, authorization, and so on. You can filter the content before or after processing the request, or simply route the client request that matches the specified signature directly into your code or to another URL. For the same thing, can be done through different processing methods, and the implementation of the code is very intuitive. In addition, the HTTP runtime provides the best flexibility between easy development and performance.

The entire ASP.net engine is completely built into managed code, and all extensibility features are provided through the extension of managed code. For powerful, functional. NET Framework, the use of your own things to build a mature, high-performance engine architecture has become a testament. Nevertheless, it is important that the ASP. NET is the most impressive is the visionary design, which makes the work on top of it very easy, and provides the ability to hook up almost any part of the request processing.

You can use ASP.net to accomplish tasks that were previously done using ISAPI extensions and filtering on IIS. Although there are some limitations, but compared with the ASP, has made great progress. ISAPI is the underlying WIN32-style API, its interface is 1 trillion, which is very difficult for large program development. Because the ISAPI is the underlying interface, it is also very fast. But for enterprise-level program development is quite difficult to manage. So, for a certain amount of time, ISAPI acts primarily as a bridge interface for other applications or platforms. But in any case, the ISAPI is not abandoned. In fact, the ASP.net and IIS interfaces on the Microsoft platform are communicated through the ISAPI extensions hosted in. NET and then directly to the ASP.net runtime. ISAPI provides the core interface for communicating with Web server, and then ASP.net uses unmanaged code to get requests and respond to client requests. ISAPI provides content that is similar to HttpRequest and httpresponse through a common object, exposing unmanaged data in a managed object through a well-designed, accessible interface.

From the browser to the ASP.net

 

Let's start with a typical asp.net of the life cycle of a Web request. By typing a URL in the browser, a user clicks a hyperlink, submits an HTML form (a POST request), or a client program invokes a ASP.net based WebService (service provided through ASP.net). On the server side, IIS5 or IIS6 will receive this request. Asp. NET is communicated with IIS through an ISAPI extension, and then, through ASP.net, this request is typically routed to a page with an. aspx extension. However, how this process works is entirely dependent on the execution of the HTTP processor (handler). This processor will be installed to handle the specified extension. In IIS,. aspx is mapped to the DLL file of the ASP.net ISAPI via Application extensions: Aspnet_isapi.dll. Each request that triggers a asp.net must be identified by a registered extension that points to aspnet_isapi.dll.

Note: ISAPI is the first and most high-performance IIS entry point in custom Web request processing.

Depending on the extension, ASP. NET routes a request to a proper processor, which is responsible for processing the request. For example, the webservices extension. asmx does not route a request to a page on disk, but rather to a class that has a specified attribute (WebMethodAttribute) appended to the definition, which identifies it as a Web services implementation. Many other processors will be installed along with the asp.net. Of course, you can also define your own processor. All HttpHandler in IIS are mapped and point to the asp.net ISAPI extension, and these HttpHandler are also configured in Web.config to route the request to the specified HTTP processor. Each processor is one. NET class, which is used to handle the specified extension. These processors can deal with Hello World, which is simple to a few lines of code, and can handle pages that are complex to resemble ASP.net and perform webservice. For now, just understand that extension is a basic mapping mechanism, ASP. NET uses it to get a request from the ISAPI and then route the request to the processor that specifies that the request is processed.

ISAPI Connection

 

ISAPI is the underlying unmanaged Win32 API. It defines an interface that is very simple and performs optimally. The original pointer (raw pointer) is processed with these interfaces, and the function pointer list (functions pointer tables) is used for callbacks. ISAPI provides the lowest-level, high-performance interface that developers and tool vendors can use to drill down into IIS. Because ISAPI is very low-level, it is not appropriate to use it to build application-level programs. ISAPI tends to be used as a bridge interface to provide a high-level tool with the ability to apply service types. For example, both ASP and ASP.net are built on ISAPI as cold fusion. Most Perl, PHP, and JSP executions, like many third-party solutions, can be run in IIS. ISAPI is a great tool that provides high performance vertical access interfaces for high-level applications. This allows the information that the high-level application needs to be distilled from the information provided by the ISAPI. In ASP and ASP.net, the engine can refine objects in the form provided by the ISAPI interface such as request and response, which can read their respective contents from the information in the ISAPI request.

As a convention, ISAPI supports ISAPI extensions (extensions) and ISAPI filtering (filters). An extension is a request-processing interface that provides logical processing related to Web server input and output. Essentially, it is a transactional interface. Both ASP and ASP.net are considered implementations of ISAPI extensions. An ISAPI is a hook interface that allows you to view every request that goes into IIS and can modify the contents of the request (including input and output) or alter the behavior of the module (e.g., authentication, etc.). By the way, ASP. NET is mapped to ISAPI through two aspects: an HTTP processor (corresponding to an ISAPI extension) and an HTTP module (corresponding to ISAPI filtering). The relevant content will be described in detail later.

An ISAPI is the initial point of the code that identifies asp.net the start of a request. Asp. NET maps different ISAPI extensions to it, and the ISAPI extension is located in the. NET Framework directory:

<.net Frameworkdir>/aspnet_isapi.dll

You can see these mappings in IIS Service Manager, as shown in Figure 1. Open the properties of the Web site's root directory, select the Home Directory tab, and then view the configuration | Application mappings.

Figure 1:iis Maps different extensions, such as. aspx, to the ISAPI extension of ASP.net. With this mechanism, in the Web server, requests can be routed to the ASP.net processing pipeline.

Although. NET requires a lot of extensions, but you don't have to set them manually, you can use the Aspnet_regiis.exe utility to make sure all the script mappings are registered.

cd;. Netframeworkdirectory> Aspnet_regiis–i

This will asp.net individual versions of the runtime, through script mappings, to the entire Web site, and the client script library, which will be used by the controls on the browser. Note that it is the version of the CLR that is registered to be installed in the above directory. Aspnet_regiis has an optional option that allows you to configure a single virtual directory. Every one. NET Framework versions, all have their own aspnet_regiis, for different versions of the. NET Framework, you need to run the appropriate version of the aspnet_regiis, register to the entire site or virtual directory. Starting with asp.net2.0, in the IIS console, there is an IIS ASP. NET Configuration page, which you can select on this page. NET version of.

IIS5 the difference between the IIS6 and the

 

When a request comes in, IIS examines the script map and then routes the request to aspnet_isapi.dll. What is the operation of this DLL file next? In IIS5 and IIS6, how does this request get to the ASP.net runtime? There has been no significant change in the way they are handled. Figure 2 shows an approximate process.

Figure 2: Stand at a higher angle, watch the process of requesting the runtime from IIS to ASP.net, and then go directly to the request processing pipeline. IIS5 and IIS6 have different ways of interfacing with ASP.net, but the whole process is exactly the same after the request arrives at the ASP.net pipe.

IIS5 directly put Aspnet_isapi.dll in the Inetinfo.exe process, or one of them will be isolated from the worker process, and if you have quarantine permissions, you can set the level of isolation for both the Web site and the virtual directory to medium or advanced. When the first ASP.net request comes in, the DLL assigns a new process to another exe-aspnet_wp.exe, and then routes the relevant information to the newly allocated process. The new process is then loaded and hosted sequentially. NET Runtime. Each request entered into the ISAPI DLL will be given to the worker process by invoking the named pipe path.

Note: Unlike the previous Web server, the IIS6 has been optimized for asp.net. Application pools are used in IIS6.

Notably, IIS6 changed the processing model, and IIS no longer directly hosted any external executable code like ISAPI extensions. Instead, IIS always maintains a separate worker process: the application pool. All processing occurs in this process, including the execution of the ISAPI DLL. For IIS6, application pooling is a significant improvement because they allow for a smaller granularity of control over the execution of a specified process. You can configure the application pool for each virtual directory or the entire Web site, which makes it easy to isolate each application into its own process so that it can be completely isolated from other programs running on the same machine. From the Web processing point of view, if a process dies, at least it does not affect other processes.

In addition, the application pool is highly configurable. By setting application pool execution permissions, you can configure their execution security environment. These configurations can be customized to the same granularity for the specified application. For ASP.net, IIS6 's biggest improvement was the use of application pools to replace most of the processmodel entities in Machine.config. In IIS5, this entity is difficult to manage because its settings are global and cannot be overridden in the web.config of the specified Web program. When IIS6 is running, most of the configuration in processmodel will be ignored and replaced by reading the application pool configuration. Note that I'm talking about most of the other configurations, such as the size of the thread pool and the number of IO threads that still need to be configured through this node, because there is no configuration for similar functionality in the server's application pool.

Because application pools are performed externally, these can be easily monitored and managed. IIS6 also provides a number of performance counters that can be tracked for restart and timeout options. In many cases, this can help the application correct the problem. Finally, the implementation of the IIS6 application pool does not rely on COM +, just as the IIS5 isolation process does, which improves the performance and stability of the program, especially those that need to use the COM object internally.

The IIS6 application pool also contains something inherent to the asp.net, asp.net can communicate with the new underlying APIs that allow direct access to the HTTP buffer memory APIs, while the HTTP buffer memory APIs can go directly to the Web server's buffer memory. Uninstall the asp.net level cache.

In IIS6, the ISAPI extension runs in the process of the application pool. The NET runtime also runs in this process, so the communication between the ISAPI extension and the. NET runtime occurs within the process. This allows for higher performance than the IIS5 that must use the named pipe interface. Although the host model for IIS is different, the interfaces that actually enter managed code are similar, and there are only some changes in obtaining the routed request.

entered. NET run time

 

Enter. NET runtime's true login point occurs between classes and interfaces that do not have formal documentation. In the world outside of Microsoft, these interfaces are little known. Microsoft's folks aren't too keen to discuss these details, probably because they think they don't have much impact on developers who use ASP.net builders.

Worker processes aspnet_wp.exe (IIS5) and W3wp.exe (IIS6) hosts are in the. NET Runtime. An ISAPI DLL invokes an interface of a handful of unmanaged types through the underlying COM, in fact, the end invocation is an instance of the Isapiruntime derived class. The first login point to enter the runtime is the Isapiruntime class, which exposes the interface iisapiruntime to the caller via COM. These COM

Interfaces are the underlying IUnknown that, based on these interfaces, means that calls between the ISAPI extension and the asp.net belong to an internal call. Figure 3 is the signature of the Iisapiruntime interface that is seen using the well-known reflection tool Refector (http://www.aisto.com/roeder/dotnet/). Refector is a tool that allows you to view and decompile assemblies, and it makes it easy to view metadata and Decompile code, as you can see in Figure 3. It's a great way to use it to explore the process step-by-step.

Figure 3: If you want to delve deeper into the underlying interface, you can open the Refector tool and point to the System.Web.Hosting namespace. The login point into the asp.net appears as a managed COM interface that will be invoked in the ISAPI DLL. The login point receives a pointer to an unmanaged type of the ISAPI ECB. The ECB has access to the entire ISAPI interface, and it can obtain the requested data and send the returned data back to IIS.

The Iisapiruntime interface serves as a bridge between unmanaged code and managed code from the ISAPI extension (which is directly communicated in IIS6 and indirectly through named pipes in IIS5). If you pay attention to this class, you will find the signature of the ProcessRequest method as follows:

[Return:marshalas (UNMANAGEDTYPE.I4)]

int ProcessRequest ([in] the IntPtr ECB, [in, MarshalAs (UNMANAGEDTYPE.I4)] int useprocessmodel);

The

ECB parameter is the ISAPI extension control block, which is passed as an unmanaged resource to the ProcessRequest method. \ extension This method takes the ECB and uses it as a basic input and output interface for the request and response objects. The ISAPI ECB contains all the underlying request information, including server variables, the input stream for form variables, and the output stream used to write data and send the data to the client. A single ECB reference basically provides all the features that an ISAPI request can access