IIS7 中的“经典”和“集成”管道模式有什么区别？答案

【问题标题】：What is the difference between 'classic' and 'integrated' pipeline mode in IIS7?IIS7 中的“经典”和“集成”管道模式有什么区别？
【发布时间】：2010-10-17 11:50:58
【问题描述】：

昨晚我正在部署一个 ASP.NET MVC 应用程序，发现将 IIS7 设置为集成模式进行部署的工作量更少。我的问题是有什么区别？使用其中一种有何影响？

【问题讨论】：

使用集成模式与经典模式相比，部署工作量如何减少？只是好奇
@Peter：无扩展名 URL 需要在经典模式下手动映射。
即使在 MVC Global.asax 中也有注释：有关启用 IIS6 或 IIS7 经典模式的说明，请访问go.microsoft.com/?LinkId=9394801。或者您可以打开集成模式并包含 System.Web.Mvc 程序集，一切正常。

标签： asp.net asp.net-mvc iis iis-7 integrated-pipeline-mode

【解决方案1】：

经典模式（IIS6 及以下的唯一模式）是 IIS 仅直接使用 ISAPI 扩展和 ISAPI 过滤器的模式。实际上，在这种模式下，ASP.NET 只是一个 ISAPI 扩展（aspnet_isapi.dll）和一个 ISAPI 过滤器（aspnet_filter.dll）。 IIS 只是将 ASP.NET 视为在 ISAPI 中实现的外部插件，并像黑匣子一样使用它（仅当它需要向 ASP.NET 发出请求时）。在这种模式下，ASP.NET 与 PHP 或其他 IIS 技术没有太大区别。

另一方面，集成模式是 IIS7 中的一种新模式，其中 IIS 管道与 ASP.NET 请求管道紧密集成（即完全相同）。 ASP.NET 可以看到它想要处理的每个请求并在此过程中进行操作。 ASP.NET 不再被视为外部插件。它完全混合并集成在 IIS 中。在这种模式下，ASP.NET HttpModules 基本上具有与 ISAPI 过滤器一样多的功能，并且 ASP.NET HttpHandlers 可以具有与 ISAPI 扩展几乎相同的功能。在这种模式下，ASP.NET 基本上是 IIS 的一部分。

【讨论】：

集成速度比经典慢？
我不确定说 asp.net 是 IIS 的一部分是否正确。它们看起来像一个单独的（尽管是集成的）产品。我可能是错的。
@MehrdadAfshari 在iis7 中处理HttpModules 方法/事件是否比在iis6 中具有更多功能？你能详细说明一下吗？
并添加，在集成管道模式下，请求管道中的每个阶段都作为事件公开，处理程序的映射可以在应用程序中被覆盖。例如，可以为某种路由定义一个嵌入式资源 HttpHandler，并通过路由处理程序将它们映射到您的自定义处理程序。
此类问题的完美答案，至少应该参考微软的一篇文章，比如iis.net/learn/application-frameworks/…。

【解决方案2】：

集成应用程序池模式

当应用程序池处于集成模式时，您可以利用 IIS 和 ASP.NET 的集成请求处理体系结构。当应用程序池中的工作进程收到请求时，请求通过一个有序的事件列表。每个事件调用必要的本机和托管模块来处理部分请求并生成响应。

在 Integrated 中运行应用程序池有几个好处模式。首先，IIS 和 ASP.NET 的请求处理模型是集成到统一的流程模型中。该模型消除了步骤以前在 IIS 和 ASP.NET 中重复的内容，例如验证。此外，集成模式使可用性所有内容类型的托管功能。

经典应用池模式

当应用程序池处于经典模式时，IIS 7.0 处理请求与 IIS 6.0 工作进程隔离模式一样。 ASP.NET 请求先行通过 IIS 中的本机处理步骤，然后路由到 Aspnet_isapi.dll 用于处理托管中的托管代码运行。最后，请求通过 IIS 路由返回以发送回应。

