HTTP リスナー

各仮想サーバーは、1 つまたは複数の HTTP リスナーを通じてサーバーとクライアントの間の接続を提供します。各 HTTP リスナーは、IP アドレス、ポート番号、サーバー名、およびデフォルトの仮想サーバーを持つ待機ソケットです。

HTTP リスナーは、ポート番号と IP アドレスの一意の組み合わせを持つ必要があります。たとえば、IP アドレス 0.0.0.0 を指定すると、HTTP リスナーは設定されたすべての IP アドレスをマシンの特定のポートで待機できます。また、各リスナーに一意の IP アドレスを指定した上で、同一ポートを使用することもできます。

HTTP リスナーは IP アドレスとポート番号の組み合わせであるため、IP アドレスが同じでポート番号が異なる HTTP リスナーや (例: 1.1.1.1:8081 および 1.1.1.1:8082)、IP アドレスが異なっていてポート番号が同じ HTTP リスナー (例: 1.1.1.1:8081 および 1.2.3.4:8081。ただし、マシンがこれら両方のアドレスに応答するように設定されている場合) を複数使用することができます。

ただし、HTTP リスナーに単一のポート上ですべての IP アドレスを待機する 0.0.0.0 を使用する場合は、この同じポート上に、特定の IP アドレスを待機する HTTP リスナーを作成できません。たとえば、HTTP リスナーが 0.0.0.0:8080 (ポート 8080 のすべての IP アドレス) を使用する場合、別の HTTP リスナーが 1.2.3.4:8080 を使用することはできません。

通常、Application Server が稼動するシステムでアクセスできる IP アドレスは 1 つだけであるため、HTTP リスナーは、ポートが異なる 0.0.0.0 IP アドレスを通常使用し、役割ごとに異なるポート番号を使用します。システムが複数の IP アドレスにアクセスできる場合は、各アドレスを異なる役割に使用できます。

デフォルトでは、Application Server を起動すると、次の HTTP リスナーが準備されます。

• 仮想サーバー server に関連付けられた 2 つの HTTP リスナー http-listener-1 および http-listener-2。http-listener-1 ではセキュリティーが無効になり、http-listener-2 ではセキュリティーが有効になります。

• 仮想サーバー __asadmin に関連付けられた HTTP リスナー admin-listener。このリスナーでは、セキュリティーが有効になります。

これらのリスナーはすべて、Application Server のインストールの間に HTTP サーバーポート番号として指定された IP アドレス 0.0.0.0 とポート番号を使用します。Application Server がポート番号のデフォルト値をそのまま使用した場合、http-listener-1 はポート 8080、http-listener-2 はポート 8181、admin-listener はポート 4849 を使用します。

各 HTTP リスナーはデフォルトの仮想サーバーを持ちます。デフォルトの仮想サーバーは、HTTP リスナーがその HTTP リスナーに関連付けられたどの仮想サーバーともホストコンポーネントが一致しないすべての要求 URL をルーティングする宛先のサーバーです。仮想サーバーと HTTP リスナーの関連付けは、仮想サーバーの http-listeners 属性に HTTP リスナーを指定することで行われます。

さらに、HTTP リスナー内のアクセプタスレッドの数を指定します。アクセプタスレッドは、接続を待機するスレッドです。アクセプタスレッドによって受け付けられ、接続キューと呼ばれるキューに入れられた接続は、ワークスレッドによって取り出されます。新しい要求が着信したときにいつでも対応できるように、常に十分な数のアクセプタスレッドを設定しておきますが、システムに負荷がかかり過ぎない数に抑える必要もあります。接続キューには、アクセプタスレッドによって受け付けられた新しい接続と、キープアライブ接続管理サブシステムによって管理される持続接続の両方が格納されます。

一連の要求処理スレッドが、接続キューから受信 HTTP 要求を取り出し、それらの要求を処理します。これらのスレッドは、HTTP ヘッダーを解析し、適切な仮想サーバーを選択し、要求処理エンジンを実行して要求を処理します。処理すべき要求がなくなったあと、その接続が HTTP/1.1 を使用するか Connection: keep-alive ヘッダーを送信することで持続可能になっていた場合、要求処理スレッドは、その接続がアイドル状態にあると判断し、その接続をキープアライブ接続管理サブシステムに渡します。

キープアライブサブシステムは、そうしたアイドル状態の接続を定期的にポーリングし、活動中の接続が見つかるとそれらを接続キュー内に格納し、さらに処理できるようにします。要求処理スレッドは、そのキューから再び接続を取り出し、その要求を処理します。キープアライブサブシステムはマルチスレッド化されています。なぜなら、このサブシステムによって管理される接続の数が数万個に及ぶ可能性があるからです。効率的なポーリングテクニックに基づいて多数の接続がより少数の接続を含むサブセットへと分割され、どの接続で要求の準備が整ったか、あるいはどの接続のアイドル時間が閉じてもよいほど十分長い時間になったか、つまり、最大許容キープアライブタイムアウトを超えたかが判断されます。

HTTP リスナーのサーバー名は、サーバーがクライアントに送信する URL にリダイレクトの一部として表示されるホスト名です。この属性は、サーバーが自動的に生成する URL には影響しますが、サーバーに格納されているディレクトリやファイルの URL には影響しません。サーバーがエイリアスを使っている場合、通常は、この名前はエイリアス名です。クライアントが Host: ヘッダーを送信する場合、HTTP リスナーのサーバー名の代わりにホスト名がリダイレクトに指定されます。

リダイレクトポートを指定して、元の要求に指定されているポート番号とは異なるポート番号を使用します。リダイレクトは、次のいずれかの状況で行われます。

• リソースが別の位置に移動され、クライアントのアクセス対象のリソースが指定の URL に存在しない場合、サーバーは 404 を返す代わりに指定の応答コードを返し、応答のロケーションヘッダーに新しい位置を含めることで、クライアントを新しい位置にリダイレクトします。

• 通常の HTTP ポートで SSL などによって保護されているリソースにクライアントがアクセスを試みる場合、サーバーは要求を SSL 有効ポートにリダイレクトします。この場合、サーバーは、元のセキュリティー保護されていないポートを SSL 有効ポートに置き換えた新しい URL がロケーション応答ヘッダーに指定された応答を返します。クライアントは、この新しい URL に接続します。

また、HTTP リスナーのセキュリティーを有効にするかどうか、あるいは、どのセキュリティーの種類を使用するか (例: SSL プロトコルや暗号化方式の種類) も指定します。

Application Server に配備された Web アプリケーションにアクセスするには、Web アプリケーション用に指定したコンテキストルートとともに、http://localhost:8080/ (または、セキュリティー保護されたアプリケーションでは https://localhost:8181/) という URL を使用します。管理コンソールにアクセスするには、URL https://localhost:4849/ またはそのデフォルトコンテキストルートである https://localhost:4849/asadmin/ を使用します。

仮想サーバーは既存の HTTP リスナーを指定する必要があり、ほかの仮想サーバーによってすでに使用されている HTTP リスナーを指定できないことから、新しい仮想サーバーを作成するときは、事前に少なくとも 1 つの HTTP リスナーを作成します。