Understanding IIS 7.0 Architecture : IIS 7.0 Core Components

In this section, we will look at IIS 7.0 core components and their role in process activation and request processing.

HTTP.sys

HTTP.sys is the protocol listener that listens for HTTP and HTTPS requests. HTTP.sys was introduced in IIS 6.0 as an HTTP-specific protocol listener for HTTP requests. In IIS 7.0, HTTP.sys also includes support for Secure Sockets Layer (SSL), which Lsass.exe provided in IIS 6.0.

HTTP.sys is a kernel-mode device driver for HTTP protocol stack. It is part of the networking subsystem of the Windows operating systems. Beginning with IIS 6.0, this kernel-mode driver replaced Windows Sockets API (Winsock), which was a user-mode component that previous versions of IIS used to receive HTTP requests and send HTTP responses.

When a client browser requests a Web page from a site on the IIS 7.0 server, HTTP.sys picks up the request on the site binding on the server machine and then passes it to the worker process for processing. After the request has been processed, HTTP.sys returns a response to the client browser.

Apart from intercepting and returning HTTP requests, HTTP.sys also performs the following tasks:

• Preprocessing and security filtering of the incoming HTTP requests

• Queuing of HTTP requests for the application pools

• Caching of the outgoing HTTP responses

Figure 1 shows HTTP.sys request queues and response cache.

Figure 1. HTTP request queue and response cache.

Having a request queue and a response cache served by a kernel-based HTTP listener reduces overhead in context switching to user mode and results in performance enhancements, as follows:

• Kernel-mode request queuing. Requests cause less overhead in context switching because the kernel forwards requests directly to the correct worker process. If no worker process is available to accept a request, the kernel-mode request queue holds the request until a worker process picks it up.

• Kernel-mode caching. Requests for cached responses are served without switching to user mode.

HTTP.sys maintains a request queue for each worker process. It sends the HTTP requests it receives to the request queue for the worker process that serves the application pool where the requested application is located. For each application, HTTP.sys maintains the URI namespace routing table with one entry. The routing table data is used to determine which application pool responds to requests from what parts of the namespace. Each request queue corresponds to one application pool. An application pool corresponds to one request queue within HTTP.sys and one or more worker processes.

If a faulty application causes a worker process failure, service is not interrupted, and the failure is undetectable by an end user because the kernel queues the requests while the WAS service starts a new worker process for that application pool. When the WAS service identifies an unhealthy worker process, it starts a new worker process if outstanding requests are waiting to be serviced. Although a temporary disruption occurs in user-mode request processing, the user does not experience the failure, because TCP/IP connections are maintained, and requests continue to be queued and processed. Only those requests that are running in the worker process when it fails will result in users seeing an error status. The requests that haven’t been processed yet will be redirected to the new worker process.

Other than retrieving a stored response from its internal cache, HTTP.sys does not process the requests that it receives. Therefore, no application-specific code is ever loaded into kernel mode but is processed inside the worker process that runs in the user mode. As a result, bugs in application-specific code cannot affect the kernel or lead to system failures.

World Wide Web Publishing Service

World Wide Web Publishing Service (W3SVC) changed significantly in IIS 7.0 in comparison with IIS 6.0.

In IIS 6.0, W3SVC was responsible for HTTP.sys management, configuration management, process management, and performance monitoring, as shown in Figure 2.

Figure 2. W3SVC in IIS 6.0.

In IIS 7.0, this functionality is split between two services: W3SVC and a service that is new to IIS 7.0, WAS. These two services run as LocalSystem in the same Svchost.exe process, and they share the same binaries. W3SVC and WAS in IIS 7.0 are shown in Figure 3.

Figure 3. W3SVC and WAS in IIS 7.0.

In IIS 7.0, W3SVC acts as listener adapter for the HTTP listener, HTTP.sys. Listener adapters are components that establish communication between WAS and protocol listeners. WAS includes a listener adapter interface that provides communication with listener adapters.

W3SVC is responsible for configuring HTTP.sys, updating HTTP.sys when configuration changes, and notifying WAS when a request enters the request queue. Additionally, W3SVC continues to collect the counters for Web sites. However, it no longer reads configuration information from the configuration store or manages application pools and worker processes. Instead, responsibilities for reading configuration and process activation and management are factored into WAS.

The changes in W3SVC service functionality between IIS 7.0 and IIS 6.0 are summarized in the following list:

• Configuration management

  • In IIS 6.0, W3SVC reads configuration information from IIS 6.0 configuration store, the metabase.

  • In IIS 7.0, W3SVC no longer reads configuration information from configuration store. Instead, WAS reads the configuration info from IIS 7.0 configuration store, applicationHost.config, and then passes it to W3SVC.

• HTTP.sys management

  • In IIS 6.0, W3SVC configures and updates HTTP.sys using configuration information it read from the metabase.

  • In IIS 7.0, W3SVC configures and updates HTTP.sys by using configuration information received from WAS. As a listener adapter for HTTP protocol, W3SVC owns communication between WAS and HTTP.sys.

• Process management

  • In IIS 6.0, W3SVC manages application pools and worker processes, including starting, stopping, and recycling worker processes. Additionally, W3SVC monitors the health of the worker processes and invokes rapid fail detection to stop new processes from starting when several worker processes fail in a specified amount of time.

  • In IIS 7.0, W3SVC no longer has any responsibilities for managing worker processes. These responsibilities have been passed to WAS.

• Performance monitoring

  • In IIS 6.0, W3SVC monitors performance and provides performance counters for Web sites and for IIS cache.

  • In IIS 7.0, W3SVC continues to collect the counters for Web sites.

Note

Because performance counters remain part of W3SVC, they are HTTP-specific and do not apply to WAS.

Windows Process Activation Service

The HTTP process activation model was introduced in IIS 6.0 with application pools. In IIS 7.0, this service has been extended and is called Windows Process Activation Service (WAS). It is capable of receiving requests or messages over any protocol and supports pluggable activation of arbitrary protocol listeners.

In IIS 7.0, WAS manages application pool configuration and worker processes. W3SVC performs this function in IIS 6.0. WAS includes the following components, as shown in Figure 3:

• Configuration manager, which reads application and application pool configuration from configuration store.

• Process manager, which maps application pools to existing worker processes and is responsible for starting new instances of W3wp.exe to host new application pools in response to activation requests.

• Listener adapter interface, which defines how external listeners communicate activation requests they receive to WAS. For example, the W3SVC service owns the communication with HTTP.sys and communicates HTTP activation requests to WAS across the listener adapter interface.

On startup, the configuration manager in WAS reads information from the configuration store and then passes that information to the HTTP listener adapter, W3SVC, which is responsible for communication with the HTTP listener, HTTP.sys. After W3SVC receives configuration information, it configures HTTP.sys and prepares it to listen for requests.

The configuration manager in WAS obtains the following information from configuration store:

• Global configuration information

• Protocol configuration information

• Application pool configuration, such as the process account information

• Site configuration, such as bindings and applications

• Application configuration, such as the enabled protocols and the application pools to which the application belongs

If configuration changes, the configuration manager in WAS receives a notification and subsequently updates W3SVC with the new information. After W3SVC receives the new configuration, it updates and configures HTTP.sys. For example, when you add or delete an application pool, the configuration manager processes the configuration changes and communicates them to W3SVC, which updates HTTP.sys to add or delete the application pool queue.

The process manager in WAS is responsible for managing the worker processes, which includes starting the worker processes and maintaining information about the running worker processes. It also determines when to start a worker process, when to recycle a worker process, and when to restart a worker process if it becomes blocked and is unable to process any more requests.

When HTTP.sys picks up a client request, the process manager in WAS determines if a worker process is already running. If an application pool already has a worker process servicing requests, then HTTP.sys passes the request to the worker process for processing. If there is no worker process in the application pool, the process manager starts a new worker process so that HTTP.sys can pass the request for processing to that worker process.

In addition to HTTP, WAS supports other protocols. The same configuration and process model used for HTTP are made available to non-HTTP applications and services. 

Configuration Store

In IIS 6.0, configuration data is stored in the XML-based metabase. IIS 7.0 no longer uses the metabase. Instead, configuration settings are stored in a distributed XML file–based configuration system that combines both IIS and ASP.NET settings.

The distributed configuration hierarchy includes the global, computer-wide, .NET Framework configuration files machine.config and root web.config; the global IIS configuration file applicationHost.config; and distributed web.config configuration files located within the Web sites, applications, and directories, as shown in Figure 4.

Because configuration files are stored together with Web site and application content, this configuration system enables xcopy deployment of configuration alongside application code and content, allows the server administrator to delegate administration of sites and applications to users without administrative privileges on the server computer, and also provides an easy way for sharing configuration across a Web farm.

IIS global server-wide configuration is stored in the applicationHost.config file located in the %SystemRoot%\system32\Inetsrv\Config folder. The WAS service obtains application pools and application configuration information from this file.

Figure 4. IIS 7.0 distributed configuration store.

IIS 7.0 provides several administration tools and application programming interfaces (APIs) that read and write configuration in the IIS 7.0 configuration system. The configuration files are clear text-based XML files, so you can use Notepad to work with IIS 7.0 configuration if you really wish. However, even for simple web.config files, this is very much prone to error and better to be avoided.

To simplify administration tasks, IIS 7.0 provides redesigned, task-based, feature-focused IIS Manager for graphical user interface (GUI)–based Web server management, and also offers a command line administration tool, Appcmd.exe. For programmatic access, there is a COM API for managing configuration programmatically from C++ programs, and a .NET API, Microsoft.Web.Administration, for .NET programs. Most of IIS Manager features are implemented using this new .NET API. An IIS 7.0 Windows Management Instrumentation (WMI) provider for scripting is provided as well, together with the legacy IIS 6.0 WMI provider that is available for backward compatibility with existing scripts.

Microsoft.Web.Administration API, Appcmd.exe, and the WMI provider are written on top of the COM API. This new administration stack is shown in Figure 5.

Figure 5. IIS 7.0 administration stack.

The legacy configuration store, the metabase, is not a part of IIS 7.0. However, for backward compatibility, IIS 7.0 provides the optional Metabase Compatibility feature that installs the IIS Administration Service (IISADMIN), which reads and writes the metabase in IIS 6.0. The Metabase Compatibility feature also installs the Inetinfo.exe process, which hosts the IISADMIN service. These two components provide the translation layer called the Admin Base Objects (ABO) Mapper. The ABO Mapper supports the legacy ABO APIs for working with the metabase but stores configuration directly in the IIS 7.0 configuration files. If you do not install the Metabase Compatibility feature, IIS 7.0 does not use IISADMIN service or the Inetinfo.exe process.

Worker Process

The role of a worker process is to process requests. A worker process is a self-contained long-running user mode process that runs as an executable named w3wp.exe.

Each worker process provides the core Web server functionality. As a result of a request processing within the worker process, the response is generated and is subsequently returned to the client. Each worker process uses HTTP.sys to receive requests and to send responses.

One worker process serves one application pool. An application pool groups together one or more applications. Because of this, you can apply specific configuration settings to groups of applications and to the worker processes servicing those applications.

Each application runs within an application pool. An application pool can be served by a set of worker processes. A worker process can serve only one application pool. Multiple worker processes that serve different application pools can run concurrently, as shown in Figure 6.

Figure 6. Process and application isolation.

The worker process boundaries separate application pools, which enables all application code to run in an isolated environment so that individual applications can execute within a self-contained worker process. The worker process isolation model was first introduced in IIS 6.0. This model prevents applications running within one application pool from affecting applications in a different application pool on the server, providing sandboxing of applications.

Within a worker process, application domains provide application boundaries for .NET applications. Each .NET application runs in its own application domain (AppDomain), as shown in Figure 6. An application domain loads the application’s code when the application starts. Virtual directories within an application are served by the same AppDomain as the application to which they belong.

Direct from the Source: Application Pool Isolation in IIS 7.0

The application pool design introduced by IIS 6.0 has been the foundation of enabling greater security isolation of multiple applications and improving the fault-tolerance of the Web server. IIS 7.0 continues to leverage this concept, and it no longer provides support for the legacy IIS 5.0 Isolation Model. The majority of the features that made application pools successful with IIS 6.0 remain, including the ability to run each application pool with different credentials and configure intelligent health monitoring and recycling settings to maintain application reliability.

IIS 7.0 goes further, by providing automatic application pool isolation through automatically generated Security Identifiers (SIDs) for application pools, and automatically isolating server-level configuration such that it can only be read by the application pool it affects. This makes it easier than ever before to configure fully isolated Web applications by leveraging application pools.

In addition, IIS 7.0 in Windows Server 2008 delivers a number of performance improvements that significantly increase the number of application pools that can be configured and active on a single Web server, both through lower worker process footprint and intelligent worker process management features. These improvements make it easier for Web hosting providers to place each individual application into a separate application pool, in order to achieve the maximum security and fault isolation for those applications.

Be sure to fully utilize the capabilities afforded by application pool isolation when designing your Web application infrastructure.

Mike Volodarsky

IIS Core Server Program Manager

Requests within each worker process can be executed in one of two different ways: in .NET Integrated mode when both IIS and ASP.NET requests use the same integrated request processing pipeline, or in Classic mode when two separate pipelines are used for IIS and ASP.NET processing. You can configure an application pool to determine in which of the two modes to execute ASP.NET requests. In the next section, we will focus on the request processing architecture within worker processes serving the application pools.