IIS 5 和6以不同的方式工作

　　当一个请求来到时，IIS检查脚本映射(扩展名映射)然后把请求路由到aspnet_isapi.dll。这个DLL的操作和请求如何进入ASP.NET运行时在IIS5和6中是不同的。图2显示了这个流程的一个粗略概览。

　　在IIS5中，aspnet_isapi.dll直接寄宿在inetinfo.exe进程中，如果你设置了Web站点或虚拟目录的隔离度为中或高，则会寄宿在IIS单独的(被隔离的)工作进程中。当第一个ASP.NET请求来到，DLL(aspnet_isapi.dll)会开始另一个新进程aspnet_wp.exe并将请求路由到这个进程中来进行处理。这个进程依次加载并寄宿.NET运行时。每个转发到ISAPI DLL的请求都会通过命名管道调用被路由到这个进程来。

　　图2-从较高层次来看请求从IIS到ASP.NET运行时，并通过请求处理管道的流程。IIS5和IIS6通过不同的方式与ASP.NET交互，但是一旦请求来到ASP.NET管道，整个处理流程就是一样的了。

　　不同于以前版本的服务器，IIS6为ASP.NET做了全面的优化。

　　IIS6-应用程序池万岁

　　IIS6对处理模型做了意义重大的改变，IIS不再直接寄宿象ISAPI扩展这样的外部可执行代码。IIS总是创建一个独立的工作线程-一个应用程序池-所有的处理都发生在这个进程中，包括ISAPI dll的执行。应用程序池是IIS6的一个很大的改进，因为它允许对指定线程中将会执行什么代码进行非常细粒度的控制。应用程序池可以在每个虚拟路径上或者整个Web站点上进行配置，这样你可以将每个Web应用隔离到它们自己的进程中，这样每个应用都将和其他运行在同一台机器上的Web应用完全隔离。如果一个进程崩溃了，不会影响到其他进程(至少在Web处理的观点上来看是如此)。

　　不止如此，应用程序池还是高度可配置的。你可以通过设置池的执行扮演级别(execution impersonation level )来配置它们的运行安全环境，这使你可以定制赋予一个Web应用的权限(同样，粒度非常的细)。对于ASP.NET的一个大的改进是，应用程序池覆盖了在machine.config文件中大部分的ProcessModel节的设置。这一节的设置在IIS5中非常的难以管理，因为这些设置是全局的而且不能在应用程序的web.config文件中被覆盖。当运行IIS6是，ProcessModel相关的设置大部分都被忽略了，取而代之的是从应用程序池中读取。注意这里说的是大部分-有些设置，如线程池的大小还有IO线程的设置还是从machine.config中读取，因为它们在线程池的设置中没有对应项。

　　因为应用程序池是外部的可执行程序，这些可执行程序可以很容易的被监控和管理。IIS6提供了一系列的进行系统状况检查，重启和超时的选项，可以很方便的用来检查甚至在许多情况下可以修正程序的问题。最后IIS6的应用程序池并不像IIS5的隔离模式那样依赖于COM+，这样做一来可以提高性能，二来提高了稳定性(特别对某些内部需要调用COM组件的应用来说)

　　尽管IIS6的应用程序池是单独的EXE，但是它们对HTTP操作进行了高度的优化，它们直接和内核模式下的HTTP.SYS驱动程序进行通讯。收到的请求被直接路由给适当的应用程序池。InetInfo基本上只是一个管理程序和一个配置服务程序-大部分的交互实际上是直接在HTTP.SYS和应用程序池之间发生，所有这些使IIS6成为了比IIS5更加的稳定和高效的环境。特别对静态内容和ASP.NET程序来说这是千真万确的。

　　一个IIS6应用程序池对于ASP.NET有着天生的认识，ASP.NET可以在底层的API上和它进行交互，这允许直接访问HTTP缓存API，这样做可以将ASP.NET级别的缓存直接下发到Web服务器。

　　在IIS6中，ISAPI扩展在应用程序池的工作进程中运行。.NET运行时也在同一个进程中运行，所以ISAPI扩展和.NET运行时的通讯是发生在进程内的，这样做相比IIS5使用的命名管道有着天生的性能优势。虽然IIS的寄宿模型有着非常大的区别，进入托管代码的接口却异常的相似-只有路由消息的过程有一点区别。