IIS7应用程序池的托管管道模式和集成模式概述

对IIS 7托管管道模式、经典模式、集成模式的分析和理解。

IIS 7.0支持两种管道模式：一种是IIS 7.0提供的最新集成管道模式，另一种是之前版本的IIS提供的经典管道模式。

我们可以通过应用程序池设置管道模式，这对IIS管理员特别有用，因为它可以使一台服务器只运行一种模式，或者两种模式同时在一台服务器上运行。

以上两种管道模式使用的web.config文件存在显著差异，很多在经典管道模式下可以正常工作的web.config文件在集成管道模式下无法正常工作。使用AppCmd.exe，我们可以自动将经典管道模式下的配置文件格式转换为集成管道模式下的配置文件格式。

我们有必要先看看每种模式的结构，研究两种模式的区别。

1.经典模式。

在IIS 6.0的经典模式中，ASP.NET是添加到IIS中的一个ISAPI。为了向后兼容，IIS 7.0支持此模式。然而，经典模式缺少集成模式可以提供的许多功能。在经典模式下，IIS有自己的管道，可以通过创建ISAPI扩展来扩展管道，ISAPI扩展以难以开发而闻名。作为ISAPI扩展运行，ASP.NET只是IIS管道的一个组件。

下图很好地解释了上述情况。请注意，在这种情况下，ASP.NET似乎是一个类似事后想法的结果，它只能在IIS处理ISAPI扩展时发挥作用。

使用文件扩展名，您可以确定使用哪个ISAPI处理程序。例如，您可以映射带有扩展名的文件。aspx和。ascx到aspnet _ isapi。dll并用扩展名映射文件。asp到asp.dll，让传统的ASP页面可以进行处理。此外，扩展名为。php被映射到php.dll，这样就可以处理PHP页面，前提是安装了php.dll。

此外，在IIS 6.0和IIS 7.0的经典模式中，有些功能是重复的。例如，错误处理是一个重复的特性，因为IIS可以处理non-aspnet页面，而ASP.NET可以处理所有将处理程序映射到aspnet_isapi.dll的页面

在IIS 6.0中，我们可以将所有文件类型映射到ASP.NET，但是这样做有一些限制。最大的限制是如何处理默认文档：默认文档只有在global.asax或HTTP模块中被指定为默认文档才能被处理。一些自定义配置需要aspnet_isapi.dll来处理所有文件类型。IIS 7.0可以轻松解决这个问题。

经典模式可以在不修改web.config的情况下运行现有网站。因此，如果使用的Web场同时包括IIS 6.0服务器和IIS 7.0服务器，或者由于某些原因，web.config文件无法按照新语法转换为web.config文件，则可以使用经典模式。

2.集成模式。

在整合模式下，ASP.NET可以视为IIS的有机组成部分。现在，IIS服务器的功能分为40多个模块，所以IIS和ASP.NET的功能分为不同的组件。静态文件模块、基本身份验证模块、表单身份验证、会话、配置文件和角色管理器等模块都是IIS管道的组件。请注意，表单身份验证、会话、配置文件和角色管理器最初是ASP.NET的一部分，与IIS无关。

下图使用该模块解释了IIS管道。这些模块最初是ASP.NET的一部分，但现在它们是IIS管道的有机组成部分。IIS管道提供了20多种事件，可供开发人员用来扩展Web服务器的功能。实际上，通过创建自定义模块和更新applicationHost.config，我们只能使用自定义模块，而不能使用微软公司提供的内置模块。我们可以用自定义模块替换IIS 7.0中的模块。

3.两种模式的配置差异。

其实总的来说，最大的区别就是在经典模式下处理ASP.NET程序时，需要退出流水线，然后将程序转移到ASP.NET的ISAPI过滤器。在ISAPI处理之后，请求被返回到管道，然后HTTP响应被返回到客户端。但是，集成模式已经将ASP.NET集成到管道中，这意味着无论程序类型如何，ASP.NET程序和non-ASP.NET程序都在管道中处理。并且简化了工作。

补充

