IIS7 Application Pool Integrate Mode 和 Classic Mode 的区别

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下，固然也要承担上面所说的执行效率和安全问题。