IIS アーキテクチャの概要
IIS チーム、Reagan Templin
互換性
| バージョン | メモ |
|---|---|
| IIS 7.0 以降 | この記事で説明されている機能は、IIS 7.0 で導入されました。 |
| IIS 6.0 以前 | この記事で説明されている機能は、IIS 7.0 より前ではサポートされていませんでした。 |
はじめに
インターネット インフォメーション サービス (IIS) 7 以降では、次を含む要求処理アーキテクチャが提供されています:
- サイトで HTTP および HTTPS 以外のプロトコルを使用できるようにする Windows プロセス アクティブ化サービス (WAS)。
- モジュールを追加または削除することでカスタマイズできる Web サーバー エンジン。
- IIS と ASP.NET からの統合された要求処理パイプライン。
IIS のコンポーネント
IIS には、Windows Server® 2008 (IIS 7.0) および Windows Server® 2008 R2 (IIS 7.5) のアプリケーションと Web サーバーの役割に関する重要な機能を実行するコンポーネントがいくつか含まれています。 各コンポーネントには、サーバーに対する要求のリッスン、プロセスの管理、構成ファイルの読み取りなどの役割があります。 これらのコンポーネントには、HTTP.sys などのプロトコル リスナーと、World Wide Web 発行サービス (WWW サービス) や Windows プロセス アクティブ化サービス (WAS) などのサービスが含まれます。
プロトコル リスナー
プロトコル リスナーは、プロトコル固有の要求を受け取り、処理するために IIS に送信してから、要求者に応答を返します。 たとえば、クライアント ブラウザーがインターネットから Web ページを要求すると、HTTP リスナーである HTTP.sys が要求を取得し、処理するために IIS に送ります。 IIS が要求を処理すると、HTTP.sys がクライアント ブラウザーに応答を返します。
既定では、IIS は HTTP および HTTPS 要求をリッスンするプロトコル リスナーとして HTTP.sys を提供します。 HTTP.sys は、HTTP 要求の HTTP 固有のプロトコル リスナーとして IIS 6.0 で導入されました。 HTTP.sys は IIS 7 以降でも HTTP リスナーのままですが、Secure Sockets Layer (SSL) がサポートされています。
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 Sockets API (Winsock) が HTTP.sys に置き換えられました。Winsock は、以前のバージョンの IIS で HTTP 要求を受け取り、HTTP 応答を送信するために使用された、ユーザーモード コンポーネントでした。 IIS 7 以降でも引き続き、HTTP 要求に HTTP.sys が使用されます。
HTTP.sys には次のメリットがあります:
- カーネルモード キャッシュ。 キャッシュされた応答の要求が、ユーザー モードに切り替えることなく返されます。
- カーネルモード要求キュー。 カーネルが要求を正しいワーカー プロセスに直接転送するため、要求によるコンテキスト切り替えのオーバーヘッドが少なくなります。 要求を受け入れるワーカー プロセスがない場合、カーネルモード要求キューは、ワーカー プロセスが要求を受け入れるまで要求を保持します。
- 事前処理とセキュリティ フィルター処理の要求。
World Wide Web 発行サービス (WWW サービス)
IIS 7 以降では、以前は World Wide Web 発行サービス (WWW サービス) だけで処理されていた機能が、WWW サービスと、新しいサービスである Windows プロセス アクティブ化サービス (WAS) の 2 つのサービスで分担されるようになりました。 この 2 つのサービスは、同じ Svchost.exe プロセスで LocalSystem として実行され、同じバイナリを共有します。
Note
ドキュメントでは、WWW サービスが W3SVC と記載されている場合もあります。
IIS 6.0 での WWW サービスの仕組み
IIS 6.0 では、WWW サービスは IIS の次の主な領域を管理します:
- HTTP の管理と構成
- プロセス管理
- パフォーマンスの監視
HTTP の管理と構成
WWW サービスは、IIS メタベースから構成情報を読み取り、その情報を使用して HTTP リスナー (HTTP.sys) を構成および更新します。 さらに、WWW サービスは、HTTP 要求を処理するワーカー プロセスの開始、停止、監視、管理を担います。
パフォーマンスの監視
WWW サービスはパフォーマンスを監視し、Web サイトと IIS キャッシュのパフォーマンス カウンターを提供します。
プロセス管理
WWW サービスは、アプリケーション プールの管理と、ワーカー プロセスの開始、停止、リサイクルなど、ワーカー プロセスの管理を行います。 さらに、WWW サービスはワーカー プロセスの正常性を監視し、迅速なフェール検出を呼び出して、構成された時間内に複数のワーカー プロセスが失敗した場合に新しいプロセスが開始されないようにします。
IIS での WWW サービスの仕組み
IIS で、WWW サービスがワーカー プロセスを管理しなくなりました。 代わりに、WWW サービスは HTTP リスナーである HTTP.sys のリスナー アダプターとなります。 リスナー アダプターとして、WWW サービスは主に、HTTP.sys の構成、構成が変更されたときの HTTP.sys の更新、要求が要求キューに入ったときの WAS への通知を担います。
さらに、WWW サービスは引き続き Web サイトのカウンターを収集します。 パフォーマンス カウンターは WWW サービスの一部であるため、HTTP 固有であり、WAS には適用されません。
Windows プロセス アクティブ化サービス (WAS)
IIS 7 以降では、Windows プロセス アクティブ化サービス (WAS) は、WWW サービスではなく、アプリケーション プールの構成とワーカー プロセスを管理します。 これにより、HTTP サイトと非 HTTP サイトで同じ構成とプロセス モデルを使用できます。
さらに、HTTP 機能が不要な場合は、WWW サービスなしで WAS を実行できます。 たとえば、HTTP.sys で HTTP 要求をリッスンする必要がない場合、WWW サービスを実行せずに、NetTcpActivator などの WCF リスナー アダプターを使用して Web サービスを管理できます。 WCF リスナー アダプターと、WAS を使用して IIS 7 以降で WCF アプリケーションをホストする方法については、MSDN の「WCF でのホスト」を参照してください。
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 はワーカー プロセスを開始して、リスナー アダプターが処理のために要求を渡せるようにします。
Note
WAS は HTTP および非 HTTP プロトコルの両方のプロセスを管理するため、同じアプリケーション プール内で異なるプロトコルを使用してアプリケーションを実行できます。 たとえば、XML サービスなどのアプリケーションを開発し、HTTP と net.tcp の両方でホストできます。
IIS のモジュール
IIS には、以前のバージョンの IIS とは異なる新しいアーキテクチャが使用されています。 IIS には、機能の大部分をサーバー自体に保持するのではなく、ニーズに応じてモジュールと呼ばれるコンポーネントを追加または削除できる、Web サーバー エンジンが搭載されています。
モジュールとは、サーバーが要求の処理に使用する個別の機能のことです。 たとえば、IIS では認証モジュールを使用してクライアントの資格情報を認証し、キャッシュ モジュールを使用してキャッシュ アクティビティを管理します。
この新しいアーキテクチャは、以前のバージョンの IIS に比べて次のメリットがあります:
- サーバーに必要なモジュールを管理できる。
- 環境内の特定のロールに合わせてサーバーをカスタマイズできる。
- カスタム モジュールを使用して、既存のモジュールを置き換えたり、新機能を導入したりできる。
新しいアーキテクチャはセキュリティも向上し、管理しやすくなっています。 不要なモジュールを削除することで、サーバーの攻撃対象領域とメモリ占有領域 (サーバー ワーカー プロセスがマシン上で使用するメモリの量) を減らすことができます。 また、サイトやアプリケーションに不要な機能を管理する必要がなくなります。
ネイティブ モジュール
以降のセクションでは、IIS 7 以降の完全インストールで使用できるネイティブ モジュールについて説明します。 これらはニーズに応じて削除したり、カスタム モジュールに置き換えたりすることができます。
HTTP モジュール
IIS 7 以降のいくつかのモジュールは、要求処理パイプラインでハイパーテキスト転送プロトコル (HTTP) に固有のタスクを実行します。 HTTP モジュールには、クライアント ヘッダーで送信された情報や問い合わせに応答するモジュール、HTTP エラーを返すモジュール、要求をリダイレクトするモジュールなどがあります。
| モジュール名 | 説明 | リソース |
|---|---|---|
| CustomErrorModule | 応答にエラー状態コードが設定されている場合、既定または構成済みの HTTP エラー メッセージを送信します。 | Inetsrv\Custerr.dll |
| HttpRedirectionModule | HTTP 要求の構成可能なリダイレクトをサポートします。 | Inetsrv\Redirect.dll |
| ProtocolSupportModule | 応答ヘッダーの設定や、構成に基づくヘッダーのリダイレクトなど、プロトコル関連のアクションを実行します。 | Inetsrv\Protsup.dll |
| RequestFilteringModule | IIS 7.5 で追加されました。 プロトコルとコンテンツの動作を制御するため、構成に従い要求をフィルター処理します。 | Inetsrv\modrqflt.dll |
| WebDAVModule | IIS 7.5 で追加されました。 HTTP over SSL を使用してコンテンツをより安全に発行できるようにします。 | Inetsrv\WebDAV.dll |
セキュリティ モジュール
IIS のいくつかのモジュールは、要求処理パイプラインのセキュリティに関連するタスクを実行します。 さらに、認証スキームごとに個別のモジュールがあり、サーバーで必要な認証の種類のモジュールを選択できます。 また、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 のいくつかのモジュールは、要求処理パイプラインのコンテンツに関連するタスクを実行します。 コンテンツ モジュールには、静的ファイルの要求を処理するモジュール、クライアントが要求でリソースを指定しない場合に既定のページを返すモジュール、ディレクトリのコンテンツを一覧表示するモジュールなどが含まれます。
| モジュール名 | 説明 | リソース |
|---|---|---|
| CgiModule | Common Gateway Interface (CGI) プロセスを実行して応答出力を作成します。 | 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 には、要求処理パイプラインで圧縮を実行する 2 つのモジュールがあります。
| モジュール名 | 説明 | リソース |
|---|---|---|
| DynamicCompressionModule | 応答を圧縮し、応答に Gzip 圧縮転送コーディングを適用します。 | Inetsrv\Compdyn.dll |
| StaticCompressionModule | 静的コンテンツの事前圧縮を実行します。 | Inetsrv\Compstat.dll |
キャッシュ モジュール
IIS のいくつかのモジュールは、要求処理パイプラインでのキャッシュに関連するタスクを実行します。 キャッシュを使用すると、Web ページなどの処理済みの情報をサーバーのメモリに格納し、その情報を同じリソースに対するその後の要求で再利用することで、Web サイトと Web アプリケーションのパフォーマンスが向上します。
| モジュール名 | 説明 | リソース |
|---|---|---|
| FileCacheModule | ファイルとファイル ハンドルのユーザー モード キャッシュを提供します。 | Inetsrv\Cachfile.dll |
| HTTPCacheModule | HTTP.sys でのカーネル モードとユーザー モードのキャッシュを提供します。 | Inetsrv\Cachhttp.dll |
| TokenCacheModule | Windows ユーザー プリンシパルを生成するモジュールのユーザー名とトークンのペアのユーザー モード キャッシュを提供します。 | Inetsrv\Cachtokn.dll |
| UriCacheModule | URL 情報のユーザー モード キャッシュを提供します。 | Inetsrv\Cachuri.dll |
ログおよび診断モジュール
IIS のいくつかのモジュールは、要求処理パイプラインのログと診断に関連するタスクを実行します。 ログ モジュールは、カスタム モジュールの読み込みと HTTP.sys への情報の受け渡しをサポートします。 診断モジュールは、要求処理中にイベントを追跡し報告します。
| モジュール名 | 説明 | リソース |
|---|---|---|
| CustomLoggingModule | カスタム ログ モジュールを読み込みます。 | Inetsrv\Logcust.dll |
| FailedRequestsTracingModule | 失敗した要求のトレース機能をサポートします。 | Inetsrv\Iisfreb.dll |
| HttpLoggingModule | ログ用に、情報と処理の状態を HTTP.sys に渡します。 | Inetsrv\Loghttp.dll |
| RequestMonitorModule | ワーカー プロセスで現在実行されている要求を追跡し、ランタイム状態およびコントロール アプリケーション プログラミング インターフェイス (RSCA) を使用して情報を報告します。 | Inetsrv\Iisreqs.dll |
| TracingModule | Microsoft Event Tracing for Windows (ETW) にイベントを報告します。 | Inetsrv\Iisetw.dll |
マネージド サポート モジュール
IIS のいくつかのモジュールは、IIS 要求処理パイプラインでのマネージド統合をサポートします。
| モジュール名 | 説明 | リソース |
|---|---|---|
| ManagedEngine | IIS 要求処理パイプラインでマネージド コード モジュールを統合します。 | Microsoft.NET\Framework\v2.0.50727\webengine.dll |
| ConfigurationValidationModule | アプリケーションが統合モードで実行されているが、system.web セクションで宣言されたハンドラーまたはモジュールがある場合など、構成の問題を検証します。 | Inetsrv\validcfg.dll |
マネージド モジュール
ネイティブ モジュールに加えて、IIS ではマネージド コード モジュールを使用して IIS の機能を拡張できます。 UrlAuthorization などの一部のマネージド モジュールには、マネージド モジュールに代わるネイティブの代替手段となるネイティブ モジュールがあります。
Note
マネージド モジュールは、ManagedEngine モジュールに依存します。
次の表に、IIS 7 以降の完全インストールで使用できるマネージド モジュールの一覧を示します。 マネージド モジュールの詳細については、MSDN の「.NET Framework SDK 2.0」を参照してください。
| モジュール名 | 説明 | リソース |
|---|---|---|
| AnonymousIdentification | ASP.NET プロファイルなどの匿名 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 |
| プロフィール | ASP.NET プロファイルを使用してユーザー プロファイルを管理します。このプロファイルは、データベースなどのデータ ソースへのユーザー設定の格納および取得を行います。 | System.Web.Profile.ProfileModule |
| RoleManager | 現在のユーザーの RolePrincipal インスタンスを管理します。 | System.Web.Security.RoleManagerModule |
| セッション | セッション状態の維持をサポートします。これにより、サーバー上のアプリケーション内の 1 つのクライアントに固有のデータを格納できます。 | 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 での要求処理
IIS では、IIS と ASP.NET の要求パイプラインを組み合わせ、統合されたアプローチで要求が処理されます。 この新しい要求処理アーキテクチャは、要求に応じて特定のタスクを実行するネイティブおよびマネージド モジュールの順序付きリストで構成されています。
この設計は、以前のバージョンの IIS に比べ、いくつかのメリットを提供します。 まずはじめに、以前はマネージド コードでしか使用できなかった機能を、すべてのファイルの種類で使用できます。 たとえば、静的ファイル、Active Server Pages (ASP) ファイル、サイトやアプリケーション内のその他すべてのファイルの種類で、ASP.NET フォーム認証と Uniform Resource Locator (URL) 認可を使用できるようになりました。
次に、この設計では、IIS と ASP.NET の複数の機能の重複がなくなります。 たとえば、クライアントがマネージド ファイルを要求すると、サーバーは統合パイプライン内の適切な認証モジュールを呼び出して、クライアントを認証します。 以前のバージョンの IIS では、これと同じ要求に対し、IIS と ASP.NET の両方のパイプラインで認証プロセスが行われていました。
3 つ目は、IIS の構成で一部の機能を、そして ASP.NET の構成で他の機能を管理するのではなく、すべてのモジュールを 1 か所で管理できる点です。 これにより、サーバー上のサイトとアプリケーションの管理がしやすくなります。
IIS のアプリケーション プール
アプリケーション プールは、アプリケーションがサーバー上の別のアプリケーションに影響を与えないように、プロセスの境界によってアプリケーションを分離します。 IIS 7 以降では、アプリケーション プールで引き続き IIS 6.0 のワーカー プロセス分離モードが使用されます。 さらに、マネージド リソースを含む要求を、統合モードとクラシック モードのどちらで処理するかを設定できるようになりました。
Note
IIS 6.0 では、ワーカー プロセス分離モードと IIS 5.0 の分離モードがサーバー レベルで設定されます。 これにより、同じサーバーで両方の分離モードを実行できなくなります。 ただし、IIS 7 以降では、統合モードとクラシック モードがアプリケーション プール レベルで設定されます。これにより、同じサーバー上のプロセス モードが異なるアプリケーションを、アプリケーション プールで同時に実行できます。
統合アプリケーション プール モード
アプリケーション プールが統合モードの場合、IIS と ASP.NET の統合された要求処理アーキテクチャを利用できます。 アプリケーション プール内のワーカー プロセスが要求を受け取ると、要求は順序付けされたイベントのリストに従い処理されます。 各イベントは、要求の一部を処理し応答を生成するために、必要なネイティブ モジュールとマネージド モジュールを呼び出します。
統合モードでのアプリケーション プールの実行には、いくつかのメリットがあります。 まず、IIS と ASP.NET の要求処理モデルが、統合プロセス モデルにまとめられます。 このモデルでは、以前に IIS と ASP.NET で重複していた手順 (認証など) が省かれます。 さらに、統合モードを使用すると、すべてのコンテンツ タイプでマネージド機能を利用できるようになります。
クラシック アプリケーション プール モード
アプリケーション プールがクラシック モードの場合、IIS 7 以降は IIS 6.0 のワーカー プロセス分離モードと同じ方法で要求を処理します。 ASP.NET 要求は、まず IIS のネイティブ処理を経て、マネージド ランタイムでマネージド コードを処理するために Aspnet_isapi.dll にルーティングされます。 最後に、要求が IIS に戻され、応答が送信されます。
このように IIS と ASP.NET の要求処理モデルを分離することで、認証や認可などの一部の処理手順が重複します。 さらに、フォーム認証などのマネージド コード機能は、ASP.NET アプリケーション、または aspnet_isapi.dll によって処理される要求がすべてスクリプトでマップされたアプリケーションでのみ使用できます。
運用環境を IIS 7 以降にアップグレードし、統合モードでアプリケーションをアプリケーション プールに割り当てる前に、既存のアプリケーションの統合モードとの互換性をテストしてください。 アプリケーションをクラシック モードのアプリケーション プールに追加するのは、アプリケーションが統合モードで動作しない場合のみです。 たとえば、アプリケーションが IIS からマネージド ランタイムに渡される認証トークンに依存し、IIS 7 以降の新しいアーキテクチャが原因で、プロセスによってアプリケーションが機能しない場合などです。
IIS での HTTP 要求の処理
IIS 7 以降では、IIS 6.0 と同様のフローで HTTP 要求が処理されます。 このセクションの図は、HTTP 要求処理の概要を示しています。
次のリストには、図 1 に示されている要求処理フローに関する説明が記されています:
- クライアント ブラウザーが Web サーバー上のリソースに対する HTTP 要求を開始すると、HTTP.sys がその要求をインターセプトします。
- HTTP.sys が WAS にコンタクトし、構成ストアから情報を取得します。
- WAS が構成ストア applicationHost.config に構成情報を要求します。
- WWW サービスが、アプリケーション プールやサイト構成などの構成情報を受け取ります。
- WWW サービスは、構成情報を使用して HTTP.sys を構成します。
- WAS が、要求が行われたアプリケーション プールのワーカー プロセスを開始します。
- ワーカー プロセスが要求を処理し、HTTP.sys に応答を返します。
- クライアントが応答を受け取ります。
図 1: HTTP 要求の概要
ワーカー プロセスでは、HTTP 要求は、Web Server Core でイベントと呼ばれるいくつかの順序付けされた手順に従い処理されます。 各イベントで、ネイティブ モジュールが、ユーザーの認証やイベント ログへの情報の追加など、要求の一部を処理します。 要求にマネージド モジュールが必要な場合は、ネイティブ ManagedEngine モジュールによって AppDomain が作成されます。これにより、マネージド モジュールが、フォーム認証によるユーザーの認証など、必要な処理を実行できます。 要求が Web Server Core 内のすべてのイベントを通過すると、応答が HTTP.sys に返されます。 下の図 2 は、ワーカー プロセスに入る HTTP 要求を示しています。
図 2: ワーカー プロセス内の HTTP 要求の詳細
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示