Category Archives: IIS

HTTP Request flow in IIS (Image)

Overview of an HTTP Request :


The following list describes the request-processing flow :

  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.

Detail of a HTTP request inside the Worker Process


ASP.NET Request Flow:


  • IIS gets the request
  • Looks up a script map extension and maps to aspnet_isapi.dll
  • Code hits the worker process (aspnet_wp.exe in IIS5 or w3wp.exe in IIS6)
  • .NET runtime is loaded
  • IsapiRuntime.ProcessRequest() called by non-managed code
  • IsapiWorkerRequest created once per request
  • HttpRuntime.ProcessRequest() called with Worker Request
  • HttpContext Object created by passing Worker Request as input
  • HttpApplication.GetApplicationInstance() called with Context to retrieve instance from pool
  • HttpApplication.Init() called to start pipeline event sequence and hook up modules and handlers
  • HttpApplicaton.ProcessRequest called to start processing
  • Pipeline events fire
  • Handlers are called and ProcessRequest method are fired
  • Control returns to pipeline and post request events fire


A low-level Look at the ASP.NET Architecture

IIS Architecture

支持高并发的IIS Web服务器常用设置

适用的IIS版本:IIS 7.0, IIS 7.5, IIS 8.0

适用的Windows版本:Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

1、应用程序池(Application Pool)的设置: 

  • General->Queue Length设置为65535(队列长度所支持的最大值)
  • Process Model->Idle Time-out设置为0(不让应用程序池因为没有请求而回收)
  • Recycling->Regular Time Interval设置为0(禁用应用程序池定期自动回收)

2、.Net Framework相关设置

a) 在machine.config中将



b) 打开C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Browsers\Default.browser,找到<defaultBrowser id=”Wml” parentID=”Default” >,注释<capabilities>部分,然后运行在命令行中运行aspnet_regbrowsers -i。










注册表设置命令2(解决Bad Request – Request Too Long问题):

(需要在命令行运行 net stop http  & net start http & iisreset 使设置生效)


在Url Rewrite Module中增加如下的规则:





6、 设置Cache-Control为public







Introduction to ApplicationHost.config


ApplicationHost.config is the root file of the configuration system when you are using IIS 7 and above. It includes definitions of all sites, applications, virtual directories and application pools, as well as global defaults for the web server settings (similar to machine.config and the root web.config for .NET Framework settings).

It is also special in that it is the only IIS configuration file available when the web server is installed (however, users can still add web.config files if they want to). It includes a special section (called configSections) for registering all IIS and Windows Activation System (WAS) sections (machine.config has the same concept for .NET Framework sections). It has definitions for locking-down most IIS sections to the global level, so that by default they cannot be overridden by lower-level web.config files in the hierarchy.

The location of the file is currently in the system32\inetsrv directory, but this is expected to change after beta2 to system32\inetsrv\config. This document walks through all the sections, in the order they appear in the file, and explains them one by one. The most complex section is system.webServer, so it is recommended for the reader to not skip reading the description for that section in particular.

Note the following:

  1. This document specifies the content of each configuration section, as appears in applicationHost.config. By design, many of the sections are empty or not complete (only some of their content appears in the XML). The rest of the values are taken from the schema defaults. This is done to avoid too much information and cluttering of the file, and in order to keep it reasonably readable.

For full schema reference, including default values for all properties in every section, their valid ranges, etc., refer to %windir%\system32\inetsrv\config\schema\IIS_Schema.xml (for IIS settings), or ASPNET_Schema.xml (for ASP.NET settings), or FX_Schema.xml (for other .NET Framework settings).

For convenience, chunks of these files are included in this document in the appropriate sections so the reader can understand which properties are available, what the default values are, etc., for each section. See the additional note below about how to read schema information.

2. Make a backup of the file before making any changes to it.

This document contains:

How to Read Config Schema

As noted above, this document contains snippets of schema information for each section, so the reader can discover what properties are available and what their default values and valid ranges are. The snippets are taken directly from the configuration schema file for IIS settings: %windir%\system32\inetsrv\config\schema\IIS_Schema.xml. This section explains how to read schema information.

The schema for each configuration section is defined in a XML element. There is no schema definition for section groups. The following format is used here to explain how to read the schema:

