IIS7也用了好久了，关于Application Pool Integrate Mode 和 Classic Mode 究竟是什么也是懵懵懂懂，于是下决心去官网看了技术文档，终于恍然大悟，特来分享一下。

IIS从7开始引入了Application Pool，解决了IIS6设置在Server上的问题（因为设置在Server上，因此你不能让两个application跑在两个mode下）。并且增加了模式设置，分别为 Integate Mode 和 Classic Mode。那么这两个模式有什么区别呢，下面我慢慢道来。

首先要先说下IIS的Module，IIS7开始引入了Module，每个Module有各自的功用，Module包含IIS自己携带的，称为Native Module，和外来引入了。而由.NET引入的Module称为Managed Module。如果你仔细查看Native Module和Managed Module，你会发现两者是有重复的，特别是用户认证这里，而如何调用这些Module，就是这两个模式的主要区别。

先说说Integrate Mode。在这个Mode下，当接收一个新的request的时候，request会传送一个有序的事件列表，然后IIS会根据各个事件去调用需要的Native Module 和 Managed Module。就拿用户认证来说吧，如果是一个ASP.NET应用程序，那么IIS会忽略Native Module，而去直接调用Managed Module。这样便提高了处理request的效率，并且保证该应用程序的所有用户认证都被.Net程序管理。

对于Classic Mode，其实和IIS6 中的isolation mode是一样的，一个request来了，IIS先调用Native Module处理，然后如果需要运行托管代码，则调用aspnet_isapi.dll去解析，这时才调用Managed Module。如果你用了Form的认证方式，那么要先经过Native Module的一次认证，然后在调用托管代码的时候再运行一次Managed Module认证，这就重复了两次。此外，如果一个资源不运行托管代码，那么托管代码的认证是不会运行了，以Form方式为例，如果调用一个静态资源，则只会调用IIS的原生认证，而不会使用Form认证。可见Classic Mode在效率和部署配置上不如Integrate Mode好。

总结一下，通过上面不难看出，如果写ASP.NET程序，运行在Integrate Mode是最好的选择。Classic Mode更像是一种向下兼容的模式，如果你的应用在Integrate Mode下有问题，可以切换到该模式下一用。此外，Classic Mode的另外一个应用场景就是原生模块的多样，还拿认证来说，原生的就比.NET的多出不少，如果为了降低开发成本，也可运行在Classic Mode下，当然也要承担上面所说的执行效率和安全问题。

IIS7 Application Pool Integrate Mode 和 Classic Mode 的区别