IIS7の「クラシック」と「統合」パイプラインモードの違いは何ですか？

私は昨夜ASP.NET MVCアプリケーションを展開していましたが、IIS7を統合モードに設定して展開する方が作業が少ないことがわかりました。私の質問は違いは何ですか？そして、どちらか一方を使用することの意味は何ですか？

クラシックモード（IIS6以下の唯一のモード）は、IISがISAPI拡張とISAPIフィルターのみを直接操作するモードです。実際、このモードでは、ASP.NETはISAPI拡張（aspnet_isapi.dll）とISAPIフィルター（aspnet_filter.dll）にすぎません。IISは、ASP.NETをISAPIに実装された外部プラグインとして扱い、ブラックボックスのように動作します（ASP.NETにリクエストを送信する必要がある場合のみ）。このモードでは、ASP.NETは、IISのPHPまたは他のテクノロジと大差ありません。

一方、統合モードはIIS7の新しいモードで、IISパイプラインはASP.NETリクエストパイプラインと緊密に統合されています（つまり、まったく同じです）。ASP.NETは、必要なすべての要求を確認し、途中で物事を操作できます。ASP.NETは、外部プラグインとして扱われなくなりました。それは完全にブレンドされ、IISに統合されています。このモードでは、ASP.NETはHttpModule基本的にISAPIフィルターが持っていたのとほぼ同じくらいの能力を持ち、ASP.NET HttpHandlerはISAPI拡張と同じくらいの機能を持つことができます。このモードでは、ASP.NETは基本的にIISの一部です。

統合アプリケーションプールモード

アプリケーションプールが統合モードの場合、IISとASP.NETの統合された要求処理アーキテクチャを利用できます。アプリケーションプールのワーカープロセスが要求を受け取ると、要求はイベントの順序付けられたリストを通過します。各イベントは、必要なネイティブモジュールとマネージモジュールを呼び出して、要求の一部を処理し、応答を生成します。

統合モードでアプリケーションプールを実行することには、いくつかの利点があります。まず、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にアップグレードし、アプリケーションを統合モードのアプリケーションプールに割り当てる前に、統合モードで既存のアプリケーションの互換性をテストしてください。アプリケーションが統合モードで機能しない場合にのみ、アプリケーションをクラシックモードのアプリケーションプールに追加する必要があります。たとえば、アプリケーションがIISからマネージランタイムに渡された認証トークンに依存している場合、IIS 7.0の新しいアーキテクチャにより、プロセスはアプリケーションを破壊します。

参考資料：IIS7のDefaultAppPoolとClassic .NET AppPoolの違いは何ですか？

元のソース：IISアーキテクチャの概要

IIS 6.0以前のバージョン：

ASP.NETは、ISAPI拡張、C API（Cプログラミング言語ベースのAPI）を介してIISと統合され、独自のアプリケーションと要求処理モデルを公開しました。

これにより、2つの別個のサーバー（要求/応答）パイプラインが実質的に公開されました。1つはネイティブISAPIフィルターと拡張コンポーネント用で、もう1つはマネージアプリケーションコンポーネント用です。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 modulesASP.NET modules は、すべての段階で要求の処理を提供し、すべてのコンテンツタイプに対して到着した要求をIIS 7で処理します。これが、非ASP.NETコンテンツタイプ（.html、静的ファイル）を.NETモジュールで処理できる理由です。 。

• IHttpModuleすべてのアプリケーションコンテンツに対して実行できる新しいマネージモジュール（）を構築し、アプリケーションに要求処理サービスの拡張セットを提供できます。
• 新しいマネージハンドラーを追加（IHttpHandler）

クラシックモードでは、IISはISAPI拡張とISAPIフィルターを直接機能させます。また、2つのパイプラインを使用します。1つはネイティブコード用、もう1つはマネージコード用です。クラシックモードでは、IIS 7.xはIIS 6と同じように機能し、IIS 7.xの機能から余分なメリットを得ることはできません。

統合モードでは、IISとASP.Netは、クラシックモードの場合のようにAsp.net上の2つのDLLに依存するのではなく、緊密に結合されます。