<attribute-name> is the name of the configuration attribute, as appears in XML. Every attribute must have a name.

<default-value> is the value used by default, if no other value is specified in the XML for the attribute. Not all attributes have default values (for example, site name). In this case, the syntax will be “”.

<metadata> contains several items:

  • The runtime type of the attribute. This is one of “bool”, “enum”, “flags”, “int”, “int64″, “String”, “timeSpan”. Every attribute must have a type.
  • “bool” is “true” or “false”.
  • “enum” is a set of possible values, where only one of them can be set for the attribute. Every such value has a numerical value and a friendly name. The syntax is using the character “|” as a delimiter between the friendly names: value1|value2|…|valueN.
  • “flags” is similar to “enum”, except that combinations of values are allowed. Therefore the numerical values should be in multiples of 2, so they can be ORed together to form combinations. The syntax is identical to “enum”: value1|value2|…|valueN.
  • “int” is a 32 bit integer.
  • “int64″ is a 64 bit integer.
  • “String” is a character string.
  • “timeSpan” is a representation of a time unit, similar to the managed-code type TimeSpan. It can be persisted as a number (representing seconds, or minutes); or as a formatted string in the form of “[dd:]hh:mm:ss”. The “[dd:]” element represents an optional number of days. The other elements represent numbers of hours, minutes and seconds, respectively. The “timeSpanFormat” attribute specifies which format should be used: number of seconds, number of minutes, or a formatted string.
  • Required attributes are marked “Required”. It means that a value for them must be set in the XML. For example, site name is a required attribute (every site must have a name in IIS 7.0 and above).

<description> is a short description of the attribute.

Section Schema

The <sectionSchema> XML element is the base unit of schema information. All other schema information is specified within it. It has one attribute directly in it (“name”), and then the rest of the schema is in sub-elements within it:

<sectionSchema name=””  <!– [String, Required] [XML full path of the section] –> > 
    <!– sub-elements here describing rest of schema; –> 
    <!– their description is right below in the doc. –>  

Attribute Schema

Every attribute is defined in a corresponding <attribute> XML element in the schema. The <attribute> element may be in the <sectionSchema> element directly (if the attribute is in the section scope); or in the element (if the attribute is in a sub-element within the section); or in the <collection> element (if the attribute is in a collection within the section).

An attribute schema must specify a name and a runtime type for the attribute. It may mark the attribute as required. It may mark the attribute as the unique key (if inside a collection), or as part of a collection key (together with other attributes). It may specify a default value for the attribute. It may mark the attribute for automatic encryption on-disk. It may specify if the word “Infinite” is allowed as a value for the attribute (only for numeric types such as int and in64, and for timeSpan). It may specify the timespan format (seconds, minutes or formatted string) for timespan attributes. It may specify validation rules for the attributes (see Attribute Validation section below in this document).

Element Schema

Every element is defined in a corresponding <element> XML element in the schema. Elements can be nested. An element is simply a container for other attributes, or sub-elements. It must have a name and it may serve as a container of default values for collection elements (for example, siteDefaults holds the default values for sites in the <sites> collection).

Collection Schema

Every collection is defined in a corresponding <collection> XML element in the schema. Collections contain multiple elements, which can be added and removed from them individually. Typically the collection directive names are “add”, “remove” and “clear”, but some collections use different names for clarity (for example, the collection is using “site” instead of “add”).

This is done by specifying values for addElement, removeElement and clearElement in the collection schema. If a collection directive is missing from the schema, the collection will not support it. The collection schema may specify the name of a default element that will be used as a container of default values for collection elements (this complements isCollectionDefault in the element schema).

For example, the collection is using siteDefaults as the default element. Most collections append elements as they merge configuration files down the namespace, but some may specify mergeAppend=”false” in the schema to have a prepend behavior. For example, consider two levels of configuration: applicationHost.config and web.config in a site. In applicationHost.config:

    <add value=”1″/>  
In web.config:

If the collection appends, its merged (effective) configuration at the site level will be:

However, if it prepends, it will be:

Some collections may allow duplicate entries by specifying allowDuplicates=”true” in their schema. This is mostly done to support legacy collections in the .NET framework (in machine.config).

