Sun Java System Application Server Enterprise Edition 8.1 2005Q2 管理ガイド

- Previous: 第 11 章 トランザクション
- Next: HTTP サービスに関する管理コンソールタスク

# HTTP サービスについて

- 「HTTP サービスとは」

- 「仮想サーバー」

- 「HTTP リスナー」

## HTTP サービスとは

HTTP サービスは、Web アプリケーションの配備機能を提供する Application Server のコンポーネントで、配備された Web アプリケーションに HTTP クライアントがアクセスできるようにします。 「Web アプリケーションを配備する」を参照してください。これらの機能は、仮想サーバーと HTTP リスナーという 2 種類の関連オブジェクトによって提供されます。

## 仮想サーバー

仮想サーバーは、複数のインターネットドメイン名を同一の物理サーバーでホスティングするためのオブジェクトで、仮想ホストとも呼ばれます。同一物理サーバーにホスティングされるすべての仮想サーバーは、その物理サーバーの IP (Internet Protocol) アドレスを共有します。仮想サーバーは、サーバーのドメイン名 (`www.aaa.com` など) と、Application Server が稼動するサーバーを関連付けます。

注 –

インターネットドメインと Application Server の管理ドメインを混同しないでください。

たとえば、ある物理サーバーで次のドメインをホスティングすると仮定します。

    www.aaa.com
    www.bbb.com
    www.ccc.com

また、`www.aaa.com`、`www.bbb.com`、`www.ccc.com` には、それぞれに関連付けられた Web モジュール `web1`、`web2`、`web3` があるものとします。

つまり、その物理サーバーでは、次のすべての URL が処理されます。

    http://www.aaa.com:8080/web1
    http://www.bbb.com:8080/web2
    http://www.ccc.com:8080/web3

最初の URL は仮想ホスト `www.aaa.com`、2 番目の URL は仮想ホスト `www.bbb.com`、3 番目の URL は仮想ホスト `www.ccc.com` にそれぞれマッピングされます。

一方、`www.bbb.com` には `web3` が登録されていないため、次の URL は 404 リターンコードのエラーとなります。

    http://www.bbb.com:8080/web3

このマッピングが機能するには、`www.aaa.com`、`www.bbb.com`、`www.ccc.com` のすべてを物理サーバーの IP アドレスとして解決する必要があります。これをネットワークの DNS サーバーに登録しなければなりません。さらに、UNIX システムで、`/etc/nsswitch.conf` ファイルの `hosts` の設定に `files` が含まれる場合は、これらのドメインを `/etc/hosts` ファイルに追加します。

Application Server を起動すると、次の 2 つの仮想サーバーが自動的に起動されます。

- ユーザー定義のすべての Web モジュールをホスティングする仮想サーバー `server`

- すべての管理関連 Web モジュール (具体的には管理コンソール) をホスティングする仮想サーバー `__asadmin`。このサーバーの使用は制限されています。つまり、ユーザーがこの仮想サーバーに Web モジュールを配備することはできません。

本稼動環境以外での Web サービスの開発、テスト、配備で必要となる仮想サーバーは、通常、`server` だけです。ただし本稼動環境では、同一物理サーバー上でユーザーと顧客のそれぞれが専用の Web サーバーを持つように見せる機能をホスティングするため、通常は追加の仮想サーバーも使用されます。

## 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 リスナーを作成します。

- Previous: 第 11 章 トランザクション
- Next: HTTP サービスに関する管理コンソールタスク

- © 2010, Oracle Corporation and/or its affiliates