Share via


Request Processing in Worker Process Isolation Mode

Applies To: Windows Server 2003, Windows Server 2003 with SP1

Figure 2.3 shows the standard request process for IIS 6.0 when it is running in worker process isolation mode.

Art Image

The HTTP protocol stack (HTTP.sys), which runs in kernel mode, receives client requests and routes them to the appropriate request queue. Worker processes, which run in user mode, pull the requests directly from their own kernel request queues, eliminating the process hops that occur in IIS 5.0 (and that also occur in IIS 5.0 isolation mode) when the Web server sends a request to a High-isolation, out-of-process application. Because these extra process hops are eliminated in worker process isolation mode, IIS can provide application isolation without sacrificing performance.

Note

Before routing a request to a queue, HTTP.sys checks to see if the response is located in its kernel-mode cache; if a response is cached, it is returned immediately.

To see a visual representation of the request process for the two application isolation modes, compare Figure 2.3 (worker process isolation mode) with Figure 2.6 (High isolation in IIS 5.0 isolation mode).

Note

In Figure2.3, and also in Figure2.4, 2.5, 2.6, and 2.7, the numbered arrows indicate the request process flow.

When HTTP.sys receives requests that are encrypted by using SSL, the kernel-mode HTTP service cannot decrypt the requests or encrypt the responses. Instead, HTTP SSL (HTTPFilter), which is a user-mode service, implements SSL for the HTTP service. In worker process isolation mode, the default host for HTTPFilter is Lsass.exe.

Figure 2.4 illustrates the process flow for an SSL request when IIS 6.0 is running in worker process isolation mode. The HTTP protocol stack receives the SSL request from the client and places it in the SSL queue. The HTTPFilter listens for requests to enter the queue, picks up any new request, uses SSL to decrypt the request, and then returns the decrypted request to HTTP.sys. HTTP.sys then places the decrypted request in the appropriate request queue. A worker process pulls the request directly from its own kernel request queue.

Art Image

On the return trip, the worker process returns the response to HTTP.sys, which places it in the appropriate queue from which the HTTPFilter picks it up and performs SSL encryption. After encryption, the HTTPFilter again returns the response to HTTP.sys, which sends the encrypted response back to the client.

Keep in mind that SSL requires more resources than does standard HTTP. If you use SSL, ensure that the information being sent, such as credit card numbers or medical information, is sensitive enough to justify the added performance expense. For example, your home page or a search results page does not necessarily need to be run through SSL. However, you need to make sure that a checkout or purchase page is SSL-secured.

When you use SSL, the initial connection takes significantly longer than reconnecting. Reconnections use security information in the SSL session cache. The default timeout for the SSL session cache is changed to 5 minutes in Windows 2000 (10 hours in Windows 2000 with Service Pack 2) and 10 hours in Windows Server 2003. After cached data is deleted, the client and server must establish a completely new connection. You can change the default timeout by configuring the ServerCacheTime registry entry. For more information about configuring this registry setting, see Optimizing IIS 6.0 Performance.

Warning

Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first.

For more information about balancing performance and security, see Performance and Security in IIS 6.0 Help. For more information about encryption, see About Encryption in IIS 6.0 Help. For more information about the security features available in IIS 6.0, see Managing a Secure IIS 6.0 Solution.

Table 2.5 provides additional details about how worker process isolation mode processes HTTP (standard) and HTTPS (SSL) requests.

Table 2.5   HTTP and HTTPS Request Processing

Step Request Type Description

I

HTTP & HTTPS

HTTP.sys receives the request from the client and determines the type of request (HTTP or HTTPS). (Corresponds to #1 in Figures 2.3 and 2.4.)

If the request is an HTTPS request, HTTP.sys places it in the SSL queue.

 

HTTPS (SSL) only

For an SSL request, the HTTPFilter performs these steps:

  • Listens for requests to be added to the SSL queue (see #2 in Figure 2.4).

  • Picks up any requests that are queued.

  • Uses SSL to decrypt the request.

  • Returns the decrypted request to HTTP.sys for processing (see #3 in Figure 2.4).

II

HTTP & HTTPS

HTTP.sys determines if the request is valid:

  • If the request is invalid, HTTP.sys sends a 400-class error message for an invalid request back to the client. 1

  • If the request is valid, HTTP.sys checks to see if the response is located in its kernel-mode cache.

III

HTTP & HTTPS

HTTP.sys checks the kernel-mode cache for a response:

  • If the response is in the kernel-mode cache, HTTP.sys returns the response immediately, without transitioning to user mode.

  • If the response is not in the cache, HTTP.sys determines the correct request queue and places the request in that queue.

  • If the target request queue is out of service or if the queue is full, HTTP.sys returns a 503 Service Unavailable message to the client.

IV

HTTP & HTTPS

If no worker process is available and listening in the request queue and if HTTP.sys is able to request that a new worker process be started, HTTP.sys signals the WWW service to start a worker process.

V

HTTP & HTTPS

The worker process pulls the request from the queue and processes the request. (Corresponds to #2 in Figure 2.3 and #4 in Figure 2.4.)

VI

HTTP & HTTPS

The worker process sends the response back to HTTP.sys and instructs HTTP.sys whether to cache the response. (Corresponds to #3 in Figure 2.3 and #5 in Figure 2.4.)

VII

HTTP & HTTPS

HTTP.sys determines the type of response (HTTP or HTTPS).

If the request is an HTTPS response, HTTP.sys places it in the SSL queue.

 

HTTPS (SSL) only

For an SSL response, the HTTPFilter performs the following steps:

  • Listens for responses to enter the SSL queue (see #6 in Figure 2.4).

  • Picks up any responses that enter the queue.

  • Uses SSL to encrypt the response.

  • Returns the encrypted response to HTTP.sys (see #7 in Figure 2.4).

VIII

HTTP & HTTPS

HTTP.sys sends the response back to the client and logs the request if logging is enabled. (Corresponds to #4 in Figure 2.3 and #8 in Figure 2.4.)

For information about 400-class error messages, including keys to the many substatus codes, see Troubleshooting IIS 6.0.