Some collections may allow additional attributes in them, beyond those specified in the schema. This is done by specifying allowUnrecognizedAttributes=”true” in their schema. It is mostly done to support provider-based collections in the .NET framework.


    addElement=””     [String] [Name of Add directive, if supported] 
    removeElement=””  [String] [Name of Remove directive, if supported] 
    clearElement=””   [String] [Name of Clear directive, if supported] 
    defaultElement=”” [applicationDefaults|applicationPoolDefaults|siteDefaults|virtualDirectoryDefaults] [See isCollectionDefault] 
    mergeAppend=”true”  [bool] [Indicates whether or not deepest set values are appended]   
    allowDuplicates=”false”  [bool] [Indicates if multiple elements may have the same keys] 
    allowUnrecognizedAttributes=”false”  [bool] [Indicates if non-schema attributes ok] 

Enum Schema

Every attribute of type “enum” must define its enum values in a corresponding <enum> XML element in the schema. Every value must have a friendly name and a numerical value.

<enum name=””  [String, Required] [Friendly name of the enum] 
    value=”” [int, Required] [Numeric value] 

Flags Schema

Every attribute of type “flags” must define its flag values in a corresponding XML element in the schema. Every flag must have a friendly name and a numerical value that can be ORed together with other values to form combinations; therefore, the value should be in multiples of 2.

    name=””  [String, Required] [Friendly name of the flag] 
    value=”” [int in power of 2, Required] [Numeric value] 

Attribute Validation

Attribute validation is done when parsing the XML to get a section from the file, and when calling the configuration API to set values. If validation fails, it fails the desired operation (getting the section or setting the invalid value).

Each attribute may associate one validator for its value. This is done by specifying the appropriate validator name in the validationType, and additional parameters in the validationParameter in the attribute schema.

The system supports these validators:

ApplicationPoolName validator

This validator fails on these characters: |<>&\”validationType=”applicationPoolName” validationParameter=””

IntegerRange validator

This validator fails if value is outside [inside] range, in integers.validationType=”integerRange” 

NonEmptyString validator

This validator fails if string value is set.validationType=”nonEmptyString” 

SiteName validator

This validator fails on these characters: /\.?validationType=”siteName” 

TimeSpanRange validator

This validator fails if value is outside [inside] range, in seconds.validationType=”timeSpanRange” 

TrimWhiteSpace validator

This validator fails if white space is set at start or end of value.validationType=”trimWhiteSpaceString” 

XML Header

Every configuration file is an XML file and may optionally include the following line as the first line:

In addition, it must include all its content within an XML <configuration> tags:

ApplicationHost.config includes the above lines in it. The rest of this document walks throughthe rest of the sections in the file.

<configSections> Section

This is the very first section in the file. It contains a list of all other sections in the file. This is the point of registration for the sections (for example, to unregister a section from the system, remove its line from this section – no need to remove its schema file from the config\schema directory).

Note that other configuration files may have a section as well, at the very top of the file. This may be useful to register sections at levels lower than the global level. These sections will be registered for that scope of the namespace only. Web.config files can only add sections to the system; they cannot redefine sections that were registered in parent levels, and they cannot remove (unregister) sections.

The sections are structured by their hierarchy of containing section groups. Each section registration specifies the section name; the managed-code type of the section handler (this has no meaning in this file and will get removed after beta2 – it is used only by System.Configuration, so it will still exist in machine.config and web.config files); the allowDefinition level, if differs from the default; and the overrideModeDefault (this attribute is used to lockdown most IIS sections in this file).

Note: Section is the basic unit of deployment, registration, locking, searching and containment of configuration settings. Every section belongs to one section group (“immediate parent”). Section group is a container of logically-related sections, and is used solely for purposes of structured hierarchy. No operations can be done on section groups. Section groups cannot have configuration settings directly (the settings belong to sections). Section groups may be nested; section cannot.



Most IIS sections are locked down by default, using overrideModeDefault=”Deny” in the section. The recommended way to unlock sections is by using tags, as follows:

The above location tag unlocks the section for the default web site only. To unlock it for all sites, specify this in applicationHost.config:

Note: path=”.” and path=”” have the same effect. They refer to the current level in the hierarchy.


Introduction to IIS Architecture