IIS 和 ASP.NET 请求处理模型的这种分离导致一些处理步骤的重复，例如身份验证和授权。此外，托管代码功能，例如表单身份验证，仅适用于 ASP.NET 您已为其脚本映射所有应用程序或应用程序由 aspnet_isapi.dll 处理的请求。

请务必测试您现有的应用程序的兼容性将生产环境升级到 IIS 7.0 之前的集成模式并以集成模式将应用程序分配给应用程序池。您应该只将应用程序添加到 Classic 中的应用程序池模式，如果应用程序无法在集成模式下工作。例如，您的应用程序可能依赖于从 IIS 传递的身份验证令牌到托管运行时，并且由于 IIS 7.0 中的新体系结构，该过程会破坏您的应用程序。

取自：What is the difference between DefaultAppPool and Classic .NET AppPool in IIS7?

原文来源：Introduction to IIS Architecture

【讨论】：

最后一段中的关键句：“如果应用程序无法在集成模式下工作，您应该只在经典模式下将应用程序添加到应用程序池中。”
@JsonStatham - 原因之一是集成模式无法使用 ASP.NET 模拟（站点 > YourSite > IIS > 身份验证）。如果您有一个 Intranet 站点并且正在使用 Windows 身份验证，那么这是一个重要的考虑因素。 link

【解决方案3】：

IIS 6.0 及以前的版本：

ASP.NET 通过 ISAPI 扩展、C API（基于 C 编程语言的 API）与 IIS 集成，并公开了自己的应用程序和请求处理模型。

这有效地暴露了两个独立的服务器（请求/响应）管道，一个用于本地 ISAPI 过滤器和扩展组件，另一个用于托管应用程序组件。 ASP.NET 组件将完全在 ASP.NET ISAPI 扩展气泡内执行并且仅用于在 IIS 脚本映射配置中映射到 ASP.NET 的请求。

对非 ASP.NET 内容类型的请求：- 图像、文本文件、HTML 页面和无脚本 ASP 页面，由 IIS 或其他 ISAPI 扩展处理，对 ASP.NET 不可见。

此模型的主要限制是 ASP.NET 模块和自定义 ASP.NET 应用程序代码提供的服务不适用于非 ASP.NET 请求

什么是脚本映射？

脚本映射用于将文件扩展名与请求该文件类型时执行的 ISAPI 处理程序相关联。脚本映射还有一个可选设置，在允许处理请求之前验证与请求关联的物理文件是否存在

一个很好的例子可以是seen here

IIS 7 及以上版本

IIS 7.0 及更高版本已从头开始重新设计，以提供全新的基于 C++ API 的 ISAPI。

IIS 7.0 及更高版本将 ASP.NET 运行时与 Web 服务器的核心功能集成在一起，提供了一个统一的（单一）请求处理管道，该管道同时暴露给称为模块 (IHttpModules) 的本机和托管组件

这意味着 IIS 7 处理到达任何内容类型的请求，NON ASP.NET Modules / native IIS modules 和 ASP.NET modules 在所有阶段提供请求处理 这就是为什么 NON ASP.NET 内容类型（.html、静态文件）可以由 .NET 模块处理。

您可以构建能够执行所有应用程序内容的新托管模块 (IHttpModule)，并为您的应用程序提供一组增强的请求处理服务。
添加新的托管处理程序 (IHttpHandler)

【讨论】：

【解决方案4】：

在经典模式下，IIS 直接使用 ISAPI 扩展和 ISAPI 过滤器。并使用两条管道，一条用于本机代码，另一条用于托管代码。您可以简单地说，在经典模式下，IIS 7.x 的工作方式与 IIS 6 一样，并且您不会从 IIS 7.x 功能中获得额外的好处。

在集成模式下，IIS 和 ASP.Net 紧密耦合，而不是像经典模式那样仅依赖于 Asp.net 上的两个 DLL。

【讨论】：