Академический Документы
Профессиональный Документы
Культура Документы
• A new service, Windows Process Activation Service (WAS), which enables sites to
use protocols other than HTTP and HTTPS.
• A Web server engine that can be customized by adding or removing modules.
• A new approach to processing requests, integrating the request-processing
pipelines from IIS and ASP.NET.
This article describes the components, modules, and request-processing architecture in the
following sections:
• IIS 7 Components
• Protocol Listeners
• Hypertext Transfer Protocol Stack (HTTP.sys)
• World Wide Web Publishing Service (WWW service)
• Windows Process Activation Service (WAS)
• IIS 7 Modules
• Native Modules
• Managed Modules
• IIS 7 Request Processing
• IIS 7 Application Pools
• HTTP Request Processing in IIS 7
IIS 7 Components
IIS 7 contains several components that perform important functions for the application and Web
server roles in Windows Server® 2008 (IIS 7.0) and Windows Server 2008 R2 (IIS 7.5). Each
component has responsibilities, such as listening for requests made to the server, managing
processes, and reading configuration files. These components include protocol listeners, such as
HTTP.sys, and services, such as World Wide Web Publishing Service (WWW service) and Windows
Process Activation Service (WAS).
Protocol Listeners
Protocol listeners receive protocol-specific requests, send them to IIS for processing, and then
return responses to requestors. For example, when a client browser requests a Web page from
the Internet, the HTTP listener, HTTP.sys, picks up the request and sends it to IIS for processing.
Once IIS processes the request, HTTP.sys returns a response to the client browser.
By default, IIS 7 provides HTTP.sys as 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. HTTP.sys remains the HTTP listener in IIS 7, but includes support for Secure Sockets
Layer (SSL).
To support services and applications that use protocols other than HTTP and HTTPS, you can use
technologies such as Windows Communication Foundation (WCF). WCF has listener adapters that
provide the functionality of both a protocol listener and a listener adapter. Listener adapters are
covered later in this document. For more information about WCF, see Windows Communication
Foundation on MSDN.
In IIS 6.0, HTTP.sys replaced Windows Sockets API (Winsock), which was a user-mode component
used by previous versions of IIS to receive HTTP requests and send HTTP responses. IIS 7
continues to rely on HTTP.sys for HTTP requests.
Note You may also see the WWW Service referred to as W3SVC in documentation.
The WWW Service reads configuration information from the IIS metabase and uses that
information to configure and update the HTTP listener, HTTP.sys. In addition, WWW service starts,
stops, monitors, and manages worker processes that process HTTP requests.
Performance Monitoring
The WWW Service monitors performance and provides performance counters for Web sites and
for the IIS cache.
Process Management
The WWW Service manages application pools and worker processes, such as starting, stopping,
and recycling worker processes. Additionally, the WWW Service 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 configurable amount of time.
Additionally, the WWW Service continues to collect the counters for Web sites. Because
performance counters remain part of the WWW Service, they are HTTP specific and do not apply
to WAS.
In the case of WCF, a listener adapter includes the functionality of a protocol listener. So, a WCF
listener adapter, such as NetTcpActivator, is configured based on information from WAS. Once
NetTcpActivator is configured, it listens for requests that use the net.tcp protocol. For more
information about WCF listener adapters, see WAS Activation Architecture on MSDN.
The following list describes the type of information that WAS reads from configuration:
If ApplicationHost.config changes, WAS receives a notification and updates the listener adapters
with the new information.
Process Management
WAS manages application pools and worker processes for both HTTP and non-HTTP requests.
When a protocol listener picks up a client request, WAS determines if a worker process is running
or not. If an application pool already has a worker process that is servicing requests, the listener
adapter passes the request onto the worker process for processing. If there is no worker process
in the application pool, WAS will start a worker process so that the listener adapter can pass the
request to it for processing.
Note: Because WAS manages processes for both HTTP and non-HTTP protocols, you can run
applications with different protocols in the same application pool. For example, you can develop
an application, such as an XML service, and host it over both HTTP and net.tcp.
IIS 7 Modules
IIS 7 provides a new architecture that is different from previous versions of IIS. Instead of keeping
the majority of functionality within the server itself, IIS 7 includes a Web server engine in which
you can add or remove components, called modules, depending on your needs.
Modules are individual features that the server uses to process requests. For example, IIS uses
authentication modules to authenticate client credentials, and cache modules to manage cache
activity.
The new architecture provides the following advantages over previous versions of IIS:
The IIS 7 architecture also improves security and simplifies administration. By removing
unnecessary modules, you reduce the server's attack surface and memory footprint, which is the
amount of memory that server worker processes use on the machine. You also eliminate the
need to manage features that are unnecessary for your sites and applications.
Native Modules
The following sections describe the native modules that are available with a full installation of IIS
7. You can remove them or replace them with custom modules, depending on your needs.
HTTP Modules
Several modules in IIS 7 perform tasks specific to Hypertext Transfer Protocol (HTTP) in the
request-processing pipeline. HTTP modules include modules to respond to information and
inquiries sent in client headers, to return HTTP errors, to redirect requests, and more.
HttpRedirectionMod Inetsrv\Redirect.d
Supports configurable redirection for HTTP requests.
ule ll
Security Modules
Several modules in IIS 7 perform tasks related to security in the request-processing pipeline. In
addition, there are separate modules for each of the authentication schemes, which enable you
to select modules for the types of authentication you want on your server. There are also
modules that perform URL authorization, and a module that filters requests.
Performs Anonymous
authentication when no other Inetsrv\Authanon.
AnonymousAuthenticationModule
authentication method dll
succeeds.
Inetsrv\Authmd5.d
DigestAuthenticationModule Performs Digest authentication.
ll
Inetsrv\Urlauthz.dl
UrlAuthorizationModule Performs URL authorization.
l
Content Modules
Several modules in IIS 7 perform tasks related to content in the request-processing pipeline.
Content modules include modules to process requests for static files, to return a default page
when a client doesn't specify a resource in a request, to list the contents of a directory, and
more.
DirectoryListingModul
Lists the contents of a directory. Inetsrv\dirlist.dll
e
ServerSideIncludeMod
Processes server-side includes code. Inetsrv\Iis_ssi.dll
ule
Compression Modules
Two modules in IIS 7 perform compression in the request-processing pipeline.
Module Name Description Resource
StaticCompressionModul Inetsrv\Compstat.
Performs pre-compression of static content.
e dll
Caching Modules
Several modules in IIS 7 perform tasks related to caching in the request-processing pipeline.
Caching improves the performance of your Web sites and Web applications by storing processed
information, such as Web pages, in memory on the server, and then reusing that information in
subsequent requests for the same resource.
FileCacheModule Provides user mode caching for files and file handles. Inetsrv\Cachfile.dll
TokenCacheMod Provides user mode caching of user name and token pairs Inetsrv\Cachtokn.
ule for modules that produce Windows user principals. dll
Inetsrv\Logcust.d
CustomLoggingModule Loads custom logging modules.
ll
FailedRequestsTracingMo
Supports the Failed Request Tracing feature. Inetsrv\Iisfreb.dll
dule
Provides
integration of
managed code
Microsoft.NET\Framework\v2.0.50727\webengi
ManagedEngine modules in the IIS
ne.dll
request-
processing
pipeline.
Validates
configuration
issues, such as
when an
application is
ConfigurationValidationMo running in
Inetsrv\validcfg.dll
dule Integrated mode
but has handlers
or modules
declared in the
system.web
section.
Managed Modules
In addition to native modules, IIS 7 enables you to use managed code modules to extend IIS
functionality. Some of the managed modules, such as UrlAuthorization, have a native module
counterpart that provides a native alternative to the managed module.
Manages anonymous
identifiers, which are
AnonymousIdentificat used by features that System.Web.Security.AnonymousIdentification
ion support anonymous Module
identification such as
ASP.NET profile.
Ensures that an
authentication object System.Web.Security.DefaultAuthenticationMod
DefaultAuthentication
is present in the ule
context.
Supports
authentication by System.Web.Security.FormsAuthenticationMod
FormsAuthentication
using Forms ule
authentication.
Supports output
OutputCache System.Web.Caching.OutputCacheModule
caching.
Manages a
RoleManager RolePrincipal instance System.Web.Security.RoleManagerModule
for the current user.
Determines whether
the current user is
permitted access to
the requested URL,
UrlAuthorization System.Web.Security.UrlAuthorizationModule
based on the user
name or the list of
roles of which a user
is a member.
Supports mapping a
UrlMappingsModule real URL to a more System.Web.UrlMappingsModule
user-friendly URL.
This design provides several benefits over previous versions of IIS. First, all file types can use
features that were originally available only to managed code. For example, you can now use
ASP.NET Forms authentication and Uniform Resource Locator (URL) authorization for static files,
Active Server Pages (ASP) files, and all other file types in your sites and applications.
Second, this design eliminates the duplication of several features in IIS and ASP.NET. For
example, when a client requests a managed file, the server calls the appropriate authentication
module in the integrated pipeline to authenticate the client. In previous versions of IIS, this same
request would go through an authentication process in both the IIS pipeline and in the ASP.NET
pipeline.
Third, you can manage all of the modules in one location, instead of managing some features in
IIS and some in the ASP.NET configuration. This simplifies the administration of sites and
applications on the server.
Note: In IIS 6.0, worker process isolation mode and IIS 5.0 isolation mode are set at the server
level. This makes it impossible to run both isolation modes on the same server. However, in IIS 7,
Integrated mode and Classic mode are set at the application pool level, which enables you to run
applications simultaneously in application pools with different process modes on the same server.
There are several benefits to running application pools in Integrated mode. First the request-
processing models of IIS and ASP.NET are integrated into a unified process model. This model
eliminates steps that were previously duplicated in IIS and ASP.NET, such as authentication.
Additionally, Integrated mode enables the availability of managed features to all content types.
Be sure to test your existing applications for compatibility in Integrated mode before upgrading a
production environment to IIS 7 and assigning applications to application pools in Integrated
mode. You should only add an application to an application pool in Classic mode if the application
fails to work in Integrated mode. For example, your application might rely on an authentication
token passed from IIS to the managed runtime, and, due to the new architecture in IIS 7, the
process breaks your application.
IIS 7 has a similar HTTP request-processing flow as IIS 6.0. The diagrams in this section provide
an overview of an HTTP request in process.
The following list describes the request-processing flow that is shown in Figure 1:
1. When a client browser initiates an HTTP request for a resource on the Web server,
HTTP.sys intercepts the request.
2. HTTP.sys contacts WAS to obtain information from the configuration store.
3. WAS requests configuration information from the configuration store,
applicationHost.config.
4. The WWW Service receives configuration information, such as application pool and
site configuration.
5. The WWW Service uses the configuration information to configure HTTP.sys.
6. WAS starts a worker process for the application pool to which the request was
made.
7. The worker process processes the request and returns a response to HTTP.sys.
8. The client receives a response.
Figure 1: Overview of an HTTP Request
In a worker process, an HTTP request passes through several ordered steps, called events, in the
Web Server Core. At each event, a native module processes part of the request, such as
authenticating the user or adding information to the event log. If a request requires a managed
module, the native ManagedEngine module creates an AppDomain, where the managed module
can perform the necessary processing, such as authenticating a user with Forms authentication.
When the request passes through all of the events in the Web Server Core, the response is
returned to HTTP.sys. Figure 2, below, shows an HTTP request entering the worker process.
Figure 2: Detail of a HTTP request inside the Worker Process
• ISAPI requests
By understanding the fundamentals of IIS architecture and the related functionality, you can discover and
isolate problems much more quickly. You will also be better equipped to differentiate between real problems
and expected behavior.
This section explores the following functionality, which any IIS troubleshooter must understand:
• HTTP Protocol Basics: Explains the way Internet browsers and servers running IIS communicate with
each other.
• IIS Service Startup: Sometimes problems arise even before IIS starts servicing requests. This section
describes the startup process and typical startup behavior, which can help you determine the causes of
problems.
• HTTP Request Walkthrough: Explains the various phases that a typical request passes through as it
moves through the service.
100 Informational
200 Successful
300 Redirection