IIS 5 and 6 work differently.
When a request comes, IIS checks the script map (extension map) and routes the request to aspnet_isapi.dll. The operation of this DLL and how requests enter the ASP.NET runtime are different in IIS5 and 6. Figure 2 shows a rough overview of this process.
In IIS5, aspnet_isapi.dll is hosted directly in the inetinfo.exe process. If you set the isolation level of the Web site or virtual directory to medium or high, it will be hosted in a separate (isolated) worker process of IIS. When the first ASP.NET request comes, the DLL (aspnet_isapi.dll) will start another new process aspnet_wp.exe and route the request to this process for processing. This process in turn loads and hosts the .NET runtime. Every request forwarded to the ISAPI DLL is routed to this process via a named pipe call.
Figure 2 - A high-level view of the flow of requests from IIS to the ASP.NET runtime and through the request processing pipeline. IIS5 and IIS6 interact with ASP.NET in different ways, but once the request comes to the ASP.NET pipeline, the entire processing flow is the same.
Unlike previous versions of the server, IIS6 has been fully optimized for ASP.NET.
IIS6 - Long Live Application Pool
IIS6 makes significant changes to the processing model. IIS no longer directly hosts external executable code like ISAPI extensions. IIS always creates a separate worker thread - an application pool - and all processing happens in this process, including the execution of ISAPI dlls. Application pooling is a big improvement in IIS6 because it allows very fine-grained control over what code will be executed in a given thread. Application pools can be configured on each virtual path or on the entire Web site, allowing you to isolate each Web application into its own process so that each application will be connected to other Web applications running on the same machine. Applications are completely isolated. If one process crashes, it won't affect other processes (at least from a web processing point of view).
Not only that, application pools are highly configurable. You can configure the security environment in which pools run by setting their execution impersonation level, which allows you to customize the permissions granted to a web application (again, at a very fine granularity). A big improvement for ASP.NET is that the application pool overrides most of the settings in the ProcessModel section in the machine.config file. The settings in this section are very difficult to manage in IIS5 because these settings are global and cannot be overridden in the application's web.config file. When running IIS6, ProcessModel related settings are mostly ignored and instead read from the application pool. Note that most of them are mentioned here - some settings, such as the size of the thread pool and the settings of the IO thread, are still read from machine.config, because they have no corresponding items in the thread pool settings.
Because application pools are external executables, these executables can be easily monitored and managed. IIS6 provides a series of system status checks, restarts and timeout options, which can be easily used to check and even correct program problems in many cases. Finally, the application pool of IIS6 does not rely on COM+ like the isolation mode of IIS5. This can improve performance and improve stability (especially for some internal applications that need to call COM components).
Although IIS6 Application pools are separate EXEs, but they are highly optimized for HTTP operations. They communicate directly with the kernel-mode HTTP.SYS driver. Received requests are routed directly to the appropriate application pool. InetInfo is basically just a hypervisor and a configuration server - most of the interaction actually happens directly between HTTP.SYS and the application pool, all of which makes IIS6 a more stable and efficient environment than IIS5. This is especially true for static content and ASP.NET applications.
An IIS6 application pool has an innate understanding of ASP.NET. ASP.NET can interact with it at the underlying API. This allows direct access to the HTTP caching API. This allows ASP.NET level caching to be delivered directly to Web server.
In IIS6, ISAPI extensions run in the worker process of the application pool. The .NET runtime also runs in the same process, so the communication between the ISAPI extension and the .NET runtime occurs within the process. This has a natural performance advantage compared to the named pipe used by IIS5. Although the hosting model of IIS is very different, the interface into the managed code is surprisingly similar - only the process of routing messages is slightly different.