Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

IIS 6 Architecture

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 20

IIS 6 Architecture

Overview of IIS Architecture


IIS6.0 provides a redesigned World Wide Web Publishing Service (WWW service) architecture that can help you achieve better performance, reliability, scalability, and security for your Web sites, whether they run on a single server running IIS or on multiple servers. Application isolation is the separation of applications by process boundaries that prevents one application or Web site from affecting another and reduces the time that you spend restarting services to correct problems related to applications.

IIS 6 separates web-server code from application- handling code with a kernelmode HTTP listener, http.sys, and the Web Administration Service (WAS), which is a user-mode configuration and process manager. These programs don't run any third-party code, so they can't be affected by an errant web site. The code is run in a worker process. These worker processes are run by the application w3wp.exe. Each copy of w3wp.exe is another worker process. These worker processes are separate from each other and from the kernel so that they can be isolated from the operating system.

HTTP.Sys
In IIS6.0, application isolation is configured differently for each of the two IIS application isolation modes. Both modes rely on the HTTP protocol stack (also referred to as HTTP.sys) to receive Hypertext Transfer Protocol (HTTP) requests from the Internet and return responses. HTTP.sys resides in kernel mode, where operating system code, such as device drivers, runs.

HTTP.Sys (Contd.)
The new request-processing architecture and application isolation environment enables individual Web applications, which always run in user mode, to function within a self-contained worker process. A worker process is user-mode code whose role is to process requests, such as returning a static page or invoking an Internet Server API (ISAPI) extension or filter. Worker processes use HTTP.sys to receive requests and send responses over HTTP.

IIS6.0 Request Processing Models


Worker process isolation mode is the new IIS request processing model. In this application isolation mode, you can group Web applications into application pools, through which you can apply configuration settings to the worker processes that service those applications. An application pool corresponds to one request routing queue within HTTP.sys and one or more worker processes. Worker process isolation mode enables you to completely separate an application in its own process, with no dependence on a central process such as Inetinfo.exe to load and execute the application. All requests are handled by worker processes that are isolated from the Web server itself. Process boundaries separate each application pool so that when an application is routed to one application pool, applications in other application pools do not affect that application. By using application pools, you can run all application code in an isolated environment

Worker process isolation benefits


Worker process isolation mode delivers all the benefits of the new IIS6.0 architecture, including multiple application pools, health monitoring and recycling, increased security and performance, improved scalability, and processor affinity. For example, the new health monitoring features can help you discover and prevent application failures, and can also help protect your Web server from imperfect applications.

HTTP Protocol Stack (IIS 6.0)


The HTTP listener is implemented as a kernel-mode device driver called the HTTP protocol stack (HTTP.sys). IIS6.0 uses HTTP.sys, which is part of the networking subsystem of the Windows operating system, as a core component. Earlier versions of IIS use Windows Sockets API (Winsock), which is a user-mode component, to receive HTTP requests. By using HTTP.sys to process requests, IIS6.0 delivers the following performance enhancements: Kernel-mode caching. Requests for cached responses are served without switching to usermode. 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.

HTTP Protocol Stack (IIS 6.0) (Contd.)


Using HTTP.sys and the new WWW service architecture provides the following benefits: When a worker process fails, service is not interrupted; the failure is undetectable by the user because the kernel queues the requests while the WWW service starts a new worker process for that application pool. Requests are processed faster because they are routed directly from the kernel to the appropriate user-mode worker process instead of being routed between two usermode processes.

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 IIS6.0: Routing HTTP requests to the correct request queue. Caching of responses in kernel mode. Performing all text-based logging for the WWW service.

ISAPI Extensions
An ISAPI server extension is a DLL that can be loaded and called by an HTTP server. Internet server extensions, also known as Internet server applications (ISAs), are used to enhance the capabilities of an Internet Server API (ISAPI)-compliant server. An ISA is invoked from a browser application and provides similar functionality to a Common Gateway Interface (CGI) application.

ISAPI Filter
An ISAPI filter is a DLL that runs on an ISAPIenabled HTTP server to filter data traveling to and from the server. The filter registers for notification of events, such as logging on or URL mapping. When the selected events occur, the filter is called, and you can monitor and change the data (on its way from the server to the client or vice versa). ISAPI filters can be used to provide enhanced logging of HTTP requests (for example, to track who is logging on to your server), custom encryption, custom compression, or additional authentication methods.

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. 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 (IIS 6.0)


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.

Application Pools
Application pools allow code to be run in an isolated environment. Each application pool is serviced by one or more worker process. When IIS starts, the Web Administration Service initializes the http.sys namespace routing table with one entry for each application. This routing table determines to which application pool an application should be routed. When http.sys receives a request, it asks WAS to start up one or more worker processes to handle that application pool. This isolation of processes makes the web server as a whole more stable.

How Application Pools Work (IIS 6.0)


When you run IIS6.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.

How Application Pools Work (IIS 6.0)


Use multiple application pools when you want to help ensure that applications and Web sites are confidential and secure. For example, an enterprise organization might place its human resources Web site and its finance Web site on the same server, but in different application pools. Likewise, an ISP that hosts Web sites and applications for competing companies might run each companys Web services on the same server, but in different application pools. Using different application pools to isolate applications helps prevent one customer from accessing, changing, or using confidential information from another customers site. In HTTP.sys, an application pool is represented by a request queue, from which the user-mode worker processes that service an 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

Web Gardens
Multiple worker processes can be set up to handle a single application pool. This is called a web garden. Web gardens allow for better multiprocessor scalability, since each worker process can have an affinity for a single processor, to increase the cache hits on that processor. If one worker process gets bogged down, the other ones can take up the slack. It also reduces the need to reboot the server, even when upgrading components, because the application pool can merely be restarted. The number of requests that should be queued for each application pool can be set in http.sys when running in worker process isolation mode. When this limit is reached, new requests to the full application pool are not processed, and the user gets an HTTP 503 error.

You might also like