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.
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.
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:
|
II |
HTTP & HTTPS |
HTTP.sys determines if the request is valid:
|
III |
HTTP & HTTPS |
HTTP.sys checks the kernel-mode cache for a response:
|
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:
|
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.