Edit: Binzy a "Long Tune" Road from URL String to HTML Code Dino Espositowintelle July 10, 2003
Introduction
Regardless of which underlying platform, reliability and performance is the main requirements for all web applications, although in a sense, these two requirements are contradictory. For example, to build more reliable, more robust applications, you may need to separate the web server with specific applications, enabling applications to work outside the process. However, if you work in a memory environment different from the Web server process, the application will slow down. Therefore, it is necessary to take reasonable measures to ensure that processes are run as quickly as possible.
When building a Microsoft® ASP.NET runtime environment, the design principle based on the design is to fully consider reliability and performance. The resulting ASP.NET process model contains two system elements - a process in which the connector exists in the Web server process, an external auxiliary process. In addition, the scalable ability of the ASP.NET running structure is very strong, and any selected processor in multiprocessor hardware can be automatically used. This mode is called "Web Garden", which allows multiple auxiliary processes to run simultaneously, and each process is in a separate processor.
The height is summarized, and the ASP.NET is running three major properties:
The application and the ASP.NET assist process are completely separated. The service of the auxiliary process for providing services will never affect the life of the application. In other words, the auxiliary process can be terminated at any time when the application starts and in the run state.
Although the ASP.NET application is not running within the web server, most of the cases, its overall performance is still close to the performance of the application within the process.
A built-in and configurable support for the Web Garden architecture. As long as you simply check the settings in the configuration file, the auxiliary process can be cloned to use all CPUs closely related to the process. Therefore, in most cases, the scalability obtained in a computer with multiprocessor will grow linearly. (This content will be described in detail later.)
This article describes the component elements of the ASP.NET runtime environment, and then tells the "long and more zigrable" process from the URL request to the pure HTML text step by step.
Unless otherwise stated, the following description refers to the default process model of ASP.NET, which is the only model in Microsoft® Internet Information Services (IIS 5.x 5.x.
Asp.net structure
Execute the ASP.NET application requires support for host web servers. In the SERVER platform of the Microsoft® Windows®, the web server is represented by IIS executable named INetInfo.exe. The operating system of Windows 2000 and the above version provides a web server. However, it is important to note that in Microsoft® Windows ServerTM 2003, IIS and ASP.NET are not installed by default, you must add it to your system by clicking the Add or Remove Programs in Control Panel.
IIS is an unmanaged executable that provides an extensible model based on ISAPI extension module and filter module. By writing such a module, developers can directly manage requests for specific resource types and receive current requests in each predefined step. Extensions and filters are some DLLs that can export some functions with known known names and signatures. These plug-in components are registered and configured in the IIS configuration database.
Only there are several resource types requested by the client by IIS direct processing. For example, an incoming request for an HTML page, a text file, a JPEG, and GIF images is processed by IIS. Request for the Active Server Page (* .asp) file is parsed by calling an ASP-specific extension module named asp.dll. Similarly, requests for ASP.NET resources (eg, *. Aspx, *. Asmx, *. ASHX) are passed to ASP.NET ISAPI extensions. The system component is a Win32 DLL called ASPNET_ISAPI.DLL. ASP.NET extensions can handle multiple resource types, including Web services and HTTP handler calls. ASP.NET ISAPI extension is a Win32 DLL, not integrated hosting code. It is a control center that receives and dispatches a request for various ASP.NET resources. According to the design, the module exists in the IIS process, running under the System account with administrator privileges. Developers and system administrators cannot modify this account. The ASP.NET ISAPI extension is responsible for calling the ASP.NET_wp.exe, and the process is responsible for controlling the execution of the request. In addition to the request for the request, ASP.NET ISAPI also monitors the operation of the auxiliary process and cancels the process when performance is reduced to a certain extent.
The auxiliary process is a small Win32 shell code, integrated public language runtime (CLR) and runs managed code. It is responsible for processing requests for ASPX, ASMX, and ASHX resources. In general, this process has only one instance in a given computer. All currently activated ASP.NET applications run in it, each of which is located in a separate appdomain. However, as mentioned earlier, the auxiliary process supports the Web Garden mode, that is, the same copy of the process runs in a CPU closely related to the process. (For more details, see the "Web Garden Model" section later in this article.)
Communication between the ISAPI and the auxiliary process is to use a group of named pipes. Named pipe is a Win32 mechanism for transmitting data across an process. As the name suggests, the working mode of the named pipe is similar to the pipeline: on one end input data, output the same data at the other end. The established pipe can connect to both local processes or a process running on a remote computer. For local processes, the pipeline is the most effective and flexible tool in Windows.
To ensure optimal performance, ASPNET_ISAPI uses asynchronous named pipes to forward the request to the auxiliary process and get a response. On the other hand, the auxiliary process uses a synchronous pipe when the information (ie, the server variable) is required for the IIS environment. The ASPNET_ISAPI module creates a fixed number of named pipes and uses overlapping operations to process the same time through small thread pools. When the data exchange operation performed by the pipeline, the completion routine will disconnect the client and reuse the pipeline instance is a new client service. Thread pools and overlapping operations ensure that the performance of ASP.NET ISAPI has achieved satisfactory level. However, the ASPNET_ISAPI extension will never process HTTP requests.
The processing logic requested by the ASP.NET request can be summarized below.
1. When the request arrives, IIS checks the resource type and calls the ASP.NET ISAPI extension. If the default process model is enabled, the ASPNET_ISAPI will queue the request and assign the request to the auxiliary process. All request data is sent through asynchronous I / O. If the IIS 6 process model is enabled, the request will automatically queue in the auxiliary process (W3WP.exe), which is used to process the IIS application pool to which the application belongs. IIS 6 auxiliary process does not understand any situation of ASP.NET and hosting code, it is just processing * .aspx extensions and loads the ASPNET_ISAPI module. When ASP.NET ISAPI is running in the IIS 6 process model, its work mode is different, and the CLR is loaded only in the context of the w3wp.exe assist process. 2. After receiving the request, the ASP.NET assist process will notify ASP.NET ISAPI, which will serve the request. Notification is implemented by synchronization I / O. The reason why the synchronization model is used because the request is only marked as "executing" in the ISAPI internal request table, and the auxiliary process can start processing it. If the request has been processed by a special auxiliary process, it cannot be assigned to other processes unless the original process has been canceled.
3. Execute the request in the context of the auxiliary process. Sometimes, the auxiliary process may need to call to ISAPI to complete the request, that is, the need to enumerate server variables. In this case, the auxiliary process will use a synchronous pipe because it can maintain the order of requesting processing logic.
4. After the completion, the response is sent to an ASPNET_ISAPI that opens the asynchronous pipe. Now, the requested status becomes "DONE", which will then be deleted from the request table. If the auxiliary process crashes, all requests that are being processed will remain "executing" status and lasts for a while. If the ASPNET_ISAPI detects that the secondary process has been canceled, it will automatically terminate the request and release all relevant IIS resources.
The above explanation refers to the default ASP.NET process model, that is, the working model running in IIS 5.x. The default work mode provided by IIS 6 (provided) has an impact on the ASP.NET process model. When integrated in IIS 6.0, ASP.NET 1.1 will automatically adjust its own mode of operation to accommodate host environments. At this time, it is no longer necessary to use the ASPNET_WP assist process, and some configuration parameters defined in the Machine.config file are also ignored. From an ASP.NET point of view, the maximum change in IIS 6 is under the control of the request, and all in the context of the W3WP.exe assist process. The auxiliary process account is an account set for the application pool to which the web application belongs. By default, the account is NetworkService-, which is a built-in weak account with an ASPNET equivalent.
The auxiliary process is controlled by a function called process recycling (RecyCling). The process recycles an ASPNET_ISAPI feature that can automatically start a new process when the memory consumes too much memory consumption. When this happens, the new request will be processed by new instances, new instances to become new activities. However, all requests that specify to the old process remain suspended. This process is terminated if the old process ends the pending request and enter the idle state. If the auxiliary process crashes, or because other reasons will stop processing requests, all pending requests will be reset to the new process.
Although the ASP.NET ISAPI and the auxiliary process are the main components of the ASP.NET runtime structure, there are other executables that also play. The following table lists all of these components.
Table 1: Replenishing file name constituting the ASP.NET runtime environment
Types of
account
ASPNET_ISAPI.DLL
Win32 DLL (ISAPI extension)
Local system
ASPNET_WP.EXE
Win32 EXE
ASPNET
ASPNET_FILTER.DLL
Win32 DLL (ISAPI Filter)
Local system
ASPNET_STATE.EXE
Win32 NT Service
ASPNET
The ASPNET_FILTER.DLL component is a small Win32 ISAPI filter that is used to back up the cookie session state of the ASP.NET application. In Windows Server 2003, when an IIS 6 process model is enabled, ASPNET_FILTER.DLL will also filter out requests for non-executable resources in the bin directory.
ASPNET_STATE.EXE's role is more important to web applications because it is used to manage session state. This service is optional and can be used to save session status data outside the web application memory space. The executable is a NT service that can be run in locally or remotely. When the service is activated, the ASP.NET application can be configured to save all session information in the memory of this process. A similar solution is to provide a more reliable data storage method, not affected by process recycling and ASP.NET application failure. This service is running under the ASPNET local account, but you can use the Service Control Manager interface to configure it.
Another executable that should be introduced is ASPNET_REGIS.EXE, although it is strict, it does not belong to the ASP.NET runtime structure. This utility can be used to configure the environment to perform different versions of ASP.NET on a computer, and can also be used to repair IIS and ASP.NET damage. The utility is moderately the update of the script map stored in the root directory of the IIS configuration database. Script mapping is a relationship between resource types and ASP.NET modules. Finally, you can also use the tool to display the status of the installed ASP.NET version, perform additional configuration operations, such as grant NTFS permissions to a specific folder, create a customer script directory.
Web Garden model
The Web Garden model can be configured through the part in the machine.config file. Note that the part is the only configuration section that cannot be placed in the application-specific web.config file. That is to say, Web Garden mode can be applied to all applications running in your computer. But by using the nodes in the Machine.config source file, you can adjust the settings of your computer for each application.
Some two properties can affect the Web Garden model, which is WebGarden and CPumask. The WebGarden property accepts the Boolean value indicating whether multiple auxiliary processes are used (a related CPU corresponding to a process). By default, the value of this property is false. The CPUMASK property saves a DWORD value that is represented by the CPU that can run the ASP.NET assist process provides bit shielding. Its default is -1 (0xfffffff), indicating that all available CPUs can be used. If the WebGarden property is false, the content of the CPUMASK property will be ignored. The CPUMASK property also sets the upper limit for the number of copies that are running ASPNET_WP.EXE.
Tongyu said "The flash is not all gold", it is very suitable here. Web Garden mode allows multiple auxiliary processes to run at the same time. However, it is important to note that all processes will have their own application status, process, ASP.NET cache, static data, and other content required to run applications. After enabling the Web Garden mode, ASP.NET ISAPI will start the auxiliary process as much as possible according to the number of CPUs, each accession process is complete clone (closely related to the corresponding CPU). To balance the workload, the incoming request is divided between the running process in a single cycle. The auxiliary process is as reclaimed as in a single processor. Note that ASP.NET inherits all CPU usage restrictions in the operating system, and does not include custom semantics that implement restrictions. In short, the Web Garden model does not apply to all applications. The more status of the application, the more performance loss. Work data is stored in a block of shared memory so that the change in a process input can be found immediately by other processes. However, when processing the request, the work data is copied to the context of the process. Therefore, each auxiliary process will handle its own work data, the more the application is status, the greater performance loss. In view of this, careful, sensible application benchmark is absolutely necessary.
Only after IIS is restarted, the changes made in the configuration file will take effect. In IIS 6, the parameters of the web Garden mode are saved in the IIS configuration database, and WebGarden and CPUMASK properties are ignored.
HTTP pipeline
After the ASP.NET ISAPI extension starts the auxiliary process, it passes the partial command line parameters. The auxiliary process uses these parameters to perform tasks that need to be executed before the CLR is loaded. The values transmitted include: the authentication level required for COM and DCOM security, the number of named pipes and IIS process identifiers can be used. The name of the named pipe is randomly generated using the IIS process identification and the allowed pipeline number. The auxiliary process does not receive the name of the available pipe, but can receive the information required to identify the pipeline name.
What is the relationship between COM and DCOM security and Microsoft® .NET Framework? In fact, the CLR is provided as a COM object. More specifically, the CLR itself is not composed of COM code, but the interface to the CLR is a COM object. Therefore, the auxiliary process loads the CLR in the same way as the loaded COM object.
When the ASPX request encounters IIS, the web server will assign a token according to the selected authentication model (anonymity, windows, baq, or digest). When the auxiliary process receives the request to be processed, the token is passed to the auxiliary process. The request is obtained from the thread in the auxiliary process. The thread inherits the IIS thread that is originally incoming request. In ASPNET_WP.EXE, the actual account responsible for handling the request depends on how to configure simulation in a special ASP.NET application. If analog is disabled (default setting), the thread will run under an access to the auxiliary process. By default, this account is ASPNET in the ASP.NET process model, which is NetWorkService in the IIS 6 process model. These two accounts are "weak" accounts, and the features provided are limited, and they can effectively resist repurchase attacks (Revert-To-Self Attack). (Reply Attack refers to the security token of the simulated client to reply to the Parent Process Token. Assign a weak account to the auxiliary process to defeat such attacks.)
The highly summary, an ASP.NET assist process completed a major task is to give the request to a series of managed objects called HTTP pipes. To activate an HTTP pipe, you can create a new instance of an HTTPRuntime class and then call its ProcessRequest method. As mentioned earlier, only one auxiliary process is always run (unless the Web Garden model is enabled), which manages all web applications in standalone AppDomain. Each appdomain has its own HTTPRuntime class instance, that is, the input point in the pipe. The HTTPRuntime object initializes a range of internal objects that help implement the request. Helper objects include Cache Manager (Cache Object) and internal file system monitor (for detecting changes to the source file of the application). HTTPRuntime is created for requesting the context and fills the context with the HTTP information associated with the request. The context is represented by an instance of the HTTPContext class. Another Helper object created at the beginning of the HTTP runtime is a text writer, which is used to include the browser's response text. Text writing is an instance of the HTTPWriter class. This object caches the page code in programming. After the HTTP is initialized, it will find the application object that implements the request. Applications are an instance of the HTTPApplication class, which is the class behind the global.asax file. Global.asax is optional when programming, but it is necessary when building structures. Therefore, if you do not build classes in your application, you must use the default object. ASP.NET runtime includes several intermediate factory classes that can be used to find and return a valid Handler object to process requests. The first factory class used throughout the process is httpapplicationfactory. Its main task is to use the URL information to find the match relationship between the URL virtual directory and the collection of HTTPApplication objects.
The behavior of application factory classes can be summarized as follows:
1. Factory class maintains the HTTPApplication object pool and uses them to process applications. The life of the pool is the same as the life of the app.
2. When the first request of the application arrives, the factory class extracts information about the application type (GLOBAL.ASAX class), sets the file used to monitor changes, create an application status, and trigger the Application_onstart event.
3. Factory class gets an HTTPApplication instance from the pool and puts the request to be processed into the instance. If there is no available object, create a new HTTPApplication object. To create an HttPApplication object, you need to complete the compilation of the Global.asax application file first.
4. HTTPApplication starts processing the request and can only process new requests after completing this request. If a new request from the same resource is received, other objects in the pool are processed.
5. The application object allows all registered HTTP modules to prepare the request and identify the type of handler that best suits the process. This is done by looking for the expansion of the requesting URL and the information in the configuration file.
The HTTP handler is a class that implements the IHTTPHANDLER interface. .NET Framework provides some predefined handles for common resource types, including ASPX pages and web services. The part in the machine.config file defines the class name that the HTTPApplication object must instantiate to process the request for a particular type of resource. If the Helper class is a handler factory, the GetHandler method will determine the type of handler to use. At this time, the appropriate type of handler will be obtained from a set of objects and configure it to handle the request. The IHTTPHandler interface provides two ways: Isreusable and ProcessRequest. The former will return a boolean value indicating whether the handler can be collected. (Most predefined handles are gathered, but you can define your own handlers each time you need a new instance.) The ProcessRequest method contains all the logic required to handle specific types of resources. For example, the processor of the ASPX page is based on the following pseudo code:
Private void processRequest () {// Determines whether the request is a return () isPostback = DeterminePostBackMode (); / / triggered the Page_init event for the ASPX source code pageinit (// Load ViewState, processing the sent value. IF (ispostback) {loadPageViewState (); processpostdata ();} // triggered the page_load event of the ASPX source code PageLoad (); // 1) Process the sent value (when // dynamically created the control) // 2) Holling the server-side events of the attribute change to the input drive // control (ie the status change of the check box) // 3) Perform all code IF (ispostback) {processpostDataSecondTry (); raiseChangeDevents (); RaisePostBackEvent ();} // Page_PreRender trigger event ASPX source code PreRender (); // save the current state of the control to the ViewState SavePageViewState (); // page content will be presented to the HTMLRenderControl (CreateHtmlTextWriter (Response.Output)); }
Regardless of the type of resource called, the model based on the HTTP handler is the same. The only element varies with resource types is a handler. The HTTPApplication object is responsible for looking for which handler should use to process the request. The HTTPApplication object is also responsible for detecting changes made to dynamically created, an assembly indicating the resource (such as a .aspx page or .asmx web service). If you detected changes, the application object will ensure the latest source of the requested resource compile and load.
Temporary file and page assembly
To fully understand the ASP.NET HTTP runtime, let's analyze the changes in the file system layer when requesting the ASP.NET page. Next, you will learn about a set of dynamic created temporary files managed and monitored by HTTP pipes.
Although the core code of the page can be isolated from the C # or Microsoft® Visual Basic® .NET class behind the code, you can write and deploy the web page and deploy as a .aspx text file. For pages to be displayed as a URL, .aspx files must always be available in the web space of the application. The actual content of the .aspx file will determine the assembly (or multiple assemblies) of the application object to be loaded.
Follow the design, the HttPApplication object will look up for classes named based on the requested ASPX file. If the page is named SAMPLE.ASPX, the corresponding class name to load is ASP.SAMPLE_ASPX. Applications Find such classes in all assembly folders of the web application, including the global assembly cache (GAC), BIN subfolders, and Temporary ASP.NET Files folders. If this class is not found, the HTTP structure analyzes the source code of the .aspx file, create a C # or Visual Basic .NET class (which type of creation, depending on the language set on the .aspx page), and compile it. . The name of the newly created assembly is randomly generated, located in an application-specific subfolder, the path is as follows: C: WindowsMicrosoft.Netframeworkv1.1.4322temporary ASP.NET FILES. Subfolders V1.1.4322 is specific to ASP.NET 1.1. If you are using the ASP.NET 1.0, the version number of the subfolder will be different, that is, the subfolder name is V1.0.3705. When you access the page again, the assembly already exists and does not need to be recreated. However, how does the HTTPApplication object determine if the page is specific? Does it scan a lot of folders each time? No, not this.
The application object only views the content of a special folder in the Temporary ASP.NET Files folder. The specific path (the application-specific path) is returned by the httpruntime.codegenndir property. If it is the first access .aspx file (ie, the page assembly has not been created), there is no XML file that starts with the ASPX page name in the folder. For example, the SAMPLE.ASPX page with dynamic assembly should have the following entry:
Sample.aspx.xxxxx.xml
The xxxxx placeholder is a hash code. By reading the content of the XML file, the application object can understand the name of the assembly to be loaded and the class you want to acquire. The following code snippet is a typical content of this helper file. The name of the assembly containing the Asp.sample_aspx class is MVXVX8XR.
Of course, the file is created only when the source code of the FileDep file is analyzed by generating a dynamic assembly. Any changes to the FileDep file will cause the assembly to be ineffective, and must recompile when requested. It should be noted that in future versions of the ASP.NET architecture, this implementation process may have a large change. No matter what reason, as long as you decide to use it in the current application, you must be very careful.
Since the update is updated to create a new assembly for the page, ASP.NET will verify that the old assembly can be deleted. If the old assembly contains only the class of the modified page, ASP.NET will try to delete and replace the assembly, otherwise a new assembly will be created in the case of retaining the old assembly.
During the deletion, ASP.NET may find that the assembly file has been loaded and locked. In this case, you can add a ".delete" extension to the old assembly to rename it. (Note that all Windows files can be renamed during use.) As long as the application is restarted (for example, due to changes to an application file such as Global.asax and Web.config), these temporary .delete files It will be deleted. But when processed the next request, these files are not deleted when the ASP.NET is running.
Note that by default, each ASP.NET application can recompile 15 pages before the entire application is restarted, while some sessions and application data will be lost. When the recent number of compilation exceeds the threshold set in the NumRecompilesBeForeApprestart property, AppDomain will be uninstalled, and the application will be restarted. Also note that in the .NET Framework, you cannot uninstall the single assembly. AppDomain is the smallest code block that can be uninstalled from the CLR. summary
ASP.NET applications have two major features: process model and page object model. ASP.NET uses some of IIS 6.0 in advance, and IIS 6.0 is a brand new, groundbreaking Microsoft Web information service provided in Windows Server 2003. It is particularly worth mentioning that ASP.NET applications run in a separate auxiliary process are the same as all applications in IIS 6. Moreover, although there is an abnormality, memory leaks or program errors, the ASP.NET runs automatically reclaims the auxiliary process to ensure excellent performance. This function has become the system function of IIS 6.0.
In this article, I summarize the basics of the default ASP.NET process model, and interactions between IIS Code (ASP.NET ISAPI Extensions) and the auxiliary process. At the same time, it also introduces the latest difference between the IIS 6 process model. This article is less discussed to the page object model, and I will further introduce in future articles. Welcome to continue reading!
To understand the ASP.NET, HTTP runtime and page object model, please review my new book in Microsoft Press 2003 Programming Microsoft ASP.NET.
About author
Dino Esposito is a training teacher and consultant from Rome, Italy. As a member of the Wintellect team, Dino specializes in ASP.NET and ADO.NET, mainly engaged in teaching and consulting in Europe and the United States. Dino also manages Wintelle's ADO.NET courseware, writing articles for MSDN Magazine's Cutting Edge column. To contact him, please send an email to dinoe@wintellect.com.
