IIS 7.0 アーキテクチャの概要
公開日: 2007 年 11 月 16 日 (作業者: pharr (英語))
更新日: 2009 年 9 月 9 日 (作業者: pharr (英語))
はじめに
インターネット インフォメーション サービス (IIS) 7.0 には、次のような機能を持つ新しい要求処理アーキテクチャが用意されています。
- HTTP や HTTPS 以外のプロトコルをサイトで使用できる新しい Windows プロセス アクティブ化サービス (WAS)
- モジュールの追加や削除によるカスタマイズが可能な Web サーバー エンジン
- IIS および ASP.NET からの要求処理パイプラインを統合した、要求処理への新しいアプローチ
この記事では、以下のセクションでコンポーネント、モジュール、および要求処理アーキテクチャについて説明します。
- IIS 7.0 のコンポーネント
- プロトコル リスナー
- ハイパーテキスト転送プロトコル スタック (HTTP.sys)
- World Wide Web 発行サービス (WWW サービス)
- Windows プロセス アクティブ化サービス (WAS)
- IIS 7.0 のモジュール
- ネイティブ モジュール
- マネージ モジュール
- IIS 7.0 の要求処理
- IIS 7.0 のアプリケーション プール
- IIS 7.0 での HTTP 要求処理
IIS 7.0 のコンポーネント
IIS 7.0 には、Windows Server® 2008 でアプリケーション サーバーおよび Web サーバーの役割の重要な機能を実行するコンポーネントがいくつか含まれています。 各コンポーネントは、サーバーに対して行われた要求のリスニング、プロセスの管理、構成ファイルの読み込みなどの処理を実行します。 これらのコンポーネントには、HTTP.sys などのプロトコル リスナーと、World Wide Web 発行サービス (WWW サービス) や Windows プロセス アクティブ化サービス (WAS) などのサービスが含まれます。
プロトコル リスナー
プロトコル リスナーは、プロトコル固有の要求を受信し、要求を IIS に送信し (IIS が処理を行います)、応答を要求元に返します。 たとえば、クライアント ブラウザーがインターネットから Web ページを要求すると、HTTP リスナーである HTTP.sys が要求を受け取り、処理のために IIS に送信します。 IIS が要求を処理すると、HTTP.sys は応答をクライアント ブラウザーに返します。
既定では、IIS 7.0 には、HTTP 要求および HTTPS 要求をリッスンするプロトコル リスナーとして HTTP.sys が用意されています。 HTTP.sys は、HTTP 要求を処理する HTTP 専用のプロトコル リスナーとして IIS 6.0 で導入されました。 IIS 7.0 でも HTTP リスナーとして HTTP.sys が用意されていますが、SSL (Secure Sockets Layer) もサポートしています。
HTTP や HTTPS 以外のプロトコルを使用するサービスやアプリケーションをサポートするには、Windows Communication Foundation (WCF) などのテクノロジを使用できます。 WCF には、プロトコル リスナーとリスナー アダプターの両方の機能を持つリスナー アダプターが用意されています。 リスナー アダプターについては、後ほど説明します。 WCF の詳細については、MSDN の「Windows Communication Foundation」を参照してください。
ハイパーテキスト転送プロトコル スタック (HTTP.sys)
HTTP リスナーは Windows オペレーティング システムのネットワーク サブシステムの一部であり、HTTP プロトコル スタック (HTTP.sys) と呼ばれるカーネルモード デバイス ドライバーとして実装されています。 HTTP.sys はネットワークからの HTTP 要求をリッスンし、処理のために要求を IIS に渡し、処理された応答をクライアント ブラウザーに返します。
IIS 6.0 では、Windows ソケット API (Winsock) に代わる機能として HTTP.sys が導入されました。IIS 6.0 以前のバージョンでは、HTTP 要求の受信および HTTP 応答の送信を行うユーザーモード コンポーネントとして Windows ソケット API が使用されていました。 IIS 7.0 でも、HTTP 要求の処理に HTTP.sys を使用します。
HTTP.sys には次のようなメリットがあります。
- カーネル モード キャッシュ。 要求に対する応答をキャッシュして、後続の要求をユーザー モードに切り替えることなく処理できます。
- カーネルモードの要求キュー。 要求はカーネルにより適切なワーカー プロセスに直接転送されるので、コンテキスト切り替えのオーバーヘッドが減少します。 要求を受け付けて処理できるワーカー プロセスが見つからない場合、要求は、ワーカー プロセスが受け付けるまで、カーネルモードの要求キューに保持されます。
- 要求の前処理およびセキュリティ フィルタリング。
World Wide Web 発行サービス (WWW サービス)
IIS 7.0 では、以前は World Wide Web 発行サービス (WWW サービス) でのみ処理されていた機能が、WWW サービスと新しい Windows プロセス アクティブ化サービス (WAS) の 2 つのサービスに分割されています。 この 2 つのサービスは同じ Svchost.exe プロセスで LocalSystem として実行され、同じバイナリを共有します。
注 ドキュメントによっては、WWW サービスは W3SVC と呼ばれることもあります。
IIS 6.0 での WWW サービスの動作
IIS 6.0 では、WWW サービスによって、次のような IIS の主要機能を管理しています。
- HTTP の管理および構成
- プロセス管理
- パフォーマンス監視
HTTP の管理および構成
IIS メタベースから構成情報を読み取り、その情報を使用して HTTP リスナー HTTP.sys の構成および更新を行います。また、HTTP 要求を処理するワーカー プロセスの起動、終了、監視、管理を行います。
パフォーマンス監視
パフォーマンスを監視し、Web サイトや IIS キャッシュのパフォーマンス カウンターを提供します。
プロセス管理
アプリケーション プールとワーカー プロセス (ワーカー プロセスの起動、終了、リサイクルなど) を管理します。 さらに、ワーカー プロセスの状態を監視し、構成された時間内に複数のワーカー プロセスがエラーになった場合は、ラピッド フェール保護を呼び出して新しいプロセスが起動されるのを防止します。
IIS 7.0 での WWW サービスの動作
IIS 7.0 では、WWW サービスはワーカー プロセスの管理を行わなず、 HTTP リスナー (HTTP.sys) のリスナー アダプターとして機能します。 WWW サービスは、リスナー アダプターとして、主に HTTP.sys の構成、構成の変更時の HTTP.sys の更新、および要求が要求キューに置かれたときの WAS への通知を行います。
さらに、WWW サービスでは、引き続き Web サイト用のカウンターが収集されます。 パフォーマンス カウンターは WWW サービスに含まれるため、HTTP に固有であり、WAS には適用されません。
Windows プロセス アクティブ化サービス (WAS)
IIS 7.0 では、Windows プロセス アクティブ化サービス (WAS) によって、アプリケーション プールの構成およびワーカー プロセスが管理されます。 これによって、HTTP サイトと非 HTTP サイトで同じ構成およびプロセス モデルを使用できます。
さらに、HTTP 機能が不要な場合は、WWW サービスを実行せずに、WAS のみを実行できます。 たとえば、HTTP.sys で HTTP 要求をリッスンする必要がない場合は、WWW サービスを実行せずに、NetTcpActivator などの WCF リスナー アダプターによって Web サービスを管理できます。WCF リスナー アダプターおよび IIS 7.0 での WAS を使用した WCF アプリケーションのホスティングについては、MSDN の「Windows プロセス アクティブ化サービスでのホスティング」を参照してください。
WAS での構成管理
WAS は、起動時に、ApplicationHost.config ファイルから特定の情報を読み込み、その情報をサーバー上のリスナー アダプターに渡します。 リスナー アダプターは、WAS とプロトコル リスナー (HTTP.sys など) との間の通信を確立するコンポーネントです。 リスナー アダプターは、構成情報を受け取ると関連するプロトコル リスナーを構成し、リスナーが要求をリッスンできるように準備します。
WCF の場合は、リスナー アダプターにプロトコル リスナーの機能が含まれています。 したがって、NetTcpActivator などの WCF リスナー アダプターは、WAS からの情報に基づいて構成されます。 NetTcpActivator は、構成されると net.tcp プロトコルを使用する要求をリッスンします。 WCF リスナー アダプターの詳細については、MSDN の「WAS アクティベーション アーキテクチャ」を参照してください。
WAS によって構成から読み込まれる情報の種類を、次の一覧に示します。
- グローバルな構成情報
- HTTP と HTTP 以外のプロトコルの両方のプロトコル構成情報
- アプリケーション プールの構成 (プロセス アカウント情報など)
- サイトの構成 (バインドやアプリケーションなど)
- アプリケーションの構成 (有効なプロトコルや、アプリケーションが属するアプリケーション プールなど)
ApplicationHost.config が変更されると、WAS は通知を受信し、新しい情報を使用してリスナー アダプターを更新します。
プロセス管理
WAS は、HTTP と HTTP 以外の両方の要求用のアプリケーション プールおよびワーカー プロセスを管理します。 プロトコル リスナーがクライアント要求を受け取ると、WAS はワーカー プロセスが実行されているかどうかを確認します。 アプリケーション プールに既に要求を処理するワーカー プロセスがある場合、リスナー アダプターは処理のためにワーカー プロセスに要求を渡します。 アプリケーション プールにワーカー プロセスがない場合は、WAS はワーカー プロセスを起動して、リスナー アダプターが要求を処理するためにワーカー プロセスに渡せるようにします。
注: WAS は HTTP と HTTP 以外のプロトコルの両方のプロセスを管理するので、異なるプロトコルを使用するアプリケーションを同じアプリケーション プールで実行できます。 たとえば、XML サービスなどのアプリケーションを開発し、HTTP と net.tcp の両方でホストすることができます。
IIS 7.0 のモジュール
IIS 7.0 では、以前のバージョンの IIS とは異なる新しいアーキテクチャが用意されています。 サーバー自体に多くの機能を装備する代わりに、IIS 7.0 では、必要に応じて、モジュールと呼ばれるコンポーネントを追加または削除できる Web サーバー エンジンが実装されています。
モジュールは、サーバーが要求を処理するときに使用する個々の機能です。 たとえば、IIS は認証モジュールを使用してクライアント資格情報を認証し、キャッシュ モジュールを使用してキャッシュのアクティビティを管理します。
新しいアーキテクチャには、以前バージョンの IIS と比べて、次のようなメリットがあります。
- サーバーに実装するモジュールを管理できます。
- 使用環境での特定の役割に合わせてサーバーをカスタマイズできます。
- カスタム モジュールを使用して、既存のモジュールを置き換えたり、新しい機能を追加したりすることができます。
また、IIS 7.0 のアーキテクチャでは、セキュリティが強化され、管理が容易になっています。 不要なモジュールを削除することによって、サーバーが攻撃にさらされる領域とメモリ フットプリント (コンピューター上でサーバー ワーカー プロセスが使用するメモリの量) を減らすことができます。 サイトやアプリケーションに不要な機能を管理する必要もなくなります。
ネイティブ モジュール
ここでは、IIS 7.0 を完全インストールした場合に使用できるネイティブ モジュールについて説明します。 必要に応じて、ネイティブ モジュールを削除したり、カスタム モジュールに置き換えたりすることができます。
HTTP モジュール
IIS 7.0 では、複数のモジュールによって、要求処理パイプラインでハイパーテキスト転送プロトコル (HTTP) 特有のタスクを実行します。 HTTP モジュールには、クライアント ヘッダーで送信された情報や問い合わせに応答するモジュール、HTTP エラーを返すモジュール、要求をリダイレクトするモジュールなどが含まれます。
モジュール名 |
説明 |
リソース |
|---|---|---|
CustomErrorModule |
エラー ステータス コードが応答に設定された場合に、既定の HTTPエラー メッセージおよび構成済みの HTTP エラー メッセージを送信します。 |
Inetsrv\Custerr.dll |
HttpRedirectionModule |
HTTP 要求の構成可能なリダイレクトをサポートします。 |
Inetsrv\Redirect.dll |
ProtocolSupportModule |
応答ヘッダーの設定や構成に基づくヘッダーのリダイレクトなど、プロトコル関連のアクションを実行します。 |
Inetsrv\Protsup.dll |
セキュリティ モジュール
IIS 7.0 では、複数のモジュールによって、要求処理パイプラインでセキュリティ関連のタスクを実行します。 さらに、認証スキームごとに個別のモジュールがあり、サーバーで必要な認証の種類に応じてモジュールを選択できます。 URL 承認を実行するモジュールや、要求をフィルター処理するモジュールもあります。
モジュール名 |
説明 |
リソース |
AnonymousAuthenticationModule |
他の認証方法が成功しなかった場合に匿名認証を実行します。 |
Inetsrv\Authanon.dll |
BasicAuthenticationModule |
基本認証を実行します。 |
Inetsrv\Authbas.dll |
CertificateMappingAuthenticationModule |
Active Directory を使用して証明書マッピング認証を実行します。 |
Inetsrv\Authcert.dll |
DigestAuthenticationModule |
ダイジェスト認証を実行します。 |
Inetsrv\Authmd5.dll |
IISCertificateMappingAuthenticationModule |
IIS 証明書構成を使用して証明書マッピング認証を実行します。 |
Inetsrv\Authmap.dll |
RequestFilteringModule |
許可される動詞やファイル拡張子の構成、制限の設定、不正な文字シーケンスのスキャンなど、URLScan のタスクを実行します。 |
Inetsrv\Modrqflt.dll |
UrlAuthorizationModule |
URL 承認を実行します。 |
Inetsrv\Urlauthz.dll |
WindowsAuthenticationModule |
NTLM 統合認証を実行します。 |
Inetsrv\Authsspi.dll |
IpRestrictionModule |
構成の ipSecurity リストにある IPv4 アドレスのアクセスを制限します。 |
Inetsrv\iprestr.dll |
コンテンツ モジュール
IIS 7.0 では、複数のモジュールによって、要求処理パイプラインでコンテンツ関連のタスクを実行します。 コンテンツ モジュールには、静的ファイルへの要求を処理するモジュール、クライアントが要求でリソースを指定していない場合に既定のページを返すモジュール、ディレクトリの内容の一覧を出力するモジュールなどがあります。
モジュール名 |
説明 |
リソース |
|---|---|---|
CgiModule |
応答出力を作成する CGI (Common Gateway Interface) プロセスを実行します。 |
Inetsrv\Cgi.dll |
DefaultDocumentModule |
親ディレクトリへの要求に対して既定のドキュメントを返すよう試みます。 |
Inetsrv\Defdoc.dll |
DirectoryListingModule |
ディレクトリの内容の一覧を出力します。 |
Inetsrv\dirlist.dll |
IsapiModule |
ISAPI 拡張 DLL をホストします。 |
Inetsrv\Isapi.dll |
IsapiFilterModule |
ISAPI フィルター DLL をサポートします。 |
Inetsrv\Filter.dll |
ServerSideIncludeModule |
サーバー側インクルード コードを処理します。 |
Inetsrv\Iis_ssi.dll |
StaticFileModule |
静的ファイルを提供します。 |
Inetsrv\Static.dll |
FastCgiModule |
CGI に代わるハイパフォーマンスを実現する FastCGI モジュールをサポートします。 |
Inetsrv\iisfcgi.dll |
圧縮モジュール
IIS 7.0 では、要求処理パイプラインで圧縮を実行するモジュールが 2 つあります。
モジュール名 |
説明 |
リソース |
|---|---|---|
DynamicCompressionModule |
応答を圧縮し、Gzip 圧縮転送コーディングを応答に適用します。 |
Inetsrv\Compdyn.dll |
StaticCompressionModule |
静的コンテンツの事前圧縮を実行します。 |
Inetsrv\Compstat.dll |
キャッシング モジュール
IIS 7.0 では、複数のモジュールによって、要求処理パイプラインでキャッシュ関連のタスクを実行します。 キャッシングによって、Web ページなどの処理された情報をサーバー上のメモリに格納して、その情報を同じリソースに対する後続の要求で再利用することにより、Web サイトと Web アプリケーションのパフォーマンスが向上します。
モジュール名 |
説明 |
リソース |
|---|---|---|
FileCacheModule |
ファイルとファイル ハンドルのユーザー モード キャッシュを提供します。 |
Inetsrv\Cachfile.dll |
HTTPCacheModule |
HTTP.sys でカーネル モードおよびユーザー モードのキャッシュを提供します。 |
Inetsrv\Cachhttp.dll |
TokenCacheModule |
Windows ユーザー プリンシパルを生成するモジュールに対して、ユーザー名とトークンのペアのユーザー モード キャッシュを提供します。 |
Inetsrv\Cachtokn.dll |
UriCacheModule |
URL 情報のユーザー モード キャッシュを提供します。 |
Inetsrv\Cachuri.dll |
ログ記録および診断モジュール
IIS 7.0 では、複数のモジュールによって、要求処理パイプラインでログ記録および診断関連のタスクを実行します。 ログ記録モジュールは、カスタム モジュールの読み込みおよび HTTP.sys への情報の受け渡しをサポートします。診断モジュールは、要求の処理中に発生するイベントを追跡およびレポートします。
モジュール名 |
説明 |
リソース |
|---|---|---|
CustomLoggingModule |
カスタム ログ記録モジュールを読み込みます。 |
Inetsrv\Logcust.dll |
FailedRequestsTracingModule |
失敗した要求のトレース機能をサポートします。 |
Inetsrv\Iisfreb.dll |
HttpLoggingModule |
情報および処理状態をログに記録するために HTTP.sys に渡します。 |
Inetsrv\Loghttp.dll |
RequestMonitorModule |
ワーカー プロセスで現在実行中の要求を追跡し、RSCA (Runtime Status and Control Application Programming Interface) によって情報をレポートします。 |
Inetsrv\Iisreqs.dll |
TracingModule |
Microsoft Windows イベント トレーシング (ETW) にイベントをレポートします。 |
Inetsrv\Iisetw.dll |
マネージ サポート モジュール
IIS 7.0 では、IIS 要求処理パイプラインでマネージ統合をサポートするモジュールがいくつかあります。
モジュール名 |
説明 |
リソース |
|---|---|---|
ManagedEngine |
IIS 要求処理パイプラインへのマネージ コード モジュールの統合を実現します。 |
Microsoft.NET\Framework\v2.0.50727\webengine.dll |
ConfigurationValidationModule |
構成に関する問題を検証します。たとえば、アプリケーションが統合モードで実行されているが、ハンドラーやモジュールが system.web セクションで宣言されているような場合です。 |
Inetsrv\validcfg.dll |
マネージ モジュール
IIS 7.0 では、ネイティブ モジュールに加えて、マネージ コード モジュールを使って IIS の機能拡張を行うことができます。 UrlAuthorization などの一部のマネージ モジュールには、マネージ モジュールに相当する代替ネイティブ機能を提供するネイティブ モジュールが用意されています。
注 マネージ モジュールは ManagedEngine モジュールに依存します。
IIS 7.0 を完全インストールした場合に使用できるマネージ モジュールの一覧を次の表に示します。マネージ モジュールの詳細については、MSDN の「.NET Framework SDK 2.0」を参照してください。
モジュール名 |
説明 |
リソース |
|---|---|---|
AnonymousIdentification |
ASP.NET プロファイルなど、匿名 ID をサポートする機能で使用される匿名 ID を管理します。 |
System.Web.Security.AnonymousIdentificationModule |
DefaultAuthentication |
認証オブジェクトがコンテキストに存在することを保証します。 |
System.Web.Security.DefaultAuthenticationModule |
FileAuthorization |
ユーザーが要求したファイルにアクセスするためのアクセス許可を持っていることを確認します。 |
System.Web.Security.FileAuthorizationModule |
FormsAuthentication |
フォーム認証による認証をサポートします。 |
System.Web.Security.FormsAuthenticationModule |
OutputCache |
出力キャッシュをサポートします。 |
System.Web.Caching.OutputCacheModule |
Profile |
ASP.NET プロファイルを利用してユーザー プロファイルを管理します。ASP.NET プロファイルでは、データベースなどのデータ ソースを使ってユーザー設定を保存したり取得することができます。 |
System.Web.Profile.ProfileModule |
RoleManager |
現在のユーザーの RolePrincipal インスタンスを管理します。 |
System.Web.Security.RoleManagerModule |
Session |
セッション状態の保持をサポートします。これにより、サーバー上のアプリケーション内で、単一クライアントの固有データを保管できます。 |
System.Web.SessionState.SessionStateModule |
UrlAuthorization |
ユーザー名またはユーザーが属するロールに基づいて、現在のユーザーが、要求された URL へのアクセスを許可されているかどうか確認します。 |
System.Web.Security.UrlAuthorizationModule |
UrlMappingsModule |
実際の URL とユーザーにわかりやすい URL とのマッピングをサポートします。 |
System.Web.UrlMappingsModule |
WindowsAuthentication |
Windows 認証が有効である場合に、ASP.NET アプリケーションに対するユーザーの ID を設定します。 |
System.Web.Security.WindowsAuthenticationModule |
IIS 7.0 の要求処理
IIS 7.0 では、IIS と ASP.NET の要求パイプラインの統合によって、単一のアプローチで要求を処理することができます。 この新しい要求処理アーキテクチャは、要求に対して特定のタスクを実行するネイティブ モジュールとマネージ モジュールの順序付けられたリストで構成されます。
この設計には、以前のバージョンの IIS に比べていくつかのメリットがあります。 まず、以前はマネージ コードでのみ使用可能だった機能が、すべての種類のファイルで使用できるようになりました。 たとえば、ASP.NET フォーム認証および URL (Uniform Resource Locator) 承認を、サイトやアプリケーションの静的ファイル、Active Server Pages (ASP) ファイル、その他すべての種類のファイルで使用できます。
2 つめは、この設計によって IIS と ASP.NET でいくつかの機能の重複を解消できたことです。 たとえば、クライアントがマネージ ファイルを要求すると、サーバーは統合パイプラインで適切な認証モジュールを呼び出して、クライアントを認証します。 以前のバージョンの IIS では、これと同じ要求は、IIS のパイプラインと ASP.NET のパイプラインの両方で認証プロセスを経ていました。
3 つめは、一部の機能を IIS の構成で管理し、一部を ASP.NET の構成で管理する代わりに、すべてのモジュールを一元管理できるようになったことです。 これにより、サーバー上でのサイトやアプリケーションの管理が簡素化されます。
IIS 7.0 のアプリケーション プール
アプリケーション プールでは、サーバー上のアプリケーションが別のアプリケーションに影響を及ぼさないように、プロセス境界によってアプリケーションが分離されます。 IIS 7.0 のアプリケーション プールでも、引き続き IIS 6.0 のワーカー プロセス分離モードが使用されています。 さらに、マネージ リソースに関連する要求の処理方法を決める設定 (統合モードとクラシック モード) を指定できるようになりました。
注: IIS 6.0 では、ワーカー プロセス分離モードと IIS 5.0 分離モードが同じレベルで設定されています。 このため、両方の分離モードを同じサーバーで実行することはできません。 一方、IIS 7.0 では、統合モードとクラシック モードがアプリケーション プール レベルで設定されており、同じサーバーで異なるプロセス モードを使用して、アプリケーション プールで同時にアプリケーションを実行できます。
統合アプリケーション プール モード
アプリケーション プールが統合モードである場合、IIS と ASP.NET の統合要求処理アーキテクチャを利用できます。 アプリケーション プール内のワーカー プロセスが要求を受け取ると、要求は順序付けされたイベントのリストを通じて受け渡しされます。 各イベントでは、必要なネイティブ モジュールおよびマネージ モジュールが呼び出され、要求の一部が処理され、応答が生成されます。
アプリケーション プールを統合モードで実行することには、いくつかのメリットがあります。 まず、IIS と ASP.NET の要求処理モデルが統一されたプロセス モデルとして統合されることです。 このモデルでは、認証など、以前は IIS と ASP.NET で重複していた手順が解消されます。 また、統合モードではあらゆる種類のコンテンツでマネージ機能を利用できるようになります。
クラシック アプリケーション プール モード
アプリケーション プールがクラシック モードである場合、要求は 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 の新しいアーキテクチャにより、このプロセスではアプリケーションに障害が発生します。
IS 7.0 での HTTP 要求処理
IIS 7.0 の HTTP 要求処理フローは IIS 6.0 と同様です。 ここでは、HTTP 要求の処理の概要を図で示します。
次の一覧では、図 1 に示す要求処理フローを説明しています。
- クライアント ブラウザーが Web サーバー上のリソースに対して HTTP 要求を開始すると、HTTP.sys が要求をインターセプトします。
- HTTP.sys は WAS に問い合わせて、構成ストアから情報を取得します。
- WAS は構成ストア applicationHost.config に構成情報を要求します。
- WWW サービスは、アプリケーション プールやサイトの構成などの構成情報を受け取ります。
- WWW サービスは構成情報を使用して HTTP.sys を構成します。
- WAS は要求の対象となるアプリケーション プール用のワーカー プロセスを起動します。
- ワーカー プロセスは要求を処理、HTTP.sys に応答を返します。
- クライアントは応答を受け取ります。
.png "HTTP 要求の概要")
図 1: HTTP 要求の概要
ワーカー プロセスでは、HTTP 要求は Web サーバー コア内のイベントと呼ばれる複数の順序付きの手順を通じて受け渡しされます。 各イベントにおいて、ネイティブ モジュールが、ユーザーの認証やイベント ログへの情報の追加など、要求の一部を処理します。 要求がマネージ モジュールを必要とする場合は、ネイティブ ManagedEngine モジュールによって AppDomain が作成されます。AppDomain で、マネージ モジュールは、フォーム認証によるユーザーの認証などの必要な処理を実行できます。 Web サーバー コアのすべてのイベントで要求の処理が終わると、HTTP.sys に応答が返されます。 次の図 2 は、ワーカー プロセス内での HTTP 要求の処理を示しています。
.png "ワーカー プロセス内での HTTP 要求処理の詳細")
図 2: ワーカー プロセス内での HTTP 要求処理の詳細