IIS7的应用程序池详细解析

在 IIS 7 中，应用程序池有两种运行模式：集成模式和经典模式。应用程序池模式会影响服务器处理托管代码请求的方式

在IIS 7中，添加一个应用程序或者单独的网站，默认会自动新建一个对应的“应用程序池”，这也是IIS 7的一大特色。

在早期的IIS 5.0中，只有一个应用程序池的情况下，很容易造成“全军覆没，一荣俱损”。因为所有的网站（或者虚拟目录下的应用程序）都“寄居”在一个“池”，当这个“池”崩溃了，所有的网站都杯具了。

后来的IIS 6中，有了“应用程序池”的概念，但是默认不会自动添加，IIS 管理员可以手动去添加，配置，这样是的IIS 具有很强的隔离性。

应用程序池具有下列优点：

改进的服务器和应用程序性能。对于占用大量资源的应用程序，您可以将其分配给它们自己的应用程序池，以免影响其他应用程序的性能。

改进的应用程序可用性。如果一个应用程序池中的应用程序发生故障，将不会影响其他应用程序池中的应用程序。

改进的安全性。通过隔离应用程序，可以降低一个应用程序访问其他应用程序资源的几率。

截取微软官方一篇文章的图，介绍IIS7集成管道下的事件生命周期如下：
该生命周期可以看出，集成模式下不管托管代码还是本机代码，都可以在身份验证和执行处理程序被插入到内核代码的托管代码拦截。在IIS6下，要想拦截本机代码，比如Htm文件，需要编写WIN32的非托管代码，但它也保留扩展的ISAPI，我们可以写托管代码拦截托管文件的请求。虽然IIS6也可以通过IIS插入ISAPI为aspnet_isapi.dll的扩展，处理对htm文件的拦截，但它实际会走两个通道，首先是IIS内部的本机代码拦截，然后是托管代码ISAPI的拦截。经典模式就是为了保留和IIS6一样的处理方式，以前开发的代码，可以方便的移植到IIS7上。

IIS7集成模式还增加了MapRequestHandler、LogRequest 和 PostLogRequest 事件，如果在经典模式下加了这些处理事件，会抛出：此操作要求使用 IIS 集成管线模式。如果集成模式下不让IIS处理不兼容集成模式的配置以及处理方式，可以在web.config中配置：
实际上IIS7集成模式，就是让用户可以通过编写托管代码的handler等，把托管代码插入到IIS内核代码中来解析，方便大家精确控制任意请求，带来更好的扩展性。但缺点呢，我认为集成模式，任何文件请求都可能经过托管代码处理，别人不想把类试图片和静态文件用托管代码处理，就得想其他办法了，这样会不会内部效率降低，但这都是个人观点。

在集成模式中，HTTP模块和HTTP处理程序不再定义于<system.web>中，而定义于<system.webServer>中。如果在集成模式中运行一个包括了HTTP模块或HTTP处理程序的web.config文件，那么将会发生失效。

因为集成模式下，要想运行HTTP处理程序，必须在配置文件中添加一个<system.webServer><handlers>节点代替经典模式下的<system.web><httpHandlers>节点。进行这种转换后，程序HTTP处理程序成功执行。

具体的转换方式如下：

在经典模式中，HTTP处理程序注册方式是添加一个<system.web><httpHandlers>节点，如图：
在集成模式中，HTTP处理程序注册方式是添加一个<system.webServer><handlers>节点：
5

另外应用程序池的集成模式，不能设置模拟，要在web.config里面干掉这段

<configuration> <system.web> <identity impersonate="true"/> </system.web> </configuration>
6

在 IIS 7 中，应用程序池有两种运行模式：集成模式和经典模式。应用程序池模式会影响服务器处理托管代码请求的方式。如果托管应用程序在采用集成模式的应用程序池中运行，服务器将使用 IIS 和 ASP.NET 的集成请求处理管道来处理请求。但是，如果托管应用程序在采用经典模式的应用程序池中运行，服务器会继续通过 Aspnet_isapi.dll 路由托管代码请求，其处理请求的方式就像应用程序在 IIS 6.0 中运行一样。