IIS 5 と 6 の動作は異なります。
要求が届くと、IIS はスクリプト マップ (拡張子マップ) を確認し、要求を aspnet_isapi.dll にルーティングします。この DLL の操作と、要求が ASP.NET ランタイムに入る方法は、IIS5 と 6 では異なります。図 2 に、このプロセスの大まかな概要を示します。
IIS5 では、aspnet_isapi.dll は inetinfo.exe プロセス内で直接ホストされます。Web サイトまたは仮想ディレクトリの分離レベルを中または高に設定すると、aspnet_isapi.dll は IIS の別の (分離された) ワーカー プロセスでホストされます。最初の ASP.NET 要求が到着すると、DLL (aspnet_isapi.dll) は別の新しいプロセス aspnet_wp.exe を開始し、要求を処理のためにこのプロセスにルーティングします。このプロセスは、.NET ランタイムをロードしてホストします。 ISAPI DLL に転送されるすべてのリクエストは、名前付きパイプ呼び出しを介してこのプロセスにルーティングされます。
図 2 - IIS から ASP.NET ランタイムへ、および要求処理パイプラインを通る要求のフローの概要。 IIS5 と IIS6 は異なる方法で ASP.NET と対話しますが、要求が ASP.NET パイプラインに到達すると、全体の処理フローは同じになります。
以前のバージョンのサーバーとは異なり、IIS6 は ASP.NET 用に完全に最適化されています。
IIS6 - Long Live Application Pool
IIS6 では、処理モデルに大幅な変更が加えられ、IIS は ISAPI 拡張機能のような外部実行可能コードを直接ホストしなくなりました。 IIS は常に別のワーカー スレッド (アプリケーション プール) を作成し、ISAPI DLL の実行を含むすべての処理がこのプロセスで行われます。アプリケーション プーリングは、特定のスレッドで実行されるコードを非常にきめ細かく制御できるため、IIS6 では大幅に改善されました。アプリケーション プールは各仮想パス上または Web サイト全体上で構成でき、各 Web アプリケーションを独自のプロセスに分離できるため、各アプリケーションは同じマシン上で実行されている他の Web アプリケーションに接続されます。 1 つのプロセスがクラッシュしても、他のプロセスには影響しません (少なくとも Web 処理の観点からは)。
それだけでなく、アプリケーション プールは高度に構成可能です。プールの実行偽装レベルを設定することで、プールが実行されるセキュリティ環境を構成できます。これにより、Web アプリケーションに付与されるアクセス許可を (やはり非常に細かい粒度で) カスタマイズできます。 ASP.NET の大きな改善点は、アプリケーション プールが machine.config ファイルの ProcessModel セクションの設定のほとんどをオーバーライドすることです。このセクションの設定はグローバルであり、アプリケーションの web.config ファイルでオーバーライドできないため、IIS5 では管理が非常に困難です。 IIS6 を実行している場合、ProcessModel 関連の設定はほとんど無視され、代わりにアプリケーション プールから読み取られます。それらのほとんどはここで説明されていることに注意してください。スレッド プールのサイズや IO スレッドの設定などの一部の設定は、スレッド プール設定に対応する項目がないため、依然として machine.config から読み取られます。
アプリケーション プールは外部実行可能ファイルであるため、これらの実行可能ファイルは簡単に監視および管理できます。 IIS6 には、一連のシステム ステータス チェック、再起動、およびタイムアウト オプションが用意されており、多くの場合、これらを簡単にチェックしてプログラムの問題を修正するために使用できます。最後に、IIS6 のアプリケーション プールは、IIS5 の分離モードとは異なり、COM+ に依存しません。これにより、パフォーマンスが向上し、安定性が向上します (特に、COM コンポーネントを呼び出す必要がある一部の内部アプリケーションの場合)
。 HTTP 操作用に高度に最適化されており、カーネル モードの HTTP.SYS ドライバーと直接通信します。受信したリクエストは、適切なアプリケーション プールに直接ルーティングされます。 InetInfo は基本的にハイパーバイザーと構成サーバーにすぎません。対話のほとんどは実際には HTTP.SYS とアプリケーション プールの間で直接行われ、そのすべてが IIS6 を IIS5 よりも安定した効率的な環境にしています。これは、静的コンテンツと ASP.NET アプリケーションに特に当てはまります。
IIS6 アプリケーション プールは ASP.NET を本質的に理解しており、ASP.NET は基礎となる API で対話できるため、ASP.NET レベルのキャッシュを Web サーバーに直接配信できます。
IIS6 では、ISAPI 拡張機能はアプリケーション プールのワーカー プロセスで実行されます。 .NET ランタイムも同じプロセス内で実行されるため、ISAPI 拡張機能と .NET ランタイム間の通信はプロセス内で行われます。これには、IIS5 で使用される名前付きパイプと比較して、当然ながらパフォーマンス上の利点があります。 IIS のホスティング モデルは大きく異なりますが、マネージ コードへのインターフェイスは驚くほど似ており、メッセージのルーティング プロセスがわずかに異なるだけです。