IISワーカープロセス内で、個別のサイト(ドメイン) 独自のアプリドメインで実行 。
example.com
というサイトにワイルドカードDNSレコードがある(つまり、*.example.com
がIPを指している)。サブドメインリソースの処理z.example.com
は、 www.abc.com
?私は答えはイエスでなければならないと思いますが、決定的なものを見つけることができません
いいえ。このようなサイトをいくつか運営しています。バインディングは、どのアプリがリクエストを受け取るかを決定し、各アプリは1つのアプリプールのみを持つことができます。アプリプールは複数のプロセス(Webガーデン)を使用できますが、ワイルドカードドメイン名とはまったく関係ありません(このシナリオでは、単一のドメインでも複数のプロセスに分割されます)。
アプリドメイン(.Net内のセキュリティ構造)は、アプリケーションを互いに分離します。各アプリケーションは、バインドするドメインの数に関係なく、プロセスごとに1つのアプリドメインのみを取得します。ワイルドカードDNSがなくても、www.abc.comやfoo.xyz.netなど、2つの完全に分離されたドメインが同じアプリケーションにバインドされている場合、それらは両方とも同じプロセスの同じアプリ内の同じアプリドメインによって処理されます)同じアプリプール内。
以下は、IISによる着信リクエストの処理方法の概要です(ISAPIフィルター、URL書き換えなどを無視します)。これは、IIS 5-8.5:
(ネットワークインターフェイスからの)着信要求のIPアドレスとポート番号は、ポートにバインドされたSSL(TLS)証明書があるかどうかを確認します。その場合、SSL(TLS)ネゴシエーションが開始されます。これは、IISが要求を認識する前に発生します。この部分はオペレーティングシステム自体によって処理されるためです。 TLSの新しいバージョンでは、ホスト名(HTTPまたはHTTPS要求のヘッダーで送信される)をスニッフィングできるため、同じIPアドレスとポートであっても、異なる証明書を暗号化に使用できます。 IIS管理インターフェイスにより、証明書の構成がIISの一部であるかのように見えますが、そうではありません。
次に、IISはオペレーティングシステムからHTTPまたはHTTPSリクエストを受信します。 IISは、すべてのサイト(IISツールによってWebサイトとも呼ばれる)のバインディングを調べ、IPアドレスとポートが一致するものをすべて見つけます。複数ある場合は、一致するホスト名を持つものを選択します(リクエスト内のホストヘッダーを使用し、ブラウザがURLからホスト名を入力します)。ホスト名にワイルドカードを含めることはできません。IIS管理インターフェイスはそれらを許可しません(コマンドラインツールを使用して設定することはできますが、とにかく思うように機能しない可能性があります。今のところそれらを避けるために)。 IIS管理インターフェイスでは、同じ情報を使用して複数のバインディングを作成することはできません(ただし、コマンドラインツールではこのようなものがすり抜けることがあり、結果は未定義です)。サイトは、実際にはIISの単なる組織構造です。バインディングと同様に、構成情報はありますが、サイトに直接関連付けられたコードはありません。サイト構成で指定されたパスは、実際にはサイト内のデフォルトアプリケーションのパスです。
サイトが決定されたので、IISはリクエストを送信するアプリケーションを決定する必要があります。サイトが作成されると、そのサイトのデフォルトアプリケーションも作成されます。 IISは、最初にサイト内のデフォルト以外のアプリケーションをチェックします。これらのアプリケーションはそれぞれ、パスによって一意に識別されます(デフォルトのアプリケーションにはパスがないか、「ルート」パスがあります)。パスが着信URLの先頭にあるものと一致する場合、そのアプリケーションが選択され、最も具体的な(最も深い)一致するサイトが選択されます。デフォルト以外のアプリケーションが一致しない場合、デフォルトのアプリケーションが選択されます。
アプリケーションが決定されたので、IISはリクエストを直接処理するか、何らかの方法でリクエストをアプリケーションにルーティングする必要があります。リクエストが静的ファイルに対するもので、アプリケーションのweb.configにsystem.webServer/modules/@runAllManagedModulesForAllRequests= "true"が設定されていない場合、IIS(またはASP.NET IIS)は、適切なコンテンツタイプのファイルコンテンツを返します。リクエストが静的ファイルに対するものでない場合(またはコードを介してすべてのリクエストをルーティングするようにweb.configを設定した場合)、IISはどのアプリケーションプール(またはコマンドラインツールとしてのAppPool)を確認しますそれを参照)サイトが使用するように構成されています。次に、そのアプリケーションプールの「Webガーデン」からランダム(またはラウンドロビン)に選択されたプロセスで、アプリケーションコードに要求を転送します。デフォルトのWebガーデンには1つのプロセスしかありません。 (IIS自体は「ウェブガーデン」という用語を使用しませんが、IISチームメンバーによるブログ投稿で使用されます。アプリケーションプール設定の[最大ワーカープロセス]設定を参照してください。庭にいくつのプロセスがあるかを制御するもの)。
Webガーデンのプロセス内で、各サイトは独自のAppDomainに存在します(これは.NETプロセス内のサンドボックスを指す.NET用語ですが、IIS 'Site'を意味するために誤用されることがよくあります。 、およびこれに「アプリケーションドメイン」という用語が使用されることもありますが、この用語がIIS管理インターフェイスまたはコマンドラインツールで使用されたことはありません。 AppDomainsの動作方法により、サイトの各インスタンス(Webガーデンの異なるプロセスにある)はそれぞれ独自の静的変数を取得します。サイトコードは必要に応じて追加のAppDomainを自由に作成できますが、それはあなた次第です。 IISは、各Webガーデン(アプリケーションプール)プロセスに1つだけ作成します。技術的には、「World Wide Web」サービスはおそらくアプリケーションプールプロセス(w3wp.exe)にリクエストを渡し、そのプロセスはリクエストを渡すサイトとAppDomainを決定しますが、それはIISによって隠されている実装の詳細です。 「World Wide Web」サービスとw3wp.exeプロセスはIISの一部です。 W3wpはこの時点でヘッダーを調べて、指定されたホスト名を確認し、その時点で一意のホスト名ごとに異なるAppDomainを呼び出すことができますが、そうではありません。リクエストにはホスト名さえない場合があります。これは、IPアドレスだけで着信する可能性があるためです。
この点に到達すると、 ASP.NETアプリケーションのライフサイクル が引き継ぎますが、それはあなたの質問とは無関係です。
リクエストがこのプロセスを通過する際、ホスト名が異なるとアプリケーションごとに別々のAppDomainに移動する場合がありますが、AppDomainを作成してルーティングするためのコードを自分で作成しない限り、同じアプリケーション内のAppDomainには移動しませんそこの要求。