Internet Information Services (IIS) 7 and above provides a request-processing architecture that includes:

  • The 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.
  • Integrated request-processing pipelines from IIS and ASP.NET.

This article describes the components, modules, and request-processing architecture in the following sections:

Components in IIS

IIS 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 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 and above, 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.

Hypertext Transfer Protocol Stack (HTTP.sys)

The HTTP listener is part of the networking subsystem of Windows operating systems, and it is implemented as a kernel-mode device driver called the HTTP protocol stack (HTTP.sys). HTTP.sys listens for HTTP requests from the network, passes the requests onto IIS for processing, and then returns processed responses to client browsers.

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 and above continue to rely on HTTP.sys for HTTP requests.

HTTP.sys provides the following benefits:

  • Kernel-mode caching. Requests for cached responses are served without switching to user mode.
  • 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.
  • Request pre-processing and security filtering.

World Wide Web Publishing Service (WWW service)

In IIS 7 and above, functionality that was previously handled by the World Wide Web Publishing Service (WWW Service) alone is now split between two services: WWW Service and a new service, Windows Process Activation Service (WAS). These two services run as LocalSystem in the same Svchost.exe process, and share the same binaries.

Note   You may also see the WWW Service referred to as W3SVC in documentation.

How WWW Service works in IIS 6.0

In IIS 6.0, WWW Service manages the following main areas in IIS:

  • HTTP administration and configuration
  • Process management
  • Performance monitoring

HTTP Administration and Configuration

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.

How the WWW Service works in IIS

In IIS, the WWW service no longer manages worker processes. Instead, the WWW Service is the listener adapter for the HTTP listener, HTTP.sys. As the listener adapter, the WWW Service is primarily responsible for configuring HTTP.sys, updating HTTP.sys when configuration changes, and notifying WAS when a request enters the request queue.

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.

Windows Process Activation Service (WAS)

In IIS 7 and above, Windows Process Activation Service (WAS) manages application pool configuration and worker processes instead of the WWW Service. This enables you to use the same configuration and process model for HTTP and non-HTTP sites.

Additionally, you can run WAS without the WWW Service if you do not need HTTP functionality. For example, you can manage a Web service through a WCF listener adapter, such as NetTcpActivator, without running the WWW Service if you do not need to listen for HTTP requests in HTTP.sys. For information about WCF listener adapters and about how to host WCF applications in IIS 7 and above by using WAS, see Hosting in WCF on MSDN.

Configuration Management in WAS

On startup, WAS reads certain information from the ApplicationHost.config file, and passes that information to listener adapters on the server. Listener adapters are components that establish communication between WAS and protocol listeners, such as HTTP.sys. Once listener adapters receive configuration information, they configure their related protocol listeners and prepare the listeners to listen for requests.

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:

  • Global configuration information
  • Protocol configuration information for both HTTP and non-HTTP protocols
  • 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 applications belong

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.


Modules in IIS

IIS provides a new architecture that is different from previous versions of IIS. Instead of keeping the majority of functionality within the server itself, IIS include 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:

  • You can control which modules you want on the server.
  • You can customize a server to a specific role in your environment.
  • You can use custom modules to replace existing modules or to introduce new features.

The new 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 and above. You can remove them or replace them with custom modules, depending on your needs.

HTTP Modules

Several modules in IIS 7 and above 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.

Module Name Description Resource
CustomErrorModule Sends default and configured HTTP error messages when an error status code is set on a response. Inetsrv\Custerr.dll
HttpRedirectionModule Supports configurable redirection for HTTP requests. Inetsrv\Redirect.dll
ProtocolSupportModule Performs protocol-related actions, such as setting response headers and redirecting headers based on configuration. Inetsrv\Protsup.dll
RequestFilteringModule Added in IIS 7.5. Filters requests as configured to control protocol and content behavior. Inetsrv\modrqflt.dll
WebDAVModule Added in IIS 7.5. Allows more secure publishing of content by using HTTP over SSL. Inetsrv\WebDAV.dll

Security Modules

Several modules in IIS 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.

Module Name Description Resource
AnonymousAuthenticationModule Performs Anonymous authentication when no other authentication method succeeds. Inetsrv\Authanon.dll
BasicAuthenticationModule Performs Basic authentication. Inetsrv\Authbas.dll
CertificateMappingAuthenticationModule Performs Certificate Mapping authentication using Active Directory. Inetsrv\Authcert.dll
DigestAuthenticationModule Performs Digest authentication. Inetsrv\Authmd5.dll
IISCertificateMappingAuthenticationModule Performs Certificate Mapping authentication using IIS certificate configuration. Inetsrv\Authmap.dll
RequestFilteringModule Performs URLScan tasks such as configuring allowed verbs and file name extensions, setting limits, and scanning for bad character sequences. Inetsrv\Modrqflt.dll
UrlAuthorizationModule Performs URL authorization. Inetsrv\Urlauthz.dll
WindowsAuthenticationModule Performs NTLM integrated authentication. Inetsrv\Authsspi.dll
IpRestrictionModule Restricts IPv4 addresses listed in the ipSecurity list in configuration. Inetsrv\iprestr.dll

Content Modules

Several modules in IIS 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.

Module Name Description Resource
CgiModule Executes Common Gateway Interface (CGI) processes to build response output. Inetsrv\Cgi.dll
DefaultDocumentModule Attempts to return a default document for requests made to the parent directory. Inetsrv\Defdoc.dll
DirectoryListingModule Lists the contents of a directory. Inetsrv\dirlist.dll
IsapiModule Hosts ISAPI extension DLLs. Inetsrv\Isapi.dll
IsapiFilterModule Supports ISAPI filter DLLs. Inetsrv\Filter.dll
ServerSideIncludeModule Processes server-side includes code. Inetsrv\Iis_ssi.dll
StaticFileModule Serves static files. Inetsrv\Static.dll
FastCgiModule Supports FastCGI, which provides a high-performance alternative to CGI. Inetsrv\iisfcgi.dll

Compression Modules

Two modules in IIS perform compression in the request-processing pipeline.

Module Name Description Resource
DynamicCompressionModule Compresses responses and applies Gzip compression transfer coding to responses. Inetsrv\Compdyn.dll
StaticCompressionModule Performs pre-compression of static content. Inetsrv\Compstat.dll

Caching Modules

Several modules in IIS 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.

Module Name Description Resource
FileCacheModule Provides user mode caching for files and file handles. Inetsrv\Cachfile.dll
HTTPCacheModule Provides kernel mode and user mode caching in HTTP.sys. Inetsrv\Cachhttp.dll
TokenCacheModule Provides user mode caching of user name and token pairs for modules that produce Windows user principals. Inetsrv\Cachtokn.dll
UriCacheModule Provides user mode caching of URL information. Inetsrv\Cachuri.dll

Logging and Diagnostics Modules

Several modules in IIS perform tasks related to logging and diagnostics in the request-processing pipeline. The logging modules support loading of custom modules and passing information to HTTP.sys. The diagnostics modules follow and report events during request processing.

Module Name Description Resource
CustomLoggingModule Loads custom logging modules. Inetsrv\Logcust.dll
FailedRequestsTracingModule Supports the Failed Request Tracing feature. Inetsrv\Iisfreb.dll
HttpLoggingModule Passes information and processing status to HTTP.sys for logging. Inetsrv\Loghttp.dll
RequestMonitorModule Tracks requests currently executing in worker processes and reports information with Runtime Status and Control Application Programming Interface (RSCA). Inetsrv\Iisreqs.dll
TracingModule Reports events to Microsoft Event Tracing for Windows (ETW). Inetsrv\Iisetw.dll

Managed Support Modules

A couple of modules in IIS support managed integration in the IIS request-processing pipeline.

Module Name Description Resource
ManagedEngine Provides integration of managed code modules in the IIS request-processing pipeline. Microsoft.NET\Framework\v2.0.50727\webengine.dll
ConfigurationValidationModule Validates configuration issues, such as when an application is running in Integrated mode but has handlers or modules declared in the system.web section. Inetsrv\validcfg.dll

Managed Modules

In addition to native modules, IIS 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.

Note   Managed modules depend on the ManagedEngine module.

The following table lists the managed modules that are available with a full installation of IIS 7 and above. For more information about the managed modules, see the .NET Framework SDK 2.0 on MSDN.

Module Name Description Resource
AnonymousIdentification Manages anonymous identifiers, which are used by features that support anonymous identification such as ASP.NET profile. System.Web.Security.AnonymousIdentificationModule
DefaultAuthentication Ensures that an authentication object is present in the context. System.Web.Security.DefaultAuthenticationModule
FileAuthorization Verifies that a user has permission to access the requested file. System.Web.Security.FileAuthorizationModule
FormsAuthentication Supports authentication by using Forms authentication. System.Web.Security.FormsAuthenticationModule
OutputCache Supports output caching. System.Web.Caching.OutputCacheModule
Profile Manages user profiles by using ASP.NET profile, which stores and retrieves user settings in a data source such as a database. System.Web.Profile.ProfileModule
RoleManager Manages a RolePrincipal instance for the current user. System.Web.Security.RoleManagerModule
Session Supports maintaining session state, which enables storage of data specific to a single client within an application on the server. System.Web.SessionState.SessionStateModule
UrlAuthorization Determines whether the current user is permitted access to the requested URL, based on the user name or the list of roles of which a user is a member. System.Web.Security.UrlAuthorizationModule
UrlMappingsModule Supports mapping a real URL to a more user-friendly URL. System.Web.UrlMappingsModule
WindowsAuthentication Sets the identity of the user for an ASP.NET application when Windows authentication is enabled. System.Web.Security.WindowsAuthenticationModule


Request Processing in IIS

In IIS, the IIS and ASP.NET request pipelines combine to process requests with an integrated approach. The new request-processing architecture consists of an ordered list of native and managed modules that perform specific tasks in response to requests.

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.

Application Pools in IIS

Application pools separate applications by process boundaries to prevent an application from affecting another application on the server. In IIS 7 and above, application pools continue to use IIS 6.0 worker process isolation mode. In addition, you can now specify a setting that determines how to process requests that involve managed resources: Integrated mode or Classic mode.

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 and above, 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.

Integrated application pool mode

When an application pool is in Integrated mode, you can take advantage of the integrated request-processing architecture of IIS and ASP.NET. When a worker process in an application pool receives a request, the request passes through an ordered list of events. Each event calls the necessary native and managed modules to process portions of the request and to generate the response.

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.

Classic application pool mode

When an application pool is in Classic mode, IIS 7 and above handles requests in the same way as in IIS 6.0 worker process isolation mode. ASP.NET requests first go through native processing steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the managed runtime. Finally, the request is routed back through IIS to send the response.

This separation of the IIS and ASP.NET request-processing models results in duplication of some processing steps, such as authentication and authorization. Additionally, managed code features, such as Forms authentication, are only available to ASP.NET applications or applications for which you have script mapped all requests to be handled by aspnet_isapi.dll.

Be sure to test your existing applications for compatibility in Integrated mode before upgrading a production environment to IIS 7 and above 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 and above, the process breaks your application.

HTTP Request Processing in IIS

IIS 7 and above have 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




什么是Web Server?


当我们配置一个Web程序时,总会涉及到一个词“Web Server”,它的功能便是会响应所有请求。


IIS(Internet Information Server)是微软Web Server的一种,用来配置ASP.NET站点。IIS拥有自己的ASP.NET处理引擎来处理请求,因此,当一个请求到达时,IIS接收并处理请求,然后返回内容。


现在,你应能搞清楚Web Server和IIS的区别。现在我们来看一下核心部分。在继续之前,你需要搞清两个概念:

1、工作进程(Worker Process)

2、应用程序池(Application Pool)



:当一个应用程序池包含多个工作进程时,被叫做“Web Garden”。

如果我们看一下IIS 6.0的结构,就会发现,可以把它分成两部分:

1、内核模块(Kernel Mode)

2、用户模块(User Mode)

内核模式是从IIS 6.0被引入的,它包含了一个叫HTTP.SYS的文件,每当请求进来时,会首先触发该文件的响应。



在IIS的用户模块中,通过Web Admin Services (WAS)从HTTP.SYS接收请求,并传入相应的应用程序池中。




一旦这个方法被调用,一个HttpContext的实例就产生了。可通过HTTPContent.Current获取到这个实例,且该实例会在整个生命周期中存活,我们通过它可以获取到一些常用对象,如Request,Response,Session 等。








A low-level Look at the ASP.NET Architecture

IIS Architecture