Next>>
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.
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.
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.
How Application Pools Work (IIS 6.0)
When you run IIS 6.0 in worker process isolation mode, you can separate different Web applications and Web sites into groups known as application pools. An application pool is a group of one or more URLs that are served by a worker process or set of worker processes. Any Web directory or virtual directory can be assigned to an application pool.
Every application within an application pool shares the same worker process. Because each worker process operates as a separate instance of the worker process executable, W3wp.exe, the worker process that services one application pool is separated from the worker process that services another. Each separate worker process provides a process boundary so that when an application is assigned to one application pool, problems in other application pools do not affect the application. This ensures that if a worker process fails, it does not affect the applications running in other application pools.
In HTTP.sys, an application pool is represented by a request queue, from which the w3wp processes the requests as application pool collect the requests. Each pool can manage requests for one or more unique Web applications, which you assign to the application pool based on their URLs. Application pools, then, are essentially worker process configurations that service groups of namespaces.
Multiple application pools can operate at the same time. An application, as defined by its URL, can only be served by one application pool at any time. While one application pool is servicing a request, you cannot route the request to another application pool. However, you can assign applications to another application pool while the server is running.
Pasted from <http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/67e39bd8-317e-4cf6-b675-6431d4425248.mspx>
Worker Processes (IIS 6.0)
A worker process is user-mode code whose role is to process requests, such as processing requests to return a static page, invoking an ISAPI extension or filter, or running a Common Gateway Interface (CGI) handler.
In both application isolation modes, the worker process is controlled by the WWW service. However, in worker process isolation mode, a worker process runs as an executable file named W3wp.exe.
Worker processes use HTTP.sys to receive requests and to send responses by using HTTP. Worker processes also run application code, such as ASP.NET applications and XML Web services. You can configure IIS to run multiple worker processes that serve different application pools concurrently. This design separates applications by process boundaries and helps achieve maximum Web server reliability.
By default, worker processes in worker process isolation mode run under the Network Service account, which has the strongest security (least access) compatible with the functionality that is required.
Pasted from <http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/29f53968-0115-451f-b26d-5ad58d87b5d1.mspx>
How HTTP.sys Works
When you create a Web site, IIS registers the site with HTTP.sys, which then receives any HTTP requests for the site. HTTP.sys functions like a forwarder, sending the Web requests it receives to the request queue for the user-mode process that runs the Web site or Web application. HTTP.sys also sends responses back to the client.
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. As a result, bugs in application-specific code cannot affect the kernel or lead to system failures.
HTTP.sys provides the following services in IIS 6.0:
| |
| |
| |
| |
How HTTP.sys Handles Kernel-Mode Queuing
When IIS 6.0 runs in worker process isolation mode, HTTP.sys listens for requests and queues those requests in the appropriate queue. 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 defective application causes the user-mode worker process to terminate unexpectedly, HTTP.sys continues to accept and queue requests, provided that the WWW service is still running, queues are still available, and space remains in the queues.
When the WWW service identifies an unhealthy worker process, it starts a new worker process if outstanding requests are waiting to be serviced. Thus, although a temporary disruption occurs in user-mode request processing, an end user does not experience the failure because TCP/IP connections are maintained, and requests continue to be queued and processed.
Pasted from <http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a2a45c42-38bc-464c-a097-d7a202092a54.mspx>
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.
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.
When you start a server that is running IIS, and the WWW service is started, this service reads metabase information and initializes the HTTP.sys namespace routing table with one entry for each application. HTTP.sys then uses the routing table data to determine which application pool responds to requests from what parts of the namespace. When HTTP.sys receives a request, it signals the WWW service to start a worker process for the application pool.
When you add or delete an application pool, the WWW service processes the configuration changes, which includes adding or deleting the application pool queue from HTTP.sys. The WWW service also listens for and processes configuration changes that occur as a result of application pool recycling.
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 7.0
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.
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.
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
|
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:
- When a client browser initiates an HTTP request for a resource on the Web server, HTTP.sys intercepts the request.
- HTTP.sys contacts WAS to obtain information from the configuration store.
- WAS requests configuration information from the configuration store, applicationHost.config.
- The WWW Service receives configuration information, such as application pool and site configuration.
- The WWW Service uses the configuration information to configure HTTP.sys.
- WAS starts a worker process for the application pool to which the request was made.
- The worker process processes the request and returns a response to HTTP.sys.
- 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
No comments:
Post a Comment