web-dev-qa-db-ja.com

IIS 7の 'クラシック'パイプラインモードと '統合'パイプラインモードの違いは何ですか？

私は昨夜、ASP.NET MVCアプリケーションをデプロイしていましたが、IIS 7を統合モードに設定してデプロイするのは面倒でないことがわかりました。私の質問は違いは何ですか？そして、どちらか一方を使うことの意味は何ですか？

asp.netasp.net-mvciisiis-7integrated-pipeline-mode
476
Jon Erickson

クラシックモード（IIS 6以降で唯一のモード）は、IISがISAPI拡張機能およびISAPIフィルタでのみ直接機能するモードです。実際、このモードでは、ASP.NETは単なるISAPI拡張機能（aspnet_isapi.dll）とISAPIフィルタ（aspnet_filter.dll）です。 IISは、ASP.NETをISAPIで実装された外部プラグインとして扱い、ブラックボックスのように機能します（ASP.NETに要求を出す必要がある場合のみ）。このモードでは、ASP.NETはPHPやIISの他のテクノロジと大差ありません。

一方、統合モードはIIS 7の新しいモードで、IISパイプラインはASP.NET要求パイプラインと緊密に統合されています（つまり、まったく同じです）。 ASP.NETは、それが望んでいるすべての要求を見て、その過程でものを操作することができます。 ASP.NETは、外部プラグインとして扱われなくなりました。それは完全に混合され、IISに統合されています。このモードでは、ASP.NETのHttpModulesは基本的にISAPIフィルタとほぼ同等の機能を持ち、ASP.NETのHttpHandlersはISAPI拡張機能とほぼ同等の機能を持つことができます。このモードでは、ASP.NETは基本的にIISの一部です。

630
Mehrdad Afshari

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

アプリケーションプールが統合モードの場合は、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の新しいアーキテクチャにより、プロセスがアプリケーションを中断します。

撮影元： IIS 7におけるDefaultAppPoolとClassic .NET AppPoolの違いは何ですか？

元の情報源： IIS Architectureの紹介

110
BrainCoder

IIS 6.0以前のバージョン：

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

これにより、ネイティブISAPIフィルタと拡張コンポーネント用、および管理対象アプリケーションコンポーネント用の2つの別々のサーバー（要求/応答）パイプラインが効果的に公開されました。 ASP.NETコンポーネントは、IISスクリプトマップ設定でASP.NETにマップされた要求に対して、完全にASP.NET ISAPI拡張バブルAND ONLYの内側で実行されます。

ASP.NET以外のコンテンツタイプへの要求： - 画像、テキストファイル、HTMLページ、およびスクリプトのないASPページは、IISまたは他のISAPI拡張機能によって処理され、表示されませんでした。 ASP.NET.

このモデルの主な制限は、ASP.NETモジュールおよびカスタムASP.NETアプリケーションコードによって提供されるサービスが、ASP.NET以外の要求で利用できないことでした

SCRIPT MAPとは何ですか？

スクリプトマップは、ファイル拡張子を、そのファイルタイプが要求されたときに実行される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の両方で、あらゆるコンテンツタイプに到着するリクエストを処理します。これが、ASP.NET以外のコンテンツタイプ（.html、静的ファイル）を.NETモジュールで処理できる理由です。

  • すべてのアプリケーションコンテンツに対して実行する機能を持つ新しいマネージモジュール（ IHttpModule ）を作成できますそしてあなたのアプリケーションにリクエスト処理サービスの強化されたセットを提供しました。
  • 新しい管理対象ハンドラを追加する（ IHttpHandler ）
11
R.C

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

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

5
Mian