IIS Architecture Basics, or Query Provisioning for ASP.NET

  • Tutorial



Last year, I had to interview about 10-15 candidates for the post of a web programmer for ASP.NET secondary qualifications. As questions “to backfill”, or “with an asterisk”, I asked to tell what happens with the HTTP request from the moment it arrives at the 80th port of the server to the transfer of control to the aspx page code. The statistics were depressing: none of the candidates could give out at least something intelligible. And this has its own explanation: neither in MSDN with technet, nor on the specialized resource iis.net, nor in the a-la books “ASP.NET for professionals”, nor in blogs, this topic is given due attention - information has to be collected almost bit by bit. I even know people who decided to write their own web server (Igor, George, hi!) So as not to understand the work of IIS. The only sensible article is “Introduction to IIS Architectures »Reagan Templin. But she also remains on the periphery of the interests of the asnets.

Although I’m personally not so interested in purely technical issues, I decided to put together my accumulated experience, dig out interesting details on the Web and pass on this sacred knowledge to the masses before it became obsolete. I must say right away that the article is more focused on IIS 7.x, sometimes there will be branches about 6-ku. I did not come across the 8th version in the work, so I decided to get around it in this article. But, I am sure that the reader can easily figure out the eight, having mastered the material presented below.

1. General plan
2. Close-up
2.1. HTTP.SYS
2.2. World Wide Web Publishing Service (W3SVC)
2.3. Windows Process Activation Service (WAS)
2.4. Application Pool
2.5. Application domain, application
3. What next?
Sources

1. General plan


So, let's start from the end, and then consider individual aspects a little more closely.
In English literature, the request processing pipeline in IIS is called the "request processing pipeline" - something like a "request processing pipeline". In general, it is presented in the figure below for an http request.


Fig. 1. HTTP request processing pipeline (IIS 7.x).

Thus, the http request passes through the "assembly line of the pipeline" through the following:

1. The browser accesses the web server at a specific URL, on the server side the request intercepts the HTTP.SYS driver .
2. HTTP.SYS is knocking on WAS to retrieve information from the configuration repository.
3. WAS servicerequests configuration from storage - from a file in the IIS folder (applicationHost.config).
4. Since this request was received via HTTP, the configuration information is received by the W3SVC service (also known as the WWW Service in the picture), this information contains data about the application pool and other site parameters.
5. The W3SVC service uses this information to configure HTTP.SYS .
6. Service WAS starts a process W3WP.exe for the application pool if it has not yet been launched.
7. In the process of W3WP.exethe website application is running, which, in fact, generates and returns a response to the HTTP.SYS driver .
8. HTTP.SYS sends a response to the browser.

In principle, this scheme is already enough to go through interviews in most companies and get a general idea of ​​IIS architecture. But if you didn’t come here for a tick, then please follow along.

2. Close-up


Now let us dwell in more detail on each of the mentioned components.

2.1. HTTP.SYS

At the transport level, IIS uses protocol listeners, which are located on top of the TCP / IP stack. The most interesting component for us is the system driver HTTP.sys, which is built into the kernel of the OS and works with the HTTP and HTTPS protocols, registering independently to listen on all the ports that will receive requests to sites in IIS.

The HTTP.sys built-in kernel became an innovation in IIS 6, replacing the Windows Socket API, a component for intercepting HTTP and HTTPS requests at the user level in IIS earlier versions. Probably, the integration of the driver into the kernel is the very reason why the IIS version is tightly bound to the Windows version.

The driver accepts all incoming requests and redirects them to the desired application pool. If for some reason the workflow in which the required pool is hosted is stopped (failure, idle timeout, configuration change, etc.) or is still starting, then HTTP.sys saves incoming requests in a queue specially allocated for each pool. Thus, user requests do not disappear anywhere, and they do not notice any interruptions in the work of sites running IIS.

Even HTTP.sys can cache responses (in more detail, Instances in which HTTP.sys does not cache content ), so some requests are processed without being passed to the application level, and it also parses the request URI and validates it in accordance with RFC 2396 (some - what can be learned from here -Use of special characters like '%' '.' and ':' in an IIS URL ) and request / response logging.

Some HTTP.sys settings are made in the Windows registry (in more detail, the Http.sys registry settings for Windows ). By the way, in the same place - in the registry - you can peek at the usual place of registration of our citizen:% SystemRoot% \ system32 \ drivers \ http.sys.
Frankly, in the process of writing this article, I discovered some details for myself. For example, caching responses at the level of the HTTP.sys driver. This helped me explain one case of a strange, as it seemed to me then, phenomenon in the behavior of IIS. Marketers posted a swf card on the site before the next holiday, but then they didn’t like something in the file name and they renamed it. However, the site continued to issue a postcard at the old URL, and even clearing the browser cache did not help. I already connected here, but neither restarting the website and the entire application pool, nor accessing the site bypassing the corporate proxy server gave the expected result. But now we know who is to blame.