IIS 7.0对配置文件做了一些修改，可供Web开发人员使用。例如，system.webServer部分就是这样的修改，可以在经典模式和集成模式下识别。同时，可以在applicationHost.config文件或web.config文件中设置system.webServer部分。system.webServer部分可以控制静态和动态页面。即使在经典模式下，系统。WebServer部分在帮助web开发人员在web.config文件中设置不同的IIS配置方面发挥了重要作用。

在集成模式下，HTTP模块和HTTP处理程序不再在system.web中定义，而是在system.webServer中定义.如果在集成模式下运行包含HTTP模块或HTTP处理程序的web.config文件，将会失败。幸运的是，微软详细指定了一个编号为500.22的错误消息，它展示了如何一步一步地迁移web.config文件。

在IIS 7.5中配置system.webServer节点。

问题

在IIS7.5中配置customErrorerror节点的404页不起作用。

分析

System.web节点是iis7.0之前的主要配置节点，II7.0之后集成了iis管道处理和ASP.NET管道处理，提升了ASP.NET的处理性能。由于程序以IIS7.5集成模式运行，因此需要在system.webServer节点中进行配置。新增加的system.webServer节点需要做哪些修改才能使程序在IIS7集成模式下完全生效，主要包括以下几个方面：

(1)模块-相当于system.web中的httpModules.

(2)Handlers-相当于system.web中的httpHandlers。

(3)自定义错误下的错误相当于system.web中的httpErrors

在以上三点中，如果你的程序有用户定义的httpModules或者httpHandlers，那么第一点和第二点就非常重要了。详情请参考MSDN。

部署

httpErrors error mode=' DetailedLocalOnly ' remove status code=' 404 '/error status code=' 404 ' path='/404 . htm ' response mode=' execute URL '/httpErrors

补充

ErrorMode有三个值，分别是Custom、DetailedLocalOnly和Detailed，这意味着自定义页面始终为用户和服务器显示，详细的错误信息只能为服务器显示，详细的错误信息始终为用户和服务器显示。

responseMode有三层：File、ExecuteUrl和Redirect，分别表示服务器端静态文件、可执行Url和URL转向的使用。

注意：httpErrors不同于customErrors。前者主要用于处理与http相关的错误消息，而后者主要用于处理应用程序级的错误翻页。

自定义错误信息

同样，如果Application_Error和customerErrors同时存在，也存在执行顺序的问题。Application_Error事件customErrors配置项被赋予优先级，因此当发生应用程序级错误时，Application_Error事件中的代码会优先执行。如果服务器。在Application_Error事件中调用ClearError()函数时，customerrers配置部分中的defaultRedirect将不起作用，因为异常已被清除；如果服务器。Application_Error事件中未调用ClearError()函数，错误页面将被重新定位到defaultRedict指定的URL页面，并为用户显示友好的错误消息。

通过分析。NET，我们可以从不同的角度对它们进行分类，方便我们理解和使用。

1.从功能分类：处理异常有Page_Error事件和Application_Error事件；错误页面属性和客户错误配置项用于将用户重定向到错误页面。

2.从错误处理范围分类：Page_Error事件和ErrorPage属性用于页面级错误处理；应用程序错误事件和客户错误配置项用于应用程序级错误处理。

这些ASP.NET模块不仅可以处理ASP.NET网页程序，还可以处理其他程序，如ASP程序、PHP程序或静态HTML页面。因为ASP.NET的很多功能已经成为IIS 7的一部分，对ASP程序、PHP程序或者静态HTML页面等的要求。您还可以使用ASP.NET 2.0的功能，如表单身份验证或输出缓存(但您必须修改IIS 7的设置)。因为IIS 7允许您使用ASP.NET API开发和添加模块，所以ASP.NET的网页开发人员将更容易扩展IIS 7和网站应用程序的功能，甚至编写程序来管理IIS 7。NET(例如，对IIS 7进行编程以构建网站或虚拟目录)。

IIS 7的执行架构图(集成托管通道模式下的架构)总结了从IIS5到IIS6的改进，主要是HTTP.sys的改进.从IIS6到IIS7的改进主要是ISAPI的改进。