(57)【特許請求の範囲】
【請求項１】
インターネット（６０４）とイントラネット（６０２）との間に接続された複数のファイアウォール・サーバ（６０３）を有するＴＣＰ／ＩＰネットワークにおいて、前記イントラネットに接続されたウェブ・クライアント（６０１）用の最良のファイアウォール・サーバ（６０３）を動的に選択する方法において、
前記イントラネットに接続された単一のオートプロキシＵＲＬシステム（６０６）上に常駐する測定プローブ・プログラム（６０７）を用いて、各ファイアウォール・サーバの性能および使用可能度を測定するステップと、
前記ウェブ・クライアント用の最良のファイアウォール・サーバを選択するために、前記オートプロキシＵＲＬシステム上に、前記性能および使用可能度の測定値（６０７）に基づいてプロキシ構成ファイルを動的に作成するステップと、前記作成されたプロキシ構成ファイルを、前記オートプロキシＵＲＬシステムから前記ウェブ・クライアントに周期的にダウンロードするステップと、
前記ダウンロードされたプロキシ構成ファイルに従って、前記ウェブ・クライアント用の最良のファイアウォール・サーバを前記ウェブ・クライアントにおいて動的に選択するステップとを含み、
前記性能および使用可能度を測定するステップは、
各ファイアウォール・サーバを経て、前記インターネットに接続されたウェブ・サーバ（６０５）との接続を確立するステップ（４０２）と、
前記ウェブ・サーバから既知のウェブ・ページを検索するステップ（４０３）と、
前記既知のウェブ・ページを検索するのに要した応答時間を測定するステップ（４０６）をさらに含むことを特徴とする方法。
【請求項２】
前記応答時間を測定するステップは、
前記検索された既知のウェブ・ページが、当該ページが正確であることを確認するための既知のキーワードを含むことをチェックするステップ（４０５）と、前記既知のキーワードが前記検索された既知のウェブ・ページ内に含まれる場合にのみ、前記測定された応答時間を確定するステップ（４０６）とをさらに含むことを特徴とする、請求項１に記載の方法。
【請求項３】
前記性能を測定するステップは、
各ファイアウォール・サーバごとに、前記測定された応答時間を、以前に測定された応答時間と比較するステップと、
各ファイアウォール・サーバごとに、前記測定された応答時間の低下または改良を判別するステップとをさらに含むことを特徴とする、請求項１または２に記載の方法。
【請求項４】
前記使用可能度を測定するステップは、
前記ウェブ・サーバからの応答がない場合、各ファイアウォール・サーバの障害を検出するステップと、
前記障害のあるファイアウォール・サーバを選択不可能としてマークするステップとをさらに含むことを特徴とする、請求項１に記載の方法。
【請求項５】
前記プロキシ構成ファイルは、前記オートプロキシＵＲＬシステム上に常駐するＣＧＩプログラム（６０８）によって作成されることを特徴とする、請求項１に記載の方法。
【請求項６】
前記プロキシ構成ファイルを動的に作成するステップは、
複数のファイアウォール・サーバが実質的に同等の測定値を有する場合、前記ウェブ・クライアント用の最良のファイアウォール・サーバを、当該複数のファイアウォール・サーバのＩＰアドレスに従って選択するステップをさらに含むことを特徴とする、請求項１に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータ・ネットワークに関し、特に、所定の応答時間および使用可能度の基準に従って、ＴＣＰ／ＩＰネットワーク内でウェブ・ファイアウォール（Ｗｅｂ  Ｆｉｒｅｗａｌｌ）を最適に選択する方法に関する。
【０００２】
【従来の技術】
インターネット（ＩＮＴＥＲＮＥＴ）
インターネットは、コンピュータおよびコンピュータ・ネットワークよりなるグローバル・ネットワーク（“ネット（Ｎｅｔ）”）である。インターネットは、ＵＮＩＸ，ＤＯＳ，Ｗｉｎｄｏｗｓ，Ｍａｃｉｎｔｏｓｈなどを含む、種々の異なるオペレーティング・システムまたは言語を用いるコンピュータに接続する。これら種々のシステムおよび言語間の通信を容易かつ可能にするために、インターネットは、ＴＣＰ／ＩＰ（“伝送制御プロトコル／インターネット・プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ”）と呼ばれる言語を用いる。ＴＣＰ／ＩＰプロトコルは、インターネット上で以下の３つの基本的なアプリケーションをサポートする。
・電子メールの送信および受信
・リモート・コンピュータへのログイン（“テルネット（Ｔｅｌｎｅｔ）”）
・一つのコンピュータから他のコンピュータへのファイルおよびプログラムの転送（“ＦＴＰ”、すなわち“ファイル転送プロトコル（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ”）
ワールド・ワイド・ウェブ（ＷＯＲＬＤ  ＷＩＤＥ  ＷＥＢ）
インターネットの規模および複雑性が増大するにつれて、ナビゲータまたはナビゲーション・システムと呼ばれる、ネットワーク上の情報の検索を支援するツールが開発されてきた。開発されたナビゲーション・システムは、Ａｒｃｈｉｅ，Ｇｏｐｈｅｒ，およびＷＡＩＳのような標準のものを含む。ワールド・ワイド・ウェブ（“ＷＷＷ”、または“ウェブ（Ｗｅｂ）”）は、最近の優れたナビゲーション・システムである。ウェブは、
・インターネットをベースにしたナビゲーション・システム，
・インターネットのための情報配布管理システム，
・ウェブ上で通信するための動的フォーマットである。
【０００３】
ウェブは、その使用のために、静止画，テキスト，オーディオ，およびビデオを含む情報のフォーマットを完全に統合する。グラフィカル・ユーザ・インターフェース（“ｇｏｏｅｙ”と発音される“ＧＵＩ”）を用いるウェブ上のユーザは、システム上の種々のホスト・コンピュータ，種々のシステム・アプリケーション（ＦＴＰおよびテルネットを含む），ファイルおよびドキュメントのための種々の情報フォーマット（例えば、テキスト，サウンド，およびグラフィックを含む）とトランスペアレントに通信することができる。
【０００４】
ハイパーメディア（ＨＹＰＥＲＭＥＤＩＡ）
ウェブは、ハイパーテキストおよびハイパーメディアを使用する。ハイパーテキストは、ハイパーメディアのサブセットであり、コンピュータをベースにした“ドキュメント（ｄｏｃｕｍｅｎｔ）”に関係する。ハイパーテキストでは、リーダーは、ドキュメント内で一つの場所から他の場所へ、または他のドキュメントへ、ノンリニアに移動する。これを実行するために、ウェブは、クライアント・サーバ・アーキテクチャーを用いる。ウェブ・サーバは、ユーザが、ウェブおよびユーザのコンピュータによって、ハイパーテキストおよびハイパーメディアの情報にアクセスすることを可能にする（ユーザのコンピュータは、ウェブ・サーバ・コンピュータのクライアント・コンピュータと呼ばれる）。クライアントは、ウェブ・サーバにリクエストを送信し、ウェブ・サーバは、反応し，検索し，応答する。ウェブは、クライアント・アプリケーション・ソフトウェアが、リクエストし、ウェブ・ファイル・サーバから、他のハイパーメディア・ドキュメントへのハイパーテキスト・リンクの機能を有するハイパーメディア・ドキュメント（フォーマットされたテキスト，オーディオ，ビデオ，およびグラフィックを含む）を受信することを可能にする。
【０００５】
したがって、ウェブは、ネットワーキング・プロトコルを用いてハイパーリンクによって相互接続され且つインターネットにまたがるバーチャル“ウェブ（Ｗｅｂ）”を形成する、多数のウェブ・ホスト・コンピュータ上に常駐するドキュメント・ファイルの集合として考えることができる。
【０００６】
ユニフォーム・リソース・ロケータ（ＵＮＩＦＯＲＭ  ＲＥＳＯＵＲＣＥ  ＬＯＣＡＴＯＲＳ）
インターネットのリソースは、特定のロケーションにおける特定のリソースに対するポインタであるユニフォーム・リソース・ロケータ（ＵＲＬ）によって正確に識別される。ＵＲＬは、サーバにアクセスするために用いられるプロトコル（例えば、ＨＴＴＰ，ＦＴＰ，・・・），サーバ名，およびそのサーバ上のファイルのロケーションを特定する。
【０００７】
ハイパーテキスト転送プロトコル（ＨＹＰＥＲ  ＴＥＸＴ  ＴＲＡＮＳＦＥＲＰＲＯＴＯＣＯＬ）
ウェブのクライアント・モニター上に現れる各ウェブ・ページは、例えば、テキスト，イメージ，サウンド，およびアニメーションを統合する複雑なドキュメントして現れ得る。また、このようなページの各々は、他のウェブ・ドキュメントへのハイパーリンクを含み、クライアント・コンピュータのユーザは、マウスを使用してアイコンをクリックし、同じか異なるウェブ・サーバ上に、新しいページ（他のドキュメント・ファイルのグラフィカル表示である）へのハイパーリンク・ジャンプを起動することができる。
【０００８】
ウェブ・サーバは、典型的にはインターネットを通じてウェブ・クライアントからのリクエストに応答するウェブ・ホスト・コンピュータ上のソフトウェア・プログラムである。全てのウェブは、ウェブ・クライアントと通信するために、ハイパーテキスト転送プロトコル（“ＨＴＴＰ”）と呼ばれる言語またはプロトコルを使用する。全ての種類のデータは、ハイパーテキスト・マークアップ言語（“ＨＴＭＬ”），グラフィック，サウンド，およびビデオを含むこのプロトコルを用いて、ウェブ・サーバとクライアントとの間で交換することができる。ＨＴＭＬは、ドキュメントおよびページのレイアウト，コンテンツ，およびハイパーリンクを記述する。ウェブ・クライアントは、ブラウズするときに、
・ユーザ指定のコマンドを、ＨＴＴＰ  ＧＥＴリクエストに変換し，
・情報を入手するために、適切なウェブ・サーバに接続し，
・レスポンスを待つ。サーバからのレスポンスは、リクエストされたドキュメントまたはエラーメッセージとすることができる。
【０００９】
ドキュメントまたはエラーメッセージが返信された後、ウェブ・クライアントとウェブ・サーバとの間の接続が閉じられる。
【００１０】
ＨＴＴＰの最初のバージョンは、ステートレス（ｓｔａｔｅｌｅｓｓ）プロトコルである。これは、各クライアントと各サーバとの間に継続接続がないＨＴＴＰと一致する。ウェブ・クライアントは、ＨＴＴＰを用いて、ＨＴＭＬデータまたは他のデータとしてレスポンスを受信する。この記述は、ＨＴＴＰプロトコルのバージョン１．０に適合するが、新バージョン１．１は、ある条件下においてサーバとクライアントとの間の接続を保持することによって、ステートレス・プロトコルのこの障害を克服する。
【００１１】
ブラウザ（ＢＲＯＷＳＥＲ）
受信後、ウェブ・クライアントは、データをフォーマットして送るか、または、サウンド・プレーヤのような補助的アプリケーションを起動してデータを送る。これを行うために、サーバまたはクライアントは、受信データの種々のタイプを判別する。ウェブ・クライアントは、実際にウェブ・サーバから検索されたドキュメントをブラウズするので、ウェブ・ブラウザとも呼ばれる。
【００１２】
ドメイン名（ＤＯＭＡＩＮ  ＮＡＭＥＳ）
ＤＮＳ（“ドメイン名サービス（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｅｒｖｉｃｅ）”）と呼ばれる方法を用いることによって、ホスト名またはコンピュータ名（ｗｗｗ．ｅｎｔｒｅｐｒｉｓｅ．ｃｏｍのような）は、数字のインターネット・アドレス（１９４．５６．７８．３のような）に変換され、あるいはこの逆に変換される。ＤＮＳは、ドメイン名サーバすなわちＤＮＳサーバとしても知られている、ネットワーク常駐サーバによってサポートされる。
【００１３】
イントラネット（ＩＮＴＲＡＮＥＴ）
幾つかの会社は、ウェブと同じ機構を用いて、社内で通信している。この場合、この機構は、“イントラネット（Ｉｎｔｒａｎｅｔ）”と呼ばれる。これらの会社は、同じネットワーキング／トランスポート・プロトコルと、ローカル・ベースのウェブ・サーバとを用い、コヒーシブ（ｃｏｈｅｓｉｖｅ）に広大な量の会社情報へのアクセスを与える。このデータは会社専用のものである。しかし、依然として、その会社の社員が公衆ウェブ情報へアクセスすることを必要とするので、その会社の社員でない人々が、公衆インターネットを用いてこの専用イントラネットにアクセスできないようにするためには、これらの会社は、ファイアウォールと呼ばれる特殊な装置を用いることによって、これらの会社のネットワークへのアクセスを保護する。
【００１４】
ファイアウォール（ＦＩＲＥＷＡＬＬ）
ファイアウォールは、インターネットに接続された外部コンピュータによるアクセスから、インターネット接続を有する１台以上のコンピュータを保護する。ファイアウォールは、一般に、ハードウェアおよびソフトウェアによって作成されるネットワーク構成であり、ファイアウォール内側のネットワーク化されたコンピュータと、ファイアウォール外側のコンピュータとの間に境界を形成する。ファイアウォール内側のコンピュータは、内部アクセス機能を有する安全なサブネットワークと、外側のコンピュータからは使用できない共有リソースとを形成する。
【００１５】
ファイアウォールが設けられる１台のマシンは、内側および外側のコンピュータの両方にアクセス可能である。ファイアウォールが設けられたコンピュータは、インターネットと直接に対話するので、外部コンピュータからの不所望なアクセスに対する厳格なセキュリティ手段が要求される。
【００１６】
ファイアウォールは、一般に、電子メールのような情報と、物理的な建物または組織サイト内のデータ・ファイルとを保護するために使用される。ファイアウォールは、未承認の人々によるインターネットからの侵入の危険性を軽減するが、同様のセキュリティ手段は、外側の情報にアクセスすることを望むファイアウォール内側の人々のための特殊なソフトウェアを制限するか、または要求することができる。ファイルウォールは、ファイアウォールの両側からの情報へのアクセスを指定する“プロキシ（Ｐｒｏｘｉｅｓ）”または“ソックス（Ｓｏｃｋｓ）”を用いて構成することができる。
【００１７】
プロキシ・サーバ（ＰＲＯＸＹ  ＳＥＲＶＥＲ）
ＨＴＴＰプロキシは、典型的には、ファイアウォールのソフトウェアと共にランし、ファイアウォール内側からインターネットへのアクセスを可能にする特殊なサーバである。プロキシ・サーバは、
・ファイアウォール内側からのリクエスト（例えば、ＨＴＴＰリクエスト）を待ち，
・ファイアウォール外側のリモート・サーバへリクエストを送信し，
・レスポンスを読み取り，
・レスポンスをクライアントへ返信する。
【００１８】
１台のコンピュータで、各サーバ接続がポート番号で識別された複数のサーバをランすることができる。ＨＴＴＰサーバまたはＦＴＰサーバのようなプロキシ・サーバは、１つのポートを占有する。典型的には、接続は、各プロトコルに対して標準化されたポート番号（例えば、ＨＴＴＰ＝８０，ＦＴＰ＝２１）を用いる。その理由は、エンド・ユーザは、定義された各プロキシ・サーバに対して特定のポート番号を選択しなければならないからである。ウェブ・ブラウザは、通常、エンド・ユーザに、カスタマイズ可能なパネル内に、プロキシ・サーバのホスト名およびポート番号を設定させる。ＨＴＴＰ，ＦＴＰ，Ｇｏｐｈｅｒ，ＷＡＩＳ，およびＳｅｃｕｒｉｔｙのようなプロトコルは、通常、指定されたプロキシを有することができる。プロキシは、一般に、キャッシング，ハイレベル・ロギング，アクセス・コントロールを実行する能力については、ソックスよりも好ましい。というのは、プロキシは、各ネットワーク・サービス・プロトコルに対して特定の接続を与えるからである。
【００１９】
ソックス（ＳＯＣＫＳ）
ソックス・サーバ（ソックス・ゲートウェイとも呼ばれる）は、また、ファイアウォール内側のコンピュータがインターネットへのアクセスを得ることを可能にするソフトウェアである。ソックスは、通常、ファイアウォールの内側または上に設けられたサーバ上にインストールされる。ファイアウォール内側のコンピュータは、インターネットに到達するように、クライアントとしてソックス・サーバにアクセスする。ウェブ・ブラウザは、通常、エンド・ユーザに、カスタマイズ可能なパネル内に、ソックス・ホスト（サーバ）のホスト名およびポート番号を設定させる。幾つかのオペレーティング・システムでは、ソックス・ホストは、個別のファイル（例えば、ｓｏｃｋｓ．ｃｏｎｆ  ｆｉｌｅ）内で特定される。ソックス・サーバは、プロトコル（ＨＴＴＰ，ＦＴＰ，・・・）の下の層として働くとき、データをキャッシュすることができない（プロキシが行うように）。というのは、転送しているデータがどんな種類かを知るためにプロトコルをデコードしないからである。
【００２０】
オプション（ＯＰＴＩＯＮＳ）
ウェブ・ブラウザは、エンド・ユーザに、種々のオプションである“Ｎｏ  Ｐｒｏｘｉｅｓ”，“Ｍａｎｕａｌ  Ｐｒｏｘｙ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ”，または“Ａｕｔｏｍａｔｉｃ  Ｐｒｏｘｙ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ”のうちから選択することを要求し、エンド・ユーザのコンピュータとインターネットとの間のコンジットを指定することができる。
・インターネットへの直接接続を有するユーザは、“Ｎｏ  Ｐｒｏｘｉｅｓ”であるデフォルトを使用すべきである。
・イントラネットが１つまたは幾つかのファイアウォールによって保護されると、エンド・ユーザは、
・そのホスト名を“Ｍａｎｕａｌ  Ｐｒｏｘｙ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ”へ入力することによって、選択されたプロキシとしてこれらファイアウォールのうちの１つを選択する、あるいは
・リモート・サーバ内の共通の構成ファイルを指定することによって、ロケーション間のプロキシ属性に関して、エンタプライズ・ポリシーを自動的に参照する。これは、“Ａｕｔｏｍａｔｉｃ  Ｐｒｏｘｙ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ”を選択することによって、および、リモート・サーバ内に設けられた共通の構成ファイル（“ユニバーサル・リソース・ロケータの固有アドレス（Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）”すなわち“ＵＲＬ”）をウェブ・ブラウザに与えることによって行われる。
【００２１】
今日、ウェブ・ブラウザの大半は、ソックス・ファイアウォールを経て、全てのリクエスト（内部ホストへのリクエストも）を転送するように構成される。したがって、エンド・ユーザが内部にあるウェブをベースにしたアプリケーションへのアクセスを望むと、エンド・ユーザのリクエストは、ファイアウォールへ送られ、内部ネットワーク内へ戻される。これは、長いパス上に内部トラフィックを送り、ファイアウォール上およびネットワーク上に余分な負荷を負わせ、最悪の場合は、アプリケーションおよびエンド・ユーザがアクセスしようとしているウェブ・ページからの、エンド・ユーザが経験する応答時間を低下させる。これは、“柔軟性のない（ｎｏｎ  ｆｌｅｘｉｂｌｅ）”ソックス・アクセス（全てがソックス・サーバを経由する場合）と呼ばれる。
【００２２】
マニュアル・プロキシ構成（ＭＡＮＵＡＬ  ＰＲＯＸＹ  ＣＯＮＦＩＧＵＲＡＴＩＯＮ）
ウェブ・ブラウザにおけるマニュアル・プロキシ構成は、処理が簡単であるが、その主な欠点は、ファイアウォール（またはプロキシ）の選択が静的であるということである。最良の応答時間を与えるファイアウォールの選択のような、ファイアウォール選択のための動的な基準はない。ファイアウォールの障害は、他のアクティブなファイアウォールを指定するために、ナビゲーション・ソフトウェアのマニュアル再構成を要求する。というのは、マニュアル構成は、通常、プロトコル当たり１つのファイアウォールの定義を許容するにすぎず、バックアップ・ファイアウォールを予め構成することができないからである。ウェブ・ブラウザにおけるマニュアル・プロキシ構成の他に、ファイアウォール選択にある種の頑強性を与えるために、外部の手順を用いることができる。これらの手順は、例えば、ドメイン名サーバ（ＤＮＳ）においてエイリアスとして定義された同じ名を持つ複数のファイアウォールの使用に頼っている。しかし、エイリアスの定義に基づくこの方法は、依然として欠点を有する。というのは、例えば、ＤＮＳは、名前解析をローカルにキャッシュするウェブ・クライアントによって、名前解析のために、常に接触されている訳ではないからである。ロードおよびリクエストのディスパッチャーのような外部ハードウェア装置を用いる他の方法は、より大きな頑強性およびロード・バランシングを与えるが、追加的なおよびコストのかかるハードウェアの必要性などの欠点を依然として有している。
【００２３】
オートマチック・プロキシ構成（ＡＵＴＯＭＡＴＩＣ  ＰＲＯＸＹ  ＣＯＮＦＩＧＵＲＡＴＩＯＮ）
オートマチック・プロキシ構成（または、“オートプロキシ（ａｕｔｏｐｒｏｘｙ）”とも呼ばれる）は、ウェブ・ブラウザがスタートするごとに、ＨＴＴＰ，ＦＴＰ，Ｇｏｐｈｅｒプロキシのロケーションを設定することができる。オートプロキシは、アドレス領域のファイルを検索し、ウェブ・ブラウザに、内部ＩＢＭホストに直接アクセスするか、または、インターネット上のホストにアクセスするためにソックス・サーバに行くかを命令する。
【００２４】
オートマチック・プロキシ構成は、ウェブ・ブラウザにおける簡単なプロキシ・サーバ構成より望ましい。というのは、ウェブ・ページを検索する（直接的または間接的に）方法についてかなり複雑な規則を実現することができるからである。オートマチック・プロキシ構成がユーザにとって有用である所以は、プロキシ・サーバに障害があると、ウェブ・ブラウザは、ページの検索方法を直接的に知ることにある。また、プロキシ・リクエストは、システム管理者の自由裁量で他のまたは複数のプロキシ・サーバに送ることができ、その場合においても、エンド・ユーザは、彼のウェブ・ブラウザ構成へ追加変更を行う必要がない。一般に、これらのプロキシ構成ファイル（オートプロキシ・コードとも呼ばれる）は、通常、ジャバスクリプト（Ｊａｖａｓｃｒｉｐｔ）言語で書かれる。また、オートプロキシ機能は、ウェブ・ブラウザに対し、内部ホストに直接アクセスするか、または、インターネット上のホストにアクセスするためにソックス・サーバに行くかを命令するためのアドレス領域のファイルを持つことができる。ソックス・サーバは、不所望な公衆アクセスから内部ネットワークを保護する一方、インターネットへのネットワーク・メンバーのアクセスを許可する。この“オートプロキシ（ａｕｔｏｐｒｏｘｙ）”機構の欠点の１つは、予防のためのファイアウォールの障害検出も、応答時間の考慮も無いことである。
【００２５】
上述したドメインについてのより詳細な説明は、次の刊行物の中で見い出すことができ、その内容は、本明細書の内容に含まれる。
・１９９７年２月に、Ｏ’Ｒｅｉｌｌｙによって発行された、ＥｌｌｉｏｔｔｅＲｕｓｔｙ  Ｈａｒｏｌｄによる、“Ｊａｖａ  Ｎｅｔｗｏｒｋ  Ｐｒｏｇｒａｍｍｉｎｇ”。
・１９９７年１０月に、Ｏ’Ｒｅｉｌｌｙによって発行された、ＶａｌｅｒｉｅＱｕｅｒｃｉａによる、“Ｉｎｔｅｒｎｅｔ  ｉｎ  ａ  ｎｕｔｓｈｅｌｌ”。
・１９９５年９月に、Ｏ’Ｒｅｉｌｌｙによって発行された、Ｂｒｅｎｔ  Ｃｈａｐｍａｎ  ａｎｄ  Ｅｌｉｚａｂｅｔｈ  Ｚｗｉｃｈｋｙによる、“Ｂｕｉｌｄｉｎｇ  Ｉｎｔｅｒｎｅｔ  Ｆｉｒｅｗａｌｌｓ”。
【００２６】
【発明が解決しようとする課題】
解決しようとする課題は、最良の応答時間および障害検出を得るための動的なプロキシまたはソックス・サーバの選択を有する、最適のウェブ・アクセスと、ウェブ・サービスの中断を防止するための、プロキシまたはソックス・サーバにおける障害の検出とを提供することにある。現在の解決方法は、この問題を部分的に処理している。
・ウェブ・ブラウザを、ターゲット・プロキシまたはソックス・サーバでマニュアル的に構成することができる。この解決方法の主な欠点は、次の通りである。
【００２７】
・動的なプロキシ／ソックス・サーバの選択がない。プロキシ／ソックスのサーバの障害時に、ウェブ・ブラウザのマニュアル再構成を必要とする。
【００２８】
・ウェブ・ブラウザの静的構成により、“マニュアル”なロード・バランシングのみが与えられる。
【００２９】
・プロキシ／ソックス・サーバ名が、エンド・ユーザによって知られ、マニュアル的に構成されなければならない。
・専用のオートプロキシＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）システムからダウンロードされるターゲット・プロキシ／ソックス・サーバの静的リストを用いて、オートプロキシのフィーチャでウェブ・ブラウザを構成することができる。この解決方法の主な欠点は、次の通りである。
【００３０】
・プロキシ／ソックス・サーバの選択において応答時間の考慮がなく、プロキシ／ソックス・サーバの選択において効率的なプロキシ／ソックス・サーバの障害検出もない（すなわち、ウェブ・ブラウザは、初期のオートプロキシ・ローディングのときでも、バックアップへ切り替わる前にタイム・アウトを待つ）。
【００３１】
これらの現在の解決方法に代わる方法は、１つの論理アクセス・ポイントとして働く外部ディスパッチャー・システムを用いて、プロキシ／ソックス・サーバを統合することである。全てのウェブ・ブラウザは、トラフィックを選択されたプロキシ／ソックス・サーバへルートする外部ディスパッチャー・システム（ターゲット・プロキシ／ソックス・サーバとして）の名でマニュアル的に構成される。このようなディスパッチャーの一例として、例えば、ＩＢＭ  Ｉｎｔｅｒａｃｔｉｖｅ  Ｎｅｔｗｏｒｋ  Ｄｉｓｐａｔｃｈｅｒがある。この製品に関する詳細情報は、ＩＢＭ社発行の“Ｉｎｔｅｒａｃｔｉｖｅ  Ｎｅｔｗｏｒｋ  Ｄｉｓｐａｔｃｈｅｒ  Ｖ１．２−Ｕｓｅｒ’ｓ  Ｇｕｉｄｅ”ＧＣ３１−８４９６−０１の中で見い出すことができ、その内容は、本明細書の内容に含まれる。ディスパッチャーによる解決方法は、多くの場合、効率的なロード・バランシングを可能とするが、その主な欠点は、追加の専用システムまたは特定のハードウェアを必要とすること、および、外部ディスパッチャー名がウェブ・ブラウザのエンド・ユーザによってマニュアル的に構成されなければならないことである。
【００３２】
本発明の目的は、使用可能度および応答時間の基準を用いることによって、プロキシ／ソックス・サーバの選択を最適にすることにある。
【００３３】
本発明の他の目的は、プロキシ／ソックス・サーバの選択に応答時間ファクタを統合することによって、ウェブ・サービスの性能を最適にすることにある。
【００３４】
本発明のさらに他の目的は、ウェブ・サービスの中断を最小にし、したがって、プロキシ／ソックス・サーバの障害を自動的に検出することによって、より良好なサービス使用可能度を保証することにある。
【００３５】
【課題を解決するための手段】
本発明は、動的オートプロキシ構成に関し、特に、応答時間および使用可能度の基準に従って、プロキシ／ソックス・サーバの選択を最適にする方法に関する。本発明は、使用可能度および応答時間のプローブを用いる動的オートプロキシ機構に基づいている。
【００３６】
また、本発明は、各プロキシ／ソックス・サーバを経て周知のＨＴＭＬページを検索し、関連する応答時間を測定し、プロキシ／ソックスの障害および応答時間の低下を検出するプローブに依存する。
【００３７】
また、本発明は、プローブによって与えられた使用可能度および応答時間の情報を用いてプロキシ／ソックス・サーバを選択するために、オートプロキシＵＲＬ（ユニバーサル・リソース・ロケータ）システム上に、オートプロキシ・コード（好適な実施例では、ジャバスクリプト（Ｊａｖａｓｃｒｉｐｔ）・コード）を動的に作成するＣＧＩ（コモン・ゲートウェイ・インタフェース）プログラムを用いる。
【００３８】
本発明は、動的なプロキシ／ソックスの使用可能度および応答時間の選択基準を、オートプロキシ機構に統合することによって現在の解決方法における欠点を解消する。
【００３９】
本発明は、次の利点を与える。
・プロキシ／ソックス・サーバの障害の早期の検出は、ウェブ・サービスの高い使用可能度を与える。
・プロキシ／ソックス・サーバの選択に対する応答時間のファクタの統合は、ウェブ・サービスの性能を最適にする。
・導入されたＨＴＴＰサーベイ・トラフィックは、１つのオートプロキシＵＲＬシステムから使用可能度および応答時間のプローブをランすることによって最小になる（各ウェブ・ブラウザ・システム上のプローブをランすることと比較して）。
・プローブにおける応答時間低下の統合は、予防的なプロキシ／ソックス・サーバの障害検出を実現する。
・“最良の”プロキシ／ソックス・サーバの周期的な動的更新を、ウェブ・ブラウザに与えることができる。
・プロキシ／ソックス・サーバは、障害検出の際に、使用可能なターゲットのサーバ・リストから除外することができるので、障害のあるプロキシ／ソックス・サーバへの無用なトラフィックを最小にする。
・追加のまたは特定のハードウェアを必要としない。
・モバイル・ユーザに、ウェブ・ブラウザ構成の容易さを与える（一度、ウェブ・ブラウザが構成されると）。
・ウェブ・ブラウザの性能は、低下しない。というのは、使用可能度および応答時間のプローブは、ダウンロードされたオートプロキシ・コード（ジャバスクリプト・コード）内ではなく、オートプロキシＵＲＬシステム内で処理されるからである。
【００４０】
【発明の実施の形態】
本発明は、動的オートプロキシ構成に関し、特に、応答時間および使用可能度の基準に従ってプロキシ／ソックス・サーバを選択する方法に関する。本発明は、使用可能度および応答時間のプローブを用いる動的オートプロキシ機構に基づいている。本発明は、各プロキシ／ソックス・サーバを経て周知のＨＴＭＬページを検索し、関連する応答時間を測定し、プロキシ／ソックスの障害および応答時間の低下を検出するプローブに依存している。
【００４１】
また、本発明は、プロキシ／ソックス・サーバを選択するために、オートプロキシＵＲＬ（ユニバーサル・リソース・ロケータ）システム上に、オートプロキシ・コード（好適な実施例では、ジャバスクリプト（Ｊａｖａｓｃｒｉｐｔ）コード）を動的に作成するＣＧＩ（コモン・ゲートウェイ・インターフェース）プログラムを用いる。
【００４２】
ワールド・ワイド・ウェブにアクセスするエンド・ユーザの論理ビュー（ＬＯＧＩＣＡＬ  ＶＩＥＷ  ＯＦ  Ａ  ＥＮＤ  ＵＳＥＲ  ＡＣＣＥＳＳＩＮＧ  ＴＨＥ  ＷＯＲＬＤ  ＷＩＤＥ  ＷＥＢ）
図１は、ワールド・ワイド・ウェブ（ＷＷＷ）へのアクセスを可能にするウェブ・ブラウザ（１０１）としてして知られるプログラムをランするユーザ・インターフェース（１０２）を備えたユーザ・システムを示す。ＷＷＷコンテンツは、ＨＴＴＰプロトコルを用いて転送される。ＨＴＴＰリクエストおよびＨＴＴＰレスポンスは、ウェブ・ブラウザ・プログラム（１０１）と、ユーザがアクセスしようとするＷＷＷコンテンツを有する宛先ウェブ・サーバ（１０３）とを行き来する。ウェブ・ブラウザ（１０１）とウェブ・サーバ（１０３）との間のファイアウォール（１０４）は、ＨＴＴＰリクエストおよびＨＴＴＰレスポンスをそれらの宛先へ転送する中継ＨＴＴＰプロキシとして働く。ウェブ・ブラウザ・プログラム（１０１）は、ファイアウォール（１０４）へのＨＴＴＰリクエストを作成し、ファイアウォール（１０４）は、宛先ウェブ・サーバ（１０３）へＨＴＴＰリクストを転送する。逆方向のフローは、ウェブ・ブラウザ（１０１）への途中にあるファイアウォール（１０４）を経て再び進むＨＴＴＰレスポンスである。このようにして、ファイアウォールは、（定義されたセキュリティおよびアクセス制御ポリシーに基づいて）可能となるように構成されるトランザクションへのトラフィックを制限することができる。したがって、ファイアウォールは、ウェブ・ブラウザが配置されるネットワークを保護する。
【００４３】
ＷＷＷにアクセスするエンド・ユーザの一般物理ビュー（ＧＥＮＥＲＡＬ  ＰＨＹＳＩＣＡＬ  ＶＩＥＷ  ＯＦ  ＡＮ  ＥＮＤ  ＵＳＥＲ  ＡＣＣＥＳＳＩＮＧ  ＴＨＥ  ＷＷＷ）
図２は、図１に論理的に示されたセットアップの物理ビューである。この特定の例では、ウェブ・ブラウザ（２０１）は、イントラネット（２０２）に接続されたシステム上でランする。イントラネットを保護するファイアウォール（２０３）は、（専用の）イントラネット（２０２）および（公衆の）インターネット（２０４）の両方に接続する。宛先ウェブ・サーバ（２０５）もまた、インターネットに接続する。これは、ユーザがインターネットＷＷＷを“ブラウジング（ｂｒｏｗｓｉｎｇ）”しているときに、ウェブ・ブラウザ，ファイアウォール，およびウェブ・サーバが、それらの機能を実行する環境である。ファイアウォールは、２つのネットワークに接続し、したがって、２つのネットワーク間の通信の中継装置として働くことができるという事実に注意することが重要である。ある程度のアクセス頑強性およびロード・シェアリングを与えるためには、多くの場合、複数のファイアウォールが用いられる。
【００４４】
使用可能度および応答時間のプローブの論理ビュー（ＬＯＧＩＣＡＬ  ＶＩＥＷ  ＯＦ  ＡＶＡＩＬＡＢＩＬＩＴＹ  ＡＮＤ  ＲＥＳＰＯＮＳＥ  ＴＩＭＥ  ＰＲＯＢＥＳ）
本発明のドメインは、図１および図２で説明したドメインであり、そこで、イントラネット内のユーザは、ウェブ・ブラウザを用いてワールド・ワイド・ウェブにアクセスすることを望み、また、イントラネット・ネットワークは、いわゆるＨＴＴＰプロキシという役割を果たす幾つかのファイアウォールによって、インターネットから保護される（図２）。問題は、エンド・ユーザへのサービスの最適な使用可能度および応答時間を保証するために、“最良の”プロキシ／ソックス・サーバを選択することである。この選択を自動的に最適化するためには、“使用可能度および応答時間のプローブ（ＷＷＷ  ａｖａｉｌａｂｉｌｉｔｙ  ａｎｄ  ｒｅｓｐｏｎｓｅ  ｔｉｍｅ  ｐｒｏｂｅ）”と呼ばれるソフトウェア・コンポーネントが導入される。その役割は、選択基準を与えることである。図３に示すように、このデータは、周知のウェブ・サーバの特定のコンテンツを要求するための応答時間を測定することによって収集される。単一のオートプロキシＵＲＬシステムにより、使用可能度および応答時間のプローブをランすることによって（各ウェブ・ブラウザ・クライアント・システム上でのプローブをランすることに対して）、発生するＨＴＴＰサーベイ・トラフィックは最小になる。
【００４５】
図３は、フレキシブルなＷＷＷの使用可能度および応答時間のプローブの機能と、プローブが、ＨＴＴＰのプロキシ・サーバおよびソックス・サーバの両方の使用可能度および応答時間の測定値を収集するのに用いることができる方法とを示す。図３の上側の部分は、ＨＴＴＰプロキシ・サーバ（３０４）とプローブとの対話を示している。プローブをランするクライアント・システム（３０２）（プロキシをテストするように構成された）は、基本的には、図１に示す方法と同様に、プロキシ・サーバ（３０４）を経由してウェブ・サーバ（３０７）から、ウェブ・コンテンツ（ページ）をリクエストする。この場合、ＨＴＴＰリクエストは、プロキシ・サーバへの“ＨＴＴＰサーベイ・フロー（ＨＴＴＰ  ｓｕｒｖｅｙ  ｆｌｏｗ）”（３０３）を示す。プロキシ・サーバは、ウェブ・サーバへリクエストを転送する（３０６）（図示しないファイアウォール（３０５）を経由して）。クライアント・システムは、リクエスト／レスポンスのＨＴＴＰサーベイ・フローがどのくらい時間がかかるかを計り、この情報を、テストされたプロキシ・サーバを経由した応答時間および使用可能度の測定値（テストされたウェブ・コンテンツのサンプルに対する）として用いる。また、クライアント・システムが、オートプロキシＵＲＬシステム（３０１）ならば、各プロキシ・サーバに対するこの測定情報を用いて、使用すべき“最良の”プロキシ・サーバを選定することができる。その際、使用すべき正しいプロキシ・サーバを選定するために、ウェブ・ブラウザ・プログラムを用いるように、オートプロキシＵＲＬで、この測定情報をエンコードすることができる。
【００４６】
図３の下側の部分は、同様の装置を示すが、この場合、測定データは、ソックス・サーバ（ゲートウェイ）のアクセス方法のために収集されている。また、クライアント・プローブ（３０９）は、ソックス・サーバ（３１１）を経て、宛先ウェブ・サイト（３１３）へ転送する（３１２）“ＨＴＴＰサーベイ・フロー（ＨＴＴＰ  ｓｕｒｖｅｙ  ｆｌｏｗ）”（３１０）を示すＨＴＴＰリクエストを作成する。このＨＴＴＰリクエストは、ターゲット・ウェブ・サーバ上に存在することが知られている１組のターゲットＵＲＬ（３０８）のためのものである。また、１組のソックス・サーバ（または、上記の場合、ＨＴＴＰプロキシ）の相対的性能を考慮するオートプロキシＵＲＬを作成するのに用いることができる測定データを与えることは、このサーベイがどのくらい時間がかかるかを計ることである。
【００４７】
明らかに、ＨＴＴＰサーベイ・フローに対するレスポンスがなければ、テストされている特定のプロキシ・サーバまたはソックス・サーバは、選択不可能としてマークすることができる。このようにして、働かないプロキシ・サーバまたはソックス・サーバを選択しないように、オートプロキシＵＲＬを用いることができる。
【００４８】
使用可能度および応答時間のプローブの内部論理（ＩＮＴＥＲＮＡＬ  ＬＯＧＩＣ  ＯＦ  ＴＨＥ  ＡＶＡＩＬＡＢＩＬＩＴＹ  ＡＮＤ  ＲＥＳＰＯＮＳＥ  ＴＩＭＥ  ＰＲＯＢＥＳ）
プローブ自体の内部機構を、図４で説明する。プローブは、ターゲット・プロキシ／ソックス・サーバを経て（そのホスト名およびポートを参照として用いて）、ターゲットＵＲＬからのウェブ・ページを、ＨＴＴＰ接続によりリクエストすることによって、ウェブ・クライアントをシミュレートする。ウェブ・ページは、通常のＨＴＴＰ接続により、あるいは、ソックス化された（ｓｏｃｋｓｉｆｉｅｄ）フロー（ソックス・サーバを経るフロー）によって検索される。典型的には、通常のフローは、プロキシ・サーバからまたはウェブ・サーバからのウェブ・ページを検索するのに用いられるが、ソックス化されたフローは、ソックス・サーバを経てウェブ・ページを検索するのに用いられる。次に、プローブは、ウェブ・ページが以下のことであることを基本的にチェックする。
・ウェブ・ページが、秒単位の許容時間内で受信されること、および
・受信されたページが正確であることを確認するための特定のキーワードを含むこと。
これら２つの条件が満たされると、ウェブ・ページの検索は成功である。
【００４９】
最後に、プローブは、秒単位の関連する応答時間（成功的な検索）、または障害のリターン・コードのいずれかを返信する。この機構は、１つまたは複数のターゲット・ウェブ・ページを検索する。複数のウェブ・ページが検索されると、プローブ・プログラムは、１つのウェブ・ページ検索が成功するか、または、全てのウェブ・ページ検索が失敗するまで、各ウェブ・ページを連続的にテストする。
【００５０】
プローブは、
・各プロキシ／ソックス・サーバを経て、周知のＨＴＭＬページを検索し、
・関連する応答時間を測定し、さらに、
・プロキシ／ソックス・サーバの障害および応答時間の低下を検出する。
【００５１】
図４は、図３に示されたＷＷＷの使用可能度および応答時間のプローブの内部論理フローを示すフローチャートである。
・プローブ・プログラムが行う最初のことは、タイマーをスタートすることである（４０１）。
・次に、プローブ・プログラムは、ターゲットＵＲＬ（ユニバーサル・リソース・ロケータ）でウェブ・ページを検索するために、ターゲット・ウェブ・サーバとの接続を確立しようと試みる（４０２）。プローブ・プログラムは、構成された方法に従って、例えば、ＨＴＴＰプロキシ・サーバを経て、ソックス・サーバ（ゲートウェイ）を経て、あるいは直接に接続を確立する。
・接続を確立する試みが成功しないと、プローブ・プログラムは、直ちにエラー・モードに入る（４０８）。エラー値が、プローブ・プログラムによって返信され、接続が可能でないことを示す（４０７）。
・接続を確立する試みが成功すると、ウェブ・ページは、プローブ・プログラムによって検索される（４０３）。
・次に、プローブ・プログラムは、通常のＨＴＴＰプロトコル手順に従って接続を閉じる（４０４）。
・次に、ウェブ・ページが正確に検索されたことを確認するために、プローブ・プログラムは、ウェブ・ページ内にあると予測される既知のキーワードをサーチする（４０５）。
・キーワードがウェブ・ページ内で見つかると（４０６）、ウェブ・ページの検索は成功である。タイマーは停止し、処理に対する正確な応答時間が返信される。測定された応答時間の短い履歴を時間にわたって記憶し統合することによって、プローブ・プログラムは、応答時間の低下を検出して返信することができ、したがって、プロキシ／ソックス・サーバの障害の予知を可能にする。
・しかし、正確なキーワードがウェブ・ページ内に見つからないと（４０７）、ウェブ検索は不成功であり、エラー値が再び返信される。この種のエラーを引き起こすイベントの種類は、接続が完全に確立されているが、エラーを有するウェブ・ページが検索されるときである。
・プローブが再試行モード（４０９）に入る処理は、プローブが１つのＵＲＬとは対照的に複数の宛先ＵＲＬを試行するように構成されるときのみ発生する。これは、プローブのテスティングに頑強性を付加し、したがって、ワン−オフ（ｏｎｅ−ｏｆｆ）ネットワークの“障害（ｇｌｉｔｃｈｅｓ）”（例えば、ドロップされた接続など）からプローブを分離する。
【００５２】
使用可能度および応答時間のプローブの外部フローの物理ビュー（ＰＨＹＳＩＣＡＬ  ＶＩＥＷ  ＯＦ  ＡＶＡＩＬＡＢＩＬＩＴＹ  ＡＮＤ  ＲＥＳＰＯＮＳＥ  ＴＩＭＥ  ＰＲＯＢＥＳ  ＥＸＴＥＲＮＡＬ  ＦＬＯＷＳ）
ウェブ・ブラウザが最良のプロキシ／ソックス・サーバを備えるためには、プローブは、種々のコンポーネントによって、また種々のフローで使用される（図５および図６）。プローブによって収集されたデータは、オートプロキシ機構を用いることによって、ウェブ・ブラウザに間接的にダウンロードされる。本発明は、追加のまたは特定のハードウェアなしに、ソフトフェアを実現することを可能にする。
【００５３】
図７に示すように、プローブからの出力は、オートプロキシＵＲＬシステムに格納され、オートプロキシ・コード（好適な実施例では、ジャバスクリプト・コード）を作成するのに用いられる。コードの内側では、余分な処理はない。使用可能度および応答時間のプローブは、ダウンロードされたオートプロキシ・コード（ジャバスクリプト・コード）内ではなく、オートプロキシＵＲＬシステム内で処理されるので、ウェブ・ブラウザの性能は低下しない。
【００５４】
ＣＧＩ（コモン・ゲートウェイ・インターフェース）プログラムは、プローブによって与えられる使用可能度および応答時間の情報によって、図８に示されるように、オートプロキシ・コードを動的に作成する。プローブによってプロキシ／ソックス・サーバを選択するために、応答時間および使用可能度の基準を使用することは、クライアントのオリジン（ｏｒｉｇｉｎ）ＩＰサブネットのような既存の基準と、完全にコンパチブルであり、組み合わせることができる。
【００５５】
また、応答時間および使用可能度の基準の使用は、応答時間の低下の統合により、予防的なプロキシ／ソックス・サーバの障害検出を与える。ウェブ・ブラウザは、“最良の”プロキシ／ソックス・サーバの新しい選択で、以下のものを用いて、周期的かつ動的に更新することができる。
・オートプロキシ・コード内の“リフレッシュ”タグ，
・外部コード（またはジャバ・アプレット（Ｊａｖａ  ａｐｐｌｅｔ），または・オートプロキシ・コードを周期的かつ自動的にリフレッシュするためのウェブ・ブラウザの新しいフィーチャ。
【００５６】
他の有利な結果は、障害のあるプロキシ／ソックス・サーバへの不使用のトラフィックを最小にすることである。というのは、プロキシ／ソックス・サーバは、障害の検出時に、使用可能なターゲット・サーバのリストから除外されるからである。オートプロキシ機構が用いられるので、プロキシ／ソックス・サーバの障害の場合、ウェブ・ブラウザのマニュアルプロキシ構成をマニュアル的に更新する必要はない。プロキシ／ソックス・サーバ名またはロケーションは、エンド・ユーザによって知られたり、構成される必要はなく、したがって、例えば、モバイル・ユーザに対して継続したサービスを提供する。
【００５７】
図５は、図３で説明した論理環境の物理ビューである。イントラネット（５０２）に接続されたウェブ・ブラウザ（５０１）は、オートプロキシＵＲＬを用いるように構成され、インターネット（５０４）および宛先ウェブ・サーバ（５０５）へアクセスするために、どのプロキシ／ソックス・サーバ（ファイアウォール）（５０３）を使用すべきかを判別する。また、オートプロキシＵＲＬが常駐するシステム（５０６）は、プロキシ／ソックス・サーバをテストするように構成された、使用可能度および応答時間のプローブ（５０７）をランする。オートプロキシＵＲＬは、ＣＧＩ（コモン・ゲートウェイ・インターフェース）（５０８）を用いて、オートプロキシＵＲＬのオートプロキシ・コードを動的に作成する。オートプロキシ・コードは、使用可能度および応答時間のプローブによって収集された情報に基づく。このように、ウェブ・ブラウザは、以下のもので構成される。
【００５８】
使用可能なプロキシ／ソックス・サーバ，および
最良のプロキシ／ソックス・サーバと思われるもの。
【００５９】
使用可能度および応答時間のプローブのデータフロー（ＤＡＴＡ  ＦＬＯＷＳＯＦ  ＡＶＡＩＬＡＢＩＬＩＴＹ  ＡＮＤ  ＲＥＳＰＯＮＳＥ  ＴＩＭＥ  ＰＲＯＢＥＳ）
図６は、図５に示されたエンティティと関連する実際のデータフロー図である。イントラネット（６０２）に接続されたウェブ・ブラウザ（６０１）は、オートプロキシＵＲＬを用いるように構成され、インターネット（６０４）および宛先ウェブ・サーバ（６０５）へアクセスするために、どのプロキシ／ソックス・サーバ（ファイアウォール）（６０３）を使用するかを判別する。ウェブ・ブラウザは、オートプロキシＵＲＬシステム（６０６）へアクセス（６０９）して、まず、どのプロキシ／ソックス・サーバを使用すべきかを判別する。ウェブ・ブラウザは、 “最良の”プロキシ／ソックス・サーバで、以下のものを用いて、周期的かつ動的に更新することができる。
・オートプロキシ・コード内の“リフレッシュ（ｒｅｆｒｅｓｈ）”タグ，
・外部コード（またはジャバ・アプレット），または
・オートプロキシ・コードを周期的かつ自動的にリフレッシュするためのウェブ・ブラウザの新しいフィーチャ。
【００６０】
オートプロキシＵＲＬが常駐し、使用可能度および応答時間のプローブ（６０７）をランするシステムは、ＣＧＩ（コモン・ゲート・インターフェース）（６０８）を用いて、オートプロキシＵＲＬのオートプロキシ・コード（６１０）を動的に作成する。オートプロキシ・コードは、図３で説明したＨＴＴＰサーベイ・フロー（６１１および６１２）によってプロキシ／ソックス・サーバをテストした、使用可能度および応答時間のプローブによって収集された情報に基づく。このようにして、ウェブ・ブラウザは、最良のプロキシ／ソックス・サーバと思われるもので終了する。
【００６１】
使用可能度および応答時間のプローブの内部格納（ＩＮＴＥＲＮＡＬ  ＳＴＯＲＡＧＥ  ＯＦ  ＡＶＡＩＬＡＢＩＬＩＴＹ  ＡＮＤ  ＲＥＳＰＯＮＳＥ  ＴＩＭＥ  ＰＲＯＢＥＳ）
図７は、使用可能度および応答時間のプローブ（７０１）によって検索された情報の、オートプロキシＵＲＬシステム内での内部格納を示す。各プローブは、テストする各プロキシ／ソックス・サーバの測定値によって、オートプロキシＵＲＬシステム（７０３）内のテーブルを更新する（７０２）。このようにして、テーブルは、ウェブ・ブラウザによって選択され使用される候補である全てのプロキシ／ソックス・サーバの現在の状態を含む。プローブは、構成可能なまたは周期的な時間間隔で、プロキシ／ソックス・サーバ（７０４）を再度テストし、そのサイクルを再度繰り返す。
【００６２】
オートプロキシＵＲＬシステムでランするプログラム（ＰＲＯＧＲＡＭ  ＲＵＮＮＩＮＧ  ＡＴ  ＡＵＴＯＰＲＯＸＹ  ＵＲＬ  ＳＹＳＴＥＭ）
図８はまた、オートプロキシＵＲＬシステム上でランするプログラムの内部論理を示す。
・オートプロキシＵＲＬシステムは、最初にウェブ・ブラウザによって接続され（８０１）、どれが使用すべき最良のプロキシ／ソックス・サーバ（またはファイアウォール）であるかが“分かる（ｋｎｏｗ）”ことを待つ。これは、例えば、ウェブ・ブラウザ内のオートマチック・プロキシ構成のオプションを選択することによって、および、オートプロキシ・コードのＵＲＬのような情報を与えることによって実現される。
・オートプロキシＵＲＬシステムは、ＣＧＩ（コモン・ゲートウェイ・インターフェース）プログラムを、（ウェブ・サーバのＣＧＩの拡張部によって）起動する（８０２）。ＣＧＩプログラムは、ウェブ・ブラウザのＩＰ（インターネット・プロトコル）アドレスを含む全ての標準的なＣＧＩ変数へアクセスする。
・ＣＧＩプログラムは、ウェブ・ブラウザのＩＰアドレス（ＣＧＩ変数として得られる）と、各プロキシ／ソックス・サーバの使用可能度および応答時間のプローブによって作成され、オートプロキシＵＲＬシステムのテーブル（８０７）に格納された情報とに基づいて、クライアント・システム（ウェブ・ブラウザ）のための最良のプロキシ／ソックス・サーバを選択する（８０３）。ＩＰアドレスは、プロキシ／ソックス・サーバの選択に地理的基準を付加するのに用いられる。例えば、２つのプロキシ／ソックス・サーバが、同じ応答時間を与えると（一方は米国，他方はヨーロッパ）、最も近いプロキシ／ソックス・サーバが好ましい（ウェブ・ブラウザがヨーロッパにあれば、ヨーロッパのプロキシ／ソックス・サーバ）。
・プロキシ／ソックス・サーバの選択の頑強性を改良するためには、ＣＧＩプログラムは、ウェブ・ブラウザに対し最良の“バックアップ（ｂａｃｋｕｐ）”プロキシ／ソックス・サーバを選択する（８０４）。この“バックアップ”プロキシ／ソックス・サーバは、タイムアウト後に、ウェブ・ブラウザによって自動的に用いられ、“最良の”プロキシ／ソックス・サーバと考えられるものを使用しようとする。また、この“バックアップ”プロキシ／ソックス・サーバは、ウェブ・ブラウザのＩＰアドレス（ＣＧＩ変数として得られる）と、各プロキシ／ソックス・サーバの使用可能度および応答時間のプローブによって作成され、オートプロキシＵＲＬシステムのテーブル（８０７）に格納された情報とを用いて選択される。
・ＣＧＩプログラムが、最良のバックアップ・プロキシ／ソックス・サーバを選択すると、ＣＧＩプログラムは、オートプロキシ・コードを作成する（８０５）。このコードは、一般に、ジャバスクリプト言語より作成される。
・オートプロキシ・コードが作成されると、オートプロキシＵＲＬシステムは、標準的なＨＴＴＰプロトコルにより、ウェブ・ブラウザに、オートプロキシ・コードをＣＧＩプログラムの他の出力としてダウンロードする（８０６）。
【００６３】
本発明を、特に、好適な実施例を参照して説明したが、本発明の趣旨および範囲から逸脱することなく、形態および詳細の種々の変更を行うことができることが分かるであろう。
【図面の簡単な説明】
【図１】従来例によるワールド・ワイド・ウェブにアクセスするウェブ・ブラウザをインターフェースするエンド・ユーザ・システムの一般論理ビューである。
【図２】従来例による図１に示すセットアップの一般的な物理ビューである。
【図３】本発明による使用可能度および応答時間のプローブの外部フローの論理ビューである。
【図４】本発明による図３で導入された使用可能度および応答時間のプローブの内部論理フローを示すフローチャートである。
【図５】本発明による図３で説明した論理環境の物理ビューである。
【図６】本発明による図５に示す全体図に関連するデータフロー図である。
【図７】本発明による使用可能度および応答時間のプローブの測定値の格納を示す図である。
【図８】本発明によるオートプロキシＵＲＬ（ユニバーサル・リソース・ロケータ）システムでランするプログラムのフローチャートである。
【符号の説明】
１０１，２０１，５０１，６０１  ウェブ・ブラウザ
１０２  ユーザ・インターフェース
１０３，２０５，３０７，５０５，６０５  ウェブ・サーバ
１０４，２０３，３０５，５０３，６０３  ファイアウォール
２０２，５０２，６０２  イントラネット
２０４，５０４，６０４  インターネット
３０１，５０６，６０６  オートプロキシＵＲＬシステム
３０２  クライアント・システム
３０３，３１０，６１１，６１２  ＨＴＴＰサーベイ・フロー
３０４  プロキシ・サーバ
３０８  ＵＲＬ
３０９  クライアント・プローブ
３１１  ソックス・サーバ
３１３  ウェブ・サイト
４０１  タイマー
４０２，４０４  接続
４０３  ウェブ・ページ
４０５  キーワード
４０８  エラーモード
４０９  リトライモード
５０７，６０７  プローブ
５０８，６０８  ＣＧＩ
６０９  アクセス
６１０  オートプロキシ・コード
【図１】
0003742272.tif 000002
【図２】
0003742272.tif 000003
【図３】
0003742272.tif 000004
【図４】
0003742272.tif 000005
【図５】
0003742272.tif 000006
【図６】
0003742272.tif 000007
【図７】
0003742272.tif 000008
【図８】
0003742272.tif 000009