2.2. World Wide Web Publishing Service (W3SVC)

This service (abbreviated as WWW service specification) was introduced in IIS 6 as a separate component for working with HTTP / HTTPS protocols and for managing application workflows and performed the following functions:
  • HTTP.sys driver administration.
  • Workflow management.
  • Monitoring website performance metrics.

This service operates in Windows Server 2003 in the context of the Svchost.exe process (settings can be viewed in the HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ W3Svc registry ), unlike all other IIS services that are executed in the context of the Inetinfo.exe process, it is implemented in Iisw3adm .dll.

In IIS 7.x, the process control function was moved to a separate service - WAS (see clause 2.3) in order to universalize the architecture. Now the WWW service has become in essence one of the adapters specializing in HTTP / HTTPS protocols - working on top of the HTTP.sys driver. However, the WWW service remains the cornerstone component of IIS, so its configuration is different from the configuration of adapters to other protocols (a bit more similar here); it functions in the same workflow as WAS, and is implemented in the same library (Fig. 2).


Fig. 2. Workflow with W3SVC and WAS.

Since we are talking about adapters for protocol listeners (protocol listener adpater), let's just linger a bit and see what they are. In principle, IIS 7.x can be configured to process requests using any protocols other than standard HTTP and FTP, for example, POP3, SMTP, Gopher. You are even free to come up with your own protocol for your web or WCF service and implement all the necessary components for it, if you are not sorry for your time. Most likely, adapters and listeners for the most common protocols are available for free and commercial download - I have not tested this. But first of all, you should pay attention to the standard services (Fig. 3), which are supplied with the .NET Framework and integrated with IIS:
  • NetTcpActivator for TCP;
  • NetPipeActivator for Named Pipes;
  • NetMsmqActivator for Message Queuing (aka MSMQ).



Fig. 3. A list of standard non-HTTP adapters in the Windows Services snap-in.

But still, the most important adapter for us is the WWW service, incl. Let us dwell a little more on the two remaining functions from IIS 6.

Administration and configuration of HTTP (S). At the time of updating the configuration of websites, the WAS service transfers this information to the WWW service, and it, in turn, configures HTTP.sys to listen on specific ports, parse the IP and header of the requested site and, possibly, other driver parameters. In the opposite direction, W3SVC refers to WAS when a new one arrives in the request queue in HTTP.sys, to obtain a workflow that processes this request.

Track performance metrics.The WWW service maintains performance counters using the HTTP.sys driver for this purpose and provides their metrics to websites and the IIS cache. I could not find more detailed information on this issue.

2.3. Windows Process Activation Service (WAS)

So, the WWW service in IIS 7.x, like in IIS 6, continues to perform the tasks of administering HTTP.sys and managing website performance metrics. But the task of managing workflows has been moved to a separate service - WAS. It is launched by the system in a single copy, reads the configuration from the % SystemRoot% \ System32 \ inetsrv \ Config \ ApplicationHost.config file and configures protocol listeners through the corresponding adapters in accordance with the information specified in it. Recall that for the HTTP / HTTPS protocols, the adapter is the W3SVC service, and the listener is the HTTP.sys driver. When a listener intercepts a request, through its adapter, it calls the WAS service to obtain the application workflow, to which the request will be transmitted for processing and generating a response to the client.

When you activate the application necessary for processing a user request, the following components are involved:
  • Listener adapters are special Windows services that work with a specific protocol and interact with WAS to direct requests to the correct workflow.
  • Actually WAS. She is responsible for creating work processes and managing their lifetime.
  • The w3wp.exe executable file is a workflow template.
  • The application manager manages the creation and utilization of application domains that are hosted within the workflow.
  • Protocol handlers are protocol-dependent components within a workflow that are responsible for exchanging data between a particular adapter and the workflow. There are 2 types of protocol handlers: the process (process protocol handler - PPH) and the application domain (AppDomain protocol handlers - ADPH).

The figure below shows an example of a component diagram inside an application workflow instance. When the WAS service starts the workflow, it loads the required process protocol handlers (PPH) into it according to the application configuration and through the application manager creates the application domain inside the workflow where the application will be hosted. The application manager downloads the application code into the application domain and the required application level protocol handlers (ADPH) to process messages using the appropriate network protocols.


Fig. 4. Components w3wp.exe for interacting with external components.

As noted above, the .NET Framework carries an implementation of components for the HTTP / HTTPS protocols (our favorite ASP.NET), net.tcp, net.pipe, and MSMQ. The HTTP / HTTPS and FTP protocol stacks are nevertheless more closely integrated into IIS and the OS, so the settings for the new protocol are best demonstrated using less popular Donnet protocols. So, after installing the framework, the following entries appear in the IIS ApplicationHost.config configuration file:

And the corresponding PPH and ADPH components are configured in the donnet machine.config:

In the configuration file of the web server ApplicationHost.config, together with the application settings, bindings are stored that determine the parameters of incoming requests that will be sent to this application. Such parameters are the name of the network protocol, server IP address, domain name and site port. These parameters must be unique among running applications to uniquely identify the target application. WAS monitors this restriction and will not allow you to start a site for which this condition is not met, or will offer to stop a site with the same link.

Please note that in standard IIS operation mode, the WAS service, the adapter service for each protocol listener (including W3SVC), and the drivers / listeners of each protocol (including HTTP.sys) themselves are running in the OS in a single copy. But individual requests can be sent to different applications in different workflows. On the other hand, requests for different protocols can be sent to a particular application through the corresponding adapters. Apparently, for the correct implementation of such behavior, the architectural connection of the protocol driver - the protocol driver adapter - activation service (a kind of regulator, more precisely, the router) - a workflow was invented.

2.4. Application pool

When configuring a web application, in addition to binding to request parameters and other settings, it indicates membership in the application pool. The application pool was an innovation in IIS 6 and was designed to isolate web applications from each other and thereby increase the stability of the web server as a whole. The bottom line is that the application code runs inside a special Windows process - w3wp.exe. Therefore, an exception inside a web application will only crash this process and will not affect the availability of web applications in other pools and the operation of IIS. Moreover, the WAS service will try to restart the fallen site, and external clients may not even notice problems in the server.

To manage some parameters of a single w3wp.exe workflow, IIS uses an application pool. The most commonly used ones are the account under which the process will be started, the restrictions on the request queue, various timers and counters for automatically restarting the process, the x86 / x64 architecture (in IIS 7.x) and some others (Fig. 5), о what a curious reader can easily read on MSDN and your favorite search engine. T.O. you can talk (with certain reservations, see also the last paragraph in 2.5) about the identity of the w3wp.exe process and the application pool.


Fig. 5 Advanced Application Pool Settings

The key innovation in the concept of application pools in IIS 7.x was a new parameter - the container management model, which can take 2 values: classic (Classic mode) and embedded model (Integrated mode).
To explain the difference between these modes of operation, you will need to become familiar with the concept of “Module” in IIS 6 / 7.x and the event-driven request processing model in IIS + ASP.NET. This topic is worthy of a separate article, but alas, I already do not have enough for it, apparently. Here I will bring to your attention only general, key points.

So, IIS, when processing a request, passes it inside the workflow through a sequence of special components - modules. For example filtering, redirection, caching, authentication, authorization. Each such module is associated with a specific event, and their sequence constitutes an event-driven request processing model. Modules are divided into Native and Managed. Native modules come with IIS, and managed modules come with the .NET Framework (ASP.NET). In general, you can manage them to a certain extent at the configuration level of the web application, but you can only interact with the managed modules from the code of your ASP.NET site.


Fig. 6. The ideology of modules in IIS.

Classic modelcontainer management provides backward compatibility with workflow isolation mode in IIS 6 - requests to the ASP.NET site first go through the native modules and then passed to Aspnet_isapi.dll for processing by the modules in a managed environment. This separation between IIS and ASP.NET leads to duplication of some functions, such as authentication and authorization. And you do not have the ability to programmatically control the behavior of native modules (an example, though not the most burning one, but still - the section “We remove the Server header” in this article ).

Embedded Modelinvolves closer interaction between IIS and ASP.NET. A request in such a processing architecture is passed through an established sequence of events, in each of which a request is passed through native and managed modules. In this mode, IIS and ASP.NET request processing models are combined into a single model, which helps to avoid duplication of functions and gain more control over request processing.

In practice, the most important thing to consider when developing and deploying web applications is the partial incompatibility of these two modes. Those. when translating a site (more precisely, the application pool in which the site operates) from the classical model to the embedded model, code adjustment (though perhaps not significant), as well as rigorous testing, will almost always be required.

2.5. Application Domain, Application

The direct containers of the web application are the application and the application domain (Application Domain, AppDomain). Often these two concepts are identified, but still these are slightly different things. An application is an IIS concept, and an application domain is from ASP.NET. Moreover, in the general case, an application may have several domains. You can manage the application from the IIS console, and the application domain is mostly programmatically. So, for example, the application restarts from the console. And when we re-save web.config, the application domain is rebooted without touching the IIS application.

More important from a practical point of view, the application / application domain is the sandbox for the code of your ASP.NET site (not with such reliable isolation as in the case of the pool, but still). I will give you one of my favorite questions that I asked applicants for interviews. Let there be website-1 and website-2, as well as some library MyLib.dll, in which the class MyClass1 with a static field Field1 is defined. So, both sites are running the same application pool and use the same MyLib.dll library. Website-1 writes to MyClass1.Field1 = 16 (Figure 7). Question: Will website 2 see the changes made? The answer is no. But why? Because, for IIS applications, disjoint address spaces are allocated, even if they work inside a single workflow,

Fig. 7. Figure for the puzzle.

Another important point that I would like to note here. By default, each individual workflow can use all the processors / kernels available on the server, and the application pool runs on the same workflow and, therefore, the web application runs inside the same IIS application. However, you can configure the web garden by increasing the number of workflows per pool and, therefore, the number of IIS applications per web application. You can easily find information on the web garden on the Internet, so I omit the details here. The only thing I would like to warn is that this tool is not a tool for increasing productivity, because by default, all the computing power of the server is used. On the contrary, synchronizing the work of 2+ work processes took “extra” CPU time. This is mainly done to increase the availability of the web application. It is also worth mentioning here about the web farm as the simplest means of load balancing in IIS - there are also enough articles on the Web about this. This is another example of a distributed web application. However, with the same nginx, the built-in load balancing in IIS does not stand up to competition, and in real high-load systems you will have to reinvent your bike or use third-party products.

3. What next?


Next, you need to understand the operation of modules (in IIS terms) and the event model, in which the request processing itself is already taking place, as mentioned in Section 2.4. Generally speaking, this topic deserves a separate article, which, I'm afraid, will not be enough for me. But without this, we cannot say that we examined the entire pipeline for processing requests. Therefore, we will briefly go through here on the main points that a curious reader can work out on his own.

As noted in Section 2.4 above, IIS modules are contained within the workflow. A request is passed through them sequentially (unlike HttpHandlers). Their set and order is determined by the configuration of the server and / or a specific web application. The modules are designed for separate, narrowly focused tasks, such as authorization, caching, custom logging, compression, returning static content, and, of course, generating HTML pages at a given URL.

As we already know, there are 2 types of modules in IIS: native and managed. You can find the exact list of modules in MSDN or in the Regan Templin article. You can always write your module, for example, for redirects. Most often, of course, they do managed modules, because they are easiest to implement. By the way, ASP.NET WebForms and MVC work in the form of such controlled modules. T.ch. I personally have WebForms vs. MVCs cause a smile and a hard-tempered desire to troll. Knowing the principles of IIS and ASP.NET, you yourself will be able to implement any pattern you like.

At the next level of consideration, we will encounter ASP.NET components such as HttpHandlers and page processing events. A lot of articles have been written about this, incl. I don’t see any reason to linger on this. The only thing I allow myself to advise those who go for interviews to score in the search engine “ASP.NET page lifecycle” before the meeting - this, of course, in my deep conviction is embarrassing for specialists who consider themselves developers on ASP.NET.

Example of default settings of native modules in applicationHost.config


Example of default settings of managed modules in applicationHost.config

            ***
                


Example default settings for HTTP handlers in applicationHost.config

            ***
                
            ***
        


Page Life Cycle in ASP.NET 2.0 WebForms



Page Life Cycle in ASP.NET 4.0 WebForms
image



Sources


  1. Our Everything - Introduction to IIS Architectures
  2. Application Domains Overview
  3. Application vs. Appdomain
  4. ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.0
  5. ASP.NET Application Life Cycle Overview for IIS 7.0
  6. Beginner's Guide: How IIS Process ASP.NET Request
  7. Exchange Server 2003 Services Dependencies: Internet Information Services
  8. HTTP Request Lifecycle Events in IIS Pipeline that every ASP.NET Developer Should Know
  9. Http.sys registry settings for Windows
  10. Understanding IIS 7.0 Architecture: Non-HTTP Request Processing
  11. Windows Server 2008 Events and Errors: IIS Windows Process Activation Service (WAS)
  12. Windows Server 2008 Events and Errors: IIS World Wide Web Publishing Service (W3SVC)
  13. Windows Server 2008 R2: Windows Process Activation Service (WAS) Overview

Also popular now: