JP2006190321A - ウェブコンテントの知的フェッチと配送のためのシステムと方法 - Google Patents

Abstract

【課題】コンテントの配送サービスを改善する、ウェブコンテントの知的フェッチと配送のためのシステムと方法を提供すること。
【解決手段】本システムは、要求元の末端ユーザーブラウザからのコンテントに対する要求を受信し、少なくとも一つの通信ネットワークを通してコンテントプロバイダサーバーからコンテントをフェッチするように構成されている代理サーバーを備える。代理サーバーは、フェッチの時間と要求している末端ユーザーのブラウザとを含む、フェッチされる全てのコンテントのログを維持し、同じ要求元の末端サーバーのブラウザによって、決まった時間の間のフェッチ済みコンテント間の関連を記憶するようにプログラムされている。特定のコンテントに対する次の要求が代理サーバーによって受信されると、代理サーバーは、その特定の要求されたコンテントに関連する全てのコンテントを先行フェッチする。
【選択図】図９

Description

本発明は、広くコンテントの配送ネットワークに関し、また、実施形態においては、コンテントの配送サービスを改善する、ウェブコンテントの知的フェッチと配送のためのシステムと方法に関する。本発明の実施形態は、２０００年３月２０日出願の米国仮出願第６０／１９０，６０４号"Intelligent Web Content Fetch and Delivery（ウェブコンテントの知的フェッチと配送）"に関し、その内容は、ここで参照のために組み入れられる。

ウェブ性能は、コンテントプロバイダ間に優劣をつけるための重要な点である。主要なウェブサイトでの故障と速度低下は、大量のウェブの通信を扱おうとする際に会社が直面する困難を示している。インターネットの基幹となる主要技術が進歩したので、サービス管理の分野の多くの革新によって、帯域幅とウェブコンテントを取得するための応答時間が改善された。しかし、これらの基盤の改善は、インターネット内の全ての点での通信上の問題を解決する訳ではない。

例えば、図１において、日本のネットワーク１４内の末端ユーザーが、米国内のネットワーク１８のウェブサイト１６からあるページにアクセス要求をすると仮定する。その要求は、ウェブサイト１６に着く前に、いくつかのゲートウェイ２０，７８，８０を通り抜けなくてはならない。ウェブサイト１６は、大きな帯域幅を持つが（大量のデータを高速に通信する能力）日本のネットワーク１４を米国のネットワーク１８に接続するそれらのゲートウェイは、遅いかも知れず、こうして末端ユーザー１２が、ウェブサイト１６からそのページにアクセスしようとするとき、ゲートウェイはボトルネックを作るかもしれない。そのようなゲートウェイのボトルネックは、結果として、データ１ページのアクセス時間が１０秒あるいはそれ以上のオーダーになる。そのようなゲートウェイのボトルネックがある故に、また、ウェブサイト１６と末端ユーザー１２との間のインターネットパスに沿って不確かな点が多くある故に、コンテント配送ネットワークあるいはシステムが、今や開発されている。

基本的に、コンテント配送システムは、少なくとも二つの大きな目的のために設計され配置されるが、それは、一つは負荷の平均化であり、他は応答時間を減らすことである。コンテント配送システムは、高速専用線を使って実現され、全てのゲートウェイを迂回したり、伝送経路内のインターネットゲートウェイの数を減らしてコンテントを配送する。しかし、そのような専用ネットワークは、高価であり全てのネットワークに展開することはできない。コンテント配送システムを実現する他の方法は、知的なキャッシュ、ミラー、代理サーバーあるいは、希望するコンテントを含み、末端ユーザーに高速応答時間を保証する近くて容易にアクセス可能なサーバーに、末端ユーザーを方向変更するような他の技術を使用することで行われる。いくつかの通信の向きを変えることで、通信の殺到は、減少し、末端ユーザーは、より早い応答時間の恩恵を受ける。このようなネットワークやシステムのアーキテクチャと機能性によく使用される用語は、コンテント配送サービス（ＣＤＳ）である。

図２は、従来のウェブコンテント配送とキャッシュの構成の概要を示している。図２は、図２の代理サーバー２８が図１の末端ユーザー１２と原ウェブサイト１６との間のどこかに置かれているという点で、図１に関連しているということを理解されたい。ユーザーが（例えば、ユーザー１；参照番号２４を参照）ウェブサイトから（例えば、ウェブサイト１；参照番号２６を参照）、あるページ（例えば、index.html）にアクセスしようとするとき、ユーザー１のブラウザは、最初に要求をドメイン名サーバー（ＤＮＳ）に送って、ウェブサイト１のドメイン名に対応するインターネットプロトコル（ＩＰ）アドレスを探させる。図２に示されていないが、当業者であれば、ＤＮＳのネットワークは、要求のあったドメイン名のＩＰアドレスを捜し出すために存在するということは十分に理解できる。

ユーザー１のブラウザがウェブサイト１のＩＰアドレスを受信した後、ブラウザは、代理サーバー２８から該当ページにアクセスしようとする。代理サーバー２８は、それから、希望するページが代理サーバー２８のキャッシュ３０の中にあるか捜してみる。もし、希望するページがキャッシュ３０の中にあれば、代理サーバー２８は、単に、原ウェブサイト（ウェブサイト１）から該当ページにアクセスしようとせずに、キャッシュ３０の中のコンテントをユーザー１に配送するのみである。もし、希望するページがキャッシュ３０の中に無ければ、代理サーバー２８は、index.html（テキストのみ）をフェッチするためにウェブサイト１に要求を送る。

ユーザー１のブラウザがindex.htmlを受信した後、ブラウザは、そのページを構文解析し、画像とアイコンのような埋め込まれたオブジェクトをフェッチするために追加要求を出す。しかし、代理サーバー２８は、最初にこれらの要求を受信し、埋め込まれたオブジェクトがキャッシュ３０の中で利用可能であるかどうかを決定する。もし、希望するオブジェクトがキャッシュ３０の中にあれば、代理サーバー２８は、原ウェブサイト（ウェブサイト１）からオブジェクトをフェッチしようとせずに、単にキャッシュ３０の中のオブジェクトをユーザー１に送るだけである。もし、希望するオブジェクトがキャッシュ３０の中に無ければ、代理サーバー２８は、オブジェクトをフェッチするよう適切なウェブサイトに要求を送る。

通信（すなわち、データの流れ）は、代理サーバー２８の中のログ（log）ファイル３２に記録される。そのようなログファイルは、要求の発信者のＩＰアドレスとフェッチされたオブジェクトのＵＲＬと各動作のタイムスタンプのようなものを含んでいる。代理サーバー２８は、通常、キャッシュ３０のコンテントが同様の関心を持ったユーザーからアクセスできるように、多くのユーザーによって共有されるということに注意したい。こうして、例えば、もしユーザー１があるページにアクセスし、そのページがキャッシュ３０に記憶されているなら、ユーザー２（参照番号９０を参照）が同じページを要求するとき、代理サーバー２８は、単にキャッシュ３０に記憶されているページをユーザー２に提供する。

しかし、各フェッチに対応した処理オーバーヘッドが高いゆえに、埋め込まれたオブジェクトをフェッチする間、依然として遅延が発生する可能性がある。たとえば、典型的なウェブページは、画像と本質的に小さな画像であるアイコンを含んでいる。アイコンに関連したデータは、少数のデータパケットを用いて転送される。しかし、どのような転送においても、接続を開始および終了する命令の形で、処理オーバーヘッドがある。この処理オーバーヘッドは、６個あるいは７個のデータパケットから成る。

図３は、アイコンの転送に係わるデータパケットを示している。最初に、接続を図るのにデータパケットを用いて、ユーザー３４がサーバー３８にＳＹＮ要求３６を送る。これに応答して、サーバー３８は、他のパケットを用いてＳＹＮ受け取り確認メッセージ４０をユーザー３４に送り返す。ユーザー３４は、それから、さらに他のパケットを用いて、受け取り確認４２をサーバー３８に送り返すことによって、パケットを受信したという確認をする。３個のパケットが、従って、接続を確立するのに必要である。一旦、接続が確立されると、ユーザー３４は、“アイコン入手”要求４４を、他のパケットを用いてサーバー３８に送る。サーバー３８は、それからペイロード（payload）やアイコンのコンテントを含む多数のパケット４６，８２，８４を、ユーザー３４に送り返す。一旦、データ転送が終了すると、サーバー３８は、他のパケットを用いて、ＦＩＮメッセージ４８をユーザー３４に送り返す。ＦＩＮメッセージ４８は、サーバー３８が接続を終了したがっていることを示す。これに対して、ユーザー３４は、一つのパケットを用いて受け取り確認メッセージ５０をサーバー３８に送り返す。ユーザー３４は、その後、ＦＩＮメッセージ５２を一つのパケットを用いてサーバー３８に送り返し、サーバー３８は、受け取り確認メッセージ５４をユーザー３４に返すことにより、このパケットを受け取ったと確認する。こうして、接続を終了するために、全部で４個のパケットを必要とする。図３の例は、アイコンの転送は非常に非効率的であると示しているが、これは、オーバーヘッドの７個のパケットがわずか２個か３個のコンテント用パケットのために必要になっているからである。この非効率は、多くのアイコンがある典型的なウェブページにおいては、さらにひどくなる。

加えて、ウェブページは、多数のイメージをフェッチする必要があるかも知れず、また、サーバーはユーザーごとの接続の決まった制限を課するかも知れないので全ての画像が同時にフェッチされるとは限らない。多数の画像を予定無しにフェッチすることで、ユーザーが不完全なままの画像を長時間見る結果となる。しかし、ユーザーにとっては、インターネットをさらに航行するのにあたり画像上をクリックするために、いくつかの全画像を妥当な時間内に見られことが重要であろう。ユーザーの視点からすれば、ユーザーがウェブページのコンテントに対してより良く理解できるように、できるだけ早く完全な埋め込みオブジェクトを見せることが望ましいであろう。ユーザーは、最初から小さな画像の一部に基づいて、ウェブページのコンテントを理解することはできないであろうから、このことは、特にアイコンのような小さな画像には当てはまる。

本発明の目的は、コンテントの配送サービスを改善するウェブコンテントの知的フェッチと配送のためのシステムと方法を提供することにある。

多数のオブジェクトの転送のために、ユーザーとコンテントプロバイダとの間の接続を確立したままにしておき、それによって、接続の確立、終了の回数を減らし、コンテントの転送のオーバーヘッドを減らし、アクセス時間を改善する、ウェブコンテントの知的フェッチと配送のためのシステムと方法を提供することが、本発明の実施形態の利点である。

さらに、多数のオブジェクトが配送されているときに、全ての残りのオブジェクトの全部あるいは一部がオブジェクトの大きさの昇順に転送されるような、ウェブコンテントの知的フェッチと配送のためのシステムと方法を提供することが、本発明の実施形態の利点である。

さらに、ドメイン名のアドレスを先に決定し、必要性を予測して接続を先にしておき、将来のオブジェクト転送を予測して接続を確立したままにしておくことでウェブコンテントのフェッチの応答時間を改善するような、ウェブコンテントの知的フェッチと配送のためのシステムと方法を提供することが、本発明の実施形態の利点である。

さらに、代理サーバーが、ページおよびオブジェクトのフェッチのログを保存し、特定の時間のウィンドウ内で発生するページおよびオブジェクトの複数のフェッチの間の関連のようなものを決定し記憶し、また、次のページ要求が受信されるときに、記憶された関連に従ってオブジェクトをキャッシュ内にプリフェッチするようなウェブコンテントの知的フェッチと配送のためのシステムと方法を提供することが本発明の実施形態の利点である。

これらの、そして他の利点は、要求元の末端ユーザーのブラウザからのコンテント要求を受信し、少なくとも一つの通信ネットワークを通してコンテントプロバイダサーバーからコンテントをフェッチするような構成の代理サーバーを備えたウェブコンテントのフェッチと配送システムによって達成される。代理サーバーは、フェッチ時間と要求元の末端ユーザーのブラウザを含むフェッチされた全てのコンテントのログを保存し、決まった時間の間に同じ要求元末端ユーザーのブラウザによってフェッチされたコンテント間の関連を記憶するようにプログラムされている。特定のコンテントに対する次の要求が代理サーバーによって受信されると、代理サーバーは、その特定の要求されたコンテントに関連する全てのコンテントをプリフェッチする。

本発明によれば、ドメイン名のアドレスを先行フェッチするか必要を予測して接続を先行確立することにより、また将来のオブジェクト転送を予測して接続を確立しておくことにより、ウェブコンテントのフェッチの応答時間を改善する。

以下の実施形態の記述において、ここで本発明の実施形態の一部を形成し、本発明が実践される特定の実施形態を図解によって示す添付図を参照されたい。本発明の実施形態の視野から離れることなく他の実施形態が利用可能であり、構成上の変更を行うことができるという点を理解されたい。

ウェブの性能は、コンテントプロバイダ間に優劣を付けるための重要な点である。主要なウェブサイトでの故障と速度低下は、高速ウェブ通信を扱おうとする時に、会社が直面する困難を示している。インターネットの基幹となる主要技術が進歩したので、サービス管理の分野で多くの革新によって、帯域幅とウェブコンテントを取得するための応答時間とが改善された。しかし、インフラストラクチャにこれらの改善をすることでは、インターネット内の全ての点での通信上の問題を解決することはできない。ゲートウェイのボトルネックは、データの１ページのアクセス時間が、１０秒あるいはそれ以上のオーダーになる可能性がある。ゲートウェイのボトルネックのせいで、また、末端ユーザーからウェブサイトへのインターネットのパスに沿って多くの不確実なものがあるので、コンテント配送ネットワークあるいはそのシステムが、現在開発中である。

基本的に、コンテント配送システムは、２つの主な目的のために設計される。一つは、負荷の平均化を達成することであり、他は、応答時間とアクセス時間を減らすことである。ここに記載される本発明の実施形態によって、知的キャッシュおよび代理サーバーを用いて、希望するコンテントを含みかつユーザーから近いかアクセスが容易であるような利用可能なサーバーにユーザーを方向変更するコンテント配送システムを通して、応答時間とアクセス時間とが減少する。方向変更された通信のいくつかによって、通信の殺到は減少し、ユーザーは高速応答時間の恩恵を受ける。

上述のように、オブジェクトをフェッチする手順は、その後に多くの埋め込みオブジェクトフェッチが続く、ｈｔｍｌページフェッチである。一つのｈｔｍｌページは、通常いくつかの様々な大きさの埋め込みオブジェクトを持ち、それらのオブジェクトを配送することで、ウェブを用いたユーザーの経験に影響を与える可能性がある。以下の段落において、ユーザーにより良い表示手順を提供する、ウェブオブジェクト配送スケジューリング方法が、本発明の実施形態によって記載される。

いずれのウェブ配送方法においても、いくつかの段階が実行されなければならない。最初に、ドメイン名サーバー（ＤＮＳ）ネットワークは、ドメイン名の検索を実行するのに使用されなければならない。このドメイン名検索の結果として、フェッチすべきデータを含むコンテントプロバイダサイトのアドレスができる。第２に、ソケットまたはチャネルを開くことによって接続を確立しなくてはならない。一旦、この接続ができると、オブジェクトをフェッチすることができる。

図４は、一つのソケットあるいはチャネルを用いたｈｔｍｌページ内に埋め込まれた３つのオブジェクトをフェッチすることを広く示しており、そこで、オブジェクト１（obj1）はオブジェクト２（obj2）より大きく、obj2の大きさはオブジェクト３（obj3）よりも大きい。図４において、横軸は時間を表し、縦軸はネットワーク帯域幅を表している。

図４（ａ）は、サーバーが、一つのソケットあるいはチャネルを用いて任意の順番でオブジェクトを配送するような、ウェブコンテント配送スケジューリングの一方法を示している。図４（ａ）で示された任意の配送手順において、obj1（参照番号５６を参照）が最初に配送され、次にobj2（参照番号５８を参照）とobj3（参照番号６０を参照）が続く。ユーザーは、obj1が完全に見えたときである、t=t4までは、埋め込みオブジェクトを何も完全に見ることはできない。図４（ｂ）は、obj1（参照番号８６を参照）とobj2（参照番号８８を参照）が同時に転送され、各々がネットワーク帯域幅の一部を使用する、時刻t=t2のように、サーバーが２つのソケットを用いて同時に同じネットワーク内で２個のオブジェクトを配送することができるようなウェブコンテント配送スケジューリングの他の方法を示している。図４（ｂ）が示すように、ユーザーは、obj2が完全に見える時であるt=t5まで、いかなる完全な埋め込みオブジェクトも見ることができないであろう。

目指す大きさの埋め込みオブジェクトが、評価の主観のせいで、他の大きさの埋め込みオブジェクトよりも重要であるかどうかをサーバーが決定するのは困難であることを理解されたい。オブジェクトの大きさは、重要さを決定する唯一の因子ではないだろう。例えば、小さい方の埋め込みオブジェクトは動作に必須の選択ボタンのためのアイコンであり得る一方、より大きなオブジェクトは広告のバナー（banner）であり得る。ユーザーの視点からすると、ユーザーがウェブページのコンテントに対してより良く理解できるように、完全な埋め込みオブジェクトをできるだけ早く見ることが望ましい。これは、ユーザーが、既に小さくなっている画像の一部に基づいて、ウェブページのコンテントを理解することはできないので、小さな画像に対しては特にこのことが言える。反対に、ユーザーは、大きな画像の一部に基づいて、ウェブページのコンテントを理解することはできるであろう。

図４（ｃ）は、埋め込みオブジェクトをオブジェクトの大きさの昇順で配送するという埋め込みオブジェクトの配送方法に関する、本発明の実施形態を示している。サーバーは、記憶したオブジェクトに関するオブジェクトの大きさ（オブジェクトのメタデータ内に含まれる）を含む管理情報を記憶し、ユーザーは、実際にオブジェクトが配送される前に、ｈｔｔｐプロトコルによってこの情報を受信することができるということを理解されたい。最も小さいオブジェクトが最初に配送されるので、ユーザーは、図４（ａ）と図４（ｂ）の方法よりかなり先に、t=t1の時に完全な画像を見ることができる。従って、図４（ｃ）に示される本発明の実施形態では、ユーザーは、他の方法よりも早く完全な埋め込みオブジェクトを見ることができる。

図５は、広く、本発明の他の実施形態を示している。図５（ａ）の例において、最小のobj3（参照番号９８を参照）とその次に小さいobj2（参照番号１００を参照）とが、それぞれ配送され、大きなobj1（参照番号１０２を参照）が配送されようとするときに、obj4（参照番号６２を参照）に対する埋め込みオブジェクト要求がt=t3の時に到着する。ここでobj4はobj1よりも小さい。図５（ａ）で示される一つの方法は、新しい要求の配送を、現在の全ての要求が完了した後に予定する。こうして、図５（ａ）の例において、obj4の配送は、obj1の配送の後に行われる。しかし、このスケジューリングは、全てのユーザーを考慮すると、完全な埋め込みオブジェクトの平均待ち時間を増加させる。

図５（ｂ）に示された本発明の実施形態において、埋め込みオブジェクトに対する要求がいつ起こったかに関わらず、オブジェクトの大きさの昇順で、残りの埋め込みオブジェクトを全て配送するという、埋め込みオブジェクト配送方法が採られている。こうして、図５（ｂ）の例において、obj4（参照番号１０８を参照）は、obj1（参照番号１１０を参照）よりも小さいので、obj4の配送は、全てのユーザーを考慮して埋め込みオブジェクトの平均待ち時間が最小になるように、obj1の配送前に行われるように動的にスケジューリングされる。

図６は、広く、本発明のさらに他の実施形態を示している。図６（ａ）において、最小のobj3（参照番号１１２を参照）と次に小さいobj2（参照番号１１４を参照）とがそれぞれ配送された後で、大きいobj1（参照番号１１６を参照）が配送処理をされているときに、obj4（参照番号１１８を参照）に対する埋め込みオブジェクト要求がt=t3の時に到着する。このときobj4は、obj1よりも小さい。t=t3の時に、まだ転送されるべきobj1の残りのものが、参照番号６４で示されている。残りのもの６４の大きさは、ここでＳ₁'として参照され、一方、obj4の全体の大きさはＳ₄として参照される。図６（ｂ）で示される本発明の実施形態において、２個の画像Ｓ₁'とＳ₄の小さい方が最初に配送され（参照番号１２０を参照）、その後には画像の大きいもの（参照番号１２２を参照）が続く。図６（ａ）の例において、もし、obj4（Ｓ₄）の全体の大きさがobj1（Ｓ₁'）の残りの大きさよりも小さいときは、obj4は、obj1の残りが一時的に配送を停止されている間に配送される。しかし、もしobj4（Ｓ₄）の全体の大きさが、obj1（Ｓ₁'）の残りの大きさよりも大きいときは、obj1の配送は、obj4の配送開始前に完了する。

こうして、本発明の実施形態において、もし新しく要求されたオブジェクトの大きさが、転送されるものとして残っているオブジェクトの大きさよりも小さければ、残りのオブジェクトの転送は停止され、新しく要求されたオブジェクトが即刻転送されるようにスケジューリングされる。

しかし、もし小さい埋め込みオブジェクトを転送する要求が多ければ、大きなオブジェクトが決して配送されないという枯渇の問題が発生するかも知れない。この問題が発生するのを防ぐために、本発明の他の実施形態において、停止している各オブジェクトに優先値が割り当てられる。この優先値は、配送すべきオブジェクトの待ち時間をオブジェクトの大きさで割り算して計算される。こうして、要求が停止し、システムによって配送されるのを待ち続けるとき、その優先値は増加する。オブジェクトの優先値が大きいほど、そのオブジェクトは早く配送される。従って、結局停止されている全ての大きなオブジェクトは、配送に十分な優先値に達する。たとえば、配送を停止させられているオブジェクトの合計データ量が、あらかじめ定めた閾値を超えると、この優先値に基づく配送が行われるようにしてもよい。また、配送を停止させられている最大の待ち時間を閾値とし、その時間まで待ち合わせているオブジェクトが存在する場合に、優先値に基づく配送が行われるようにしてもよい。

図４〜６に示された本発明の実施形態は、サーバーによるウェブコンテントの配送に関して包括的に記載されているが、図４〜６の実施形態は、またコンテントプロバイダのサーバーから末端ユーザーに、また代理サーバーから末端ユーザーにオブジェクトを転送することに応用できることは注意したい。サーバーの見通しからすると、図４〜６の例は、obj1,obj2,obj3,obj4をサーバーから顧客あるいはユーザーに配送する様を示している。従って、図６（ａ）において、obj1の転送の途中に受信されるobj4の要求は他の顧客あるいはユーザーから来るものであろう。

加えて、図４〜６の考え方は、オブジェクトを、コンテントプロバイダのサーバーあるいは代理サーバーから顧客あるいはユーザーが受信するということにおいても適用できる。オブジェクトは、最初ユーザーのコンピュータの中の通信プログラムを通してユーザーのウェブブラウザによって要求される。

ウェブブラウザと通信プログラムとユーザーのコンピュータは、ここではユーザーとして参照する。

オブジェクトがユーザーに配送されたときに、通信プログラムはオブジェクトをメモリ内にロードする。そのときにのみ、オブジェクトの大きさが通信プログラムによって分かる。一旦、オブジェクトがメモリ内に記憶されると、通信プログラムは、多数のオブジェクトを、図４から６に示される本発明の実施形態に従って、ウェブブラウザへと配送するよう予定を組む。

図７には、本発明の他の実施形態による継続的接続方法が示されている。継続的接続方法は、一般的に、従来のＨＴＴＰ１．０プロトコルを用いたものに比べて、より良い応答時間を得る。図７（ａ）には、ＨＴＴＰ１．０プロトコルに基づいた、従来のオブジェクトフェッチ手順の概略が示されている。接続が、各オブジェクト転送に対して確立され、そして終了することに注意したい。図７（ａ）の手順の例では、サーバーから顧客に３個のオブジェクトを送るのに９ステップを必要とし、各ステップは一つあるいは二つ以上のパケットを表している。

比較として、本発明の実施形態の継続的接続方法は、図７（ｂ）に示されている。継続的接続方法は、オーバーヘッドのステップを除くことにより応答時間を改善している。多数のオブジェクト転送に対しては接続を確立したままにし、従って、接続の確立と終了の回数を減らすことにより、オーバーヘッドは、除かれる。同じ接続内の多数のオブジェクトを転送することにより、ＣＰＵの処理とメモリ消費をも抑える結果となる。サーバーが停止するときに、通常それは、サーバーが要求情報を送れないからではないことに注意したい。むしろ、通常サーバーは、接続の確立と終了の処理に必要な量だけの利用可能な十分なＣＰＵとメモリを持っていないことからきている。こうして、少しの接続に対して定常的にそれらを確立したり終了させたりするよりも、余分な接続を確立したままにしておくのは、一般的に、より効率的である。

従来のネットワークにおいては、“目標のオブジェクトを得る”（"get-target-object"）要求が"GET target-object http/1.0"の形式で、各アイコン情報の転送に対して出され、そこで“１．０”はhttpのバージョンを示している。そのような要求で、一つのアイコンに対する画像をフェッチする。他のアイコンは、他の"get-target-object"要求を送ることによって続いてフェッチされる。しかし、本発明の実施形態において、多数のオブジェクト転送は、"get-icon"命令を多数のアイコンに拡張することによって、単一の接続内で達成することができる。その要求は、"GET list-of-targets http/1.0 extended"の形式であり、ここで"list-of-targets"は、同じ接続内で配送するオブジェクトの一覧表を特定している。こうして、もし"list-of-targets"が、obj1,obj2,obj3,obj4から成っていると、この要求に対して、一つの接続内でobj1,obj2,obj3,obj4等が配送される。同じ接続内で多数の画像を配送するのは、それらの画像が同じサーバーから配送されるときのみ可能であるということに注意したい。

単一の確立された接続内で多数の画像を転送するときに、ユーザーは、一つの画像が、いつ転送を終えて、新しい画像がいつ転送されているかを知らなくてはならない。図４〜６を参照しつつ記載したように、全ての転送しようとする画像の大きさは、現在画像を記憶しているサーバーによって前もって知られている。ユーザーは、httpプロトコルによってオブジェクトが実際に配送される前に、この情報を受信することができる。本発明の実施形態において、これらの大きさは、一つの画像が完了し、次の画像の転送が始まるのはいつかを決定するのに使用される。

図７（ｂ）で示されるように、多数の画像が同じ接続内で転送されるときに、図４〜６を参照して記載される画像転送の順番を決定する本発明の実施形態が用いられることに注意したい。例えば、図７（ｂ），obj1,obj2およびobj3は、実際にオブジェクトの大きさの昇順に転送される。

図８は、従来のhttp1.0プロトコルを用いたものと、本発明の実施形態によるプロトコルを用いたものとの２つのウェブサイトの間のオブジェクトのフェッチに係わる実験の結果を示している。この実験の結果は、本発明の継続的接続方法が、従来のオブジェクト転送プロトコルよりも速い応答時間を生み出していることを示している。

図７（ａ），７（ｂ），８に示された本発明の実施形態は、ユーザーとサーバーに関して一般的に記載されているが、本発明の実施形態は、また、コンテントプロバイダサーバーから直接コンテントを要求するユーザーや、代理サーバーからコンテントを要求するユーザーや、コンテントプロバイダサーバーからコンテントを要求する代理サーバーや、コンテントプロバイダサーバーからコンテントを要求するミラーサーバーに応用できることに注意したい。

他のサーバーからコンテントを要求する、ユーザーや代理サーバーやミラーサーバーは、ここで要求元と呼ぶ。

図９は、本発明の他の実施形態によるウェブコンテントのフェッチ応答時間を改善するための、ドメイン名の先行参照と接続の先行確立を示している。これらの実施形態は、例を使って説明される。

図９（ａ）の例において、ユーザーがbiglobe.ne.jpのページ６８に代理サーバー（図示せず）からアクセスするとき、またもしこのページが既に代理サーバーの中に無いときは、代理サーバーをウェブサイトbiglobe.ne.jpに接続するチャネルが開き、index.html（テキストのみ）のページが代理サーバーの中にフェッチされる。このページは、その後ユーザーに配送される。代理サーバーは、またnec.comやnec.co.jpのような、参照番号７０で識別されるテーブル内に示される、ページ内のリンクされたＵＲＬを参照する。これらのＩＰアドレスは、たとえこれらのページに対するアクセス要求が受信されなくても、参照される。しかし、もしこれらのページが実際に要求されると、ドメイン名に対するアドレスが既に決定しているので、応答時間は減少する。ドメイン名先行参照に対する余計な手間は、最小であり、それは、そのような動作は相対的に小さな帯域幅しか使用しないためである。

本発明の他の実施形態において、ウェブコンテントをフェッチする応答時間を改善するのに、さらなる処置が取られる。図９（ａ）の例において、代理サーバーをウェブサイト biglobe.ne.jp へ接続するチャネルは、全てのオブジェクトが配送されても開いたままにされる（表７０を参照）。接続を確立したままにしておくことにより、代理サーバーと biglobe.ne.jp との間の接続を必要とする次のコンテントのフェッチあるいはページのリフレッシュは、新しい接続を確立せずに通信することができる。一つの実施形態において、縦断するあらゆるページ上に表れるリンクに関わらず、固定した数のリンク縦断に対して、接続は、確立したままにしておかれる。他の実施形態において、開かれたページ上のリンクが、コンテントプロバイダからのさらなるフェッチを要求され得るということを示している限り、接続は確立したままにされる。こうして、もし biglobe.ne.jpに対するウェブページが、他の関連するビッグローブ（登録商標）（biglobe）のウェブページへのリンクを含んでいれば、ユーザーと biglobe.ne.jp との間の接続は、確立されたままにされるであろう。

加えて、たとえこれらのウェブページが要求されなくとも、ユーザーを nec.com と nec.co.jp に接続するチャネルが先行確立される。こうして、図９（ａ）の例において、ドメイン名 nec.com と nec.co.jp に対するＩＰアドレスが決定された後、これらのサーバーに対するチャネルが確立される（表７０参照）。もし、 nec.com と nec.co.jp におけるコンテントが要求されると、最初に新しい接続を確立することなしに、フェッチがすぐに起こる。実施形態において、その様な先行フェッチは、帯域幅の点から高価であるので、 nec.com と nec.co.jpにおけるコンテントは、先行フェッチされないことに注意したい。しかし、先行確立された接続は、非常に少しの帯域幅しか使わないし、応答時間を実質的に改善するであろう。

本発明の実施形態において、先行ドメイン名参照と接続の先行確立の処理が、ページのリンクが手繰られるにつれて、継続する。こうして、図９（ｂ）の例で示されるように、ユーザーが biglobe.ne.jp のページ６８から ccrl.com へのリンクを含む nec.com のページ７２まで進むときに、ドメイン名 ccrl.com に対するアドレスが決定され、ccrl.com からの予想されるフェッチに対してチャネルが確定される（参照番号７４で識別される表を参照）。ドメインメッセージ参照とチャネルを先行確立を実行するこの段階は、多数のページリンクを手繰るのに対して継続し、これは図９（ｃ）と参照番号７６で識別される表とで示されている。

しかし、代理サーバーの見方からして、あまりに多くのチャネルを開くことは、あまりにも多数の資源を消費する。こうして、本発明の実施形態において、前に使われたチャネルは、予め定められた基準によって閉じられる。例えば、一つの実施形態において、固定した数のリンク縦断よりも多くアクセスした唯一のものであり得るページにリンクするためのチャネルが閉じられる。こうして図９（ｃ）の例において、ユーザーが ccrl.com に進むとき、biglobe.ne.jp に接続するチャネルは閉じられるが、これは表７６に記入漏れとして示される。代わりに、決まった数のチャネルが開いたままにされ、この決まった数に達すると、最も早く開いたチャネルが閉じられる。

図９（ａ）〜（ｃ）に示された本発明の実施形態は代理サーバーに関して記述されているが、本発明の実施形態は、またコンテントプロバイダサーバーからコンテントを直接に要求しているユーザーにも当てはまることは注意したい。こうして、もし、ユーザーがコンテントプロバイダサーバーから index.html ページをフェッチすると、ユーザーは、先の段落で記述したように、接続を確立したままにしておくか、ページ内のリンク済みＵＲＬを参照するか、接続を先行確立するか、接続を終了させる。

次に、ログの記入に基づいた並列先行フェッチに関する本発明のさらなる実施形態を説明する。上述のように、ユーザーがページをフェッチすると、ＨＴＭＬテキストページが最初にフェッチされ、続いて一連の埋め込みオブジェクトがフェッチされる。この一連は、ログの中に記録される。これらのフェッチは、通常比較的短時間の内に起こるので（例えば、数秒から、もしネットワークの状況が良くなければ数分）、本発明の実施形態において、ログ情報が分析されて、同じＨＴＭＬページのフェッチにおそらく関連するであろう記入に関係づける。

図１０には、アドレスによってＩＰ１，ＩＰ２，ＩＰ３として識別される３つの異なるユーザーに対する部分的なフェッチ履歴を含む、例としての一連の代理サーバーのログ記載が示されている。各ログの記載には、要求が発せられたＩＰアドレスと、要求のあったページあるいはオブジェクトのＵＲＬと、要求のあった時刻とが含まれる。これらのログ記載は、キャッシュの中に、決まった長さの時間、例えば２４時間、維持される。本発明の実施形態において、時間ウィンドウ６６が、ログ内の記載同士の間の関連を調べるために選ばれる。もし、時間ウィンドウ６６が小さければ、それはより少ない記載しかされないだろうし、関連は計算するのがより容易であろう。しかし、小さな時間ウィンドウ６６は、画像をダウンロードするのに十分な時間を与えないだろうし、こうしていくつかの関連は失われる。本発明の実施形態において、時間ウィンドウ６６は、３０秒のような決まった時間に設定される。ウェブブラウザによって先行フェッチが行われる他の実施形態において、ウェブブラウザの"時間切れ"期間（ウェブブラウザが接続を図る間待つであろう長さの時間）は、ウィンドウの大きさとして使用される。

図１０の例において、ウィンドウ６６内において、ログの記載は、ユーザーＩＰ１がページ P1.html をフェッチし、続いてユーザーＩＰ１によって obj1.jpgとobj2.jpgとobj4.jpgとobj5.jpgのオブジェクトのフェッチが続いたことを示している。ログの記載事項には、多数のユーザーのフェッチ履歴が含まれ、これらのフェッチは、他のユーザーからのフェッチと交互に行われることに注意したい。オブジェクトのフェッチは、時間的にページのフェッチのすぐ後に続くので、obj1.jpgとobj2.jpgとobj4.jpgとobj5.jpg のオブジェクトが、ページ P1.htmlの中に埋め込まれ、ブラウザによるページ分析の帰結としてフェッチされたと思われる。これらの３つの要求は、ユーザーによって、別々の要求を短い時間の間に入力されて、独立に行われたとは考えにくい。ページのフェッチにすぐに続いて同じユーザーによって行われるオブジェクトのフェッチは、同じ場所を共用しそうなので、実施形態において、代理サーバーは、ページとオブジェクトのフェッチの間の関連を作り出す。図１０の例において、代理サーバーは、 obj1.jpgとobj2.jpgとobj4.jpgとobj5.jpg がページ P1.html に埋め込まれたオブジェクトとして最もありそうだと決定し、従ってこれらの関連を記憶する。同様に、図１０の例の中の代理サーバーは、obj3.jpg がページ P2.html に最も埋め込まれたらしいと決定する。

代理サーバーのキャッシュに記憶された各ページは期限日を割り当てられ、キャッシュ内のコンテントはページ入れ替えの一部として取り除かれるので、ページ P1.html と P2.html は埋め込みオブジェクトと同様に必然的にキャッシュから取り除かれる。しかし、 P1.html と P2.html に対する新しい要求があったときに、P1.html あるいは P2.html のみをコンテントプロバイダサーバーからフェッチする代わりに、本発明の実施形態では、代理サーバーが P1.html あるいは P2.html に対する記憶済みの関連を調べ、 P1.html あるいは P2.html に関連する埋め込みオブジェクトをキャッシュに移すのと平行して、多数の先行フェッチの要求を発する。図１０の例において、もし代理サーバーが P1.html に対する新しい要求を受信すると、キャッシュの中に obj1.jpgとobj2.jpgとobj4.jpgとobj5.jpg を、もしこれらがキャッシュの中に既にあるので無ければ、P1.html の関連に基づいて自動的に先行フェッチする。もし、ユーザーのウェブブラウザが obj1.jpgとobj2.jpgとobj4.jpgとobj5.jpg に対する埋め込みオブジェクトの追加フェッチを引き続き発すると、これらのオブジェクトは、コンテントプロバイダサーバーからの追加フェッチのための必要無しに、キャッシュから直接にユーザーへと送られる。

先行フェッチされたオブジェクトは、ページが変更された、あるいはユーザーが画像のロードを取りやめたためにページ要求が関連するオブジェクトのフェッチとはならないという事実によって、要求されているページとは実際には関連が無いということがあり得る。これらの可能性にも関わらず、代理サーバーが並列する接続を確立して、必要であろうと予測して、コンテントプロバイダサーバーからオブジェクトを先行フェッチするのは、依然としてより効率的である。

図１０に示される本発明の実施形態は、代理サーバーに関して記述されたが、本発明の実施形態は、全ての要求元に当てはめられることに注意したい。他の一つの実施形態において、コンテントをコンテントプロバイダサーバーから直接に要求するユーザーは、ユーザーのコンピュータのメモリにログを維持し、関連を記憶し、記憶した関連に従ってコンピュータプロバイダサーバーから html ページに関連したオブジェクトを先行フェッチする。他の別の実施形態において、コンテントを直接にコンテントプロバイダサーバーから複写するミラーサーバーは、ミラーサーバーのメモリ内のログを維持し、コンテントがリフレッシュされるべき時に html ページに関連するオブジェクトがコンテントプロバイダサーバーから記憶されている関連に従って先行フェッチされうるように、関連を記憶する。

従って、本発明の実施形態によって、ユーザーとコンテントプロバイダサーバーとの間の接続を多数のオブジェクト転送のために確立しておき、従って接続の確立と終了のために必要な処理の数を減らすような、ウェブコンテントの知的フェッチと配送のためのシステムと方法が提供される。本発明の実施形態は、また、多数のオブジェクトが配送されるときに、全ての残りのオブジェクトの全体あるいは部分をオブジェクトの大きさの昇順で転送することにより、画像全部を受信する待ち時間を改善する。

本発明の実施形態は、また、ドメイン名のアドレスを先行フェッチするか必要を予測して接続を先行確立することにより、また将来のオブジェクト転送を予測して接続を確立しておくことにより、ウェブコンテントのフェッチの応答時間を改善する。さらに、本発明の実施形態において、代理サーバーは、ページとオブジェクトのフェッチをログに維持し、特定の時間ウィンドウ内に発生するページとオブジェクトのフェッチの間の起こりそうな関連を決定して記憶し、次のページ要求が受信されるときには、記憶した関連に従ってキャッシュ内にオブジェクトを先行フェッチする。

末端ユーザーとウェブサイトとの間の、従来のコンテント配送パスの一例を示すブロックを示す図である。 典型的なウェブコンテントの配送とキャッシュ構成の概略を示すブロック図である。 アイコンの転送に係わるデータパケットを示す代表的な図である。 （ａ）サーバーが、オブジェクトを任意の順番で配送する、ウェブコンテントの配送スケジューリングの一方法と、（ｂ）サーバーが、２個のオブジェクトを同じネットワークで同時に配送するウェブコンテントの配送スケジューリングの他の方法と、（ｃ）埋め込みオブジェクトを昇順で配送する、本発明の実施形態による、埋め込みオブジェクト配送計画を図示している。 （ａ）もし、他のオブジェクトが配送予定のときに、あるオブジェクトに対する新しい埋め込みオブジェクトの要求が届いた場合、先に予定されていたオブジェクトが最初に配送されるというウェブコンテントの配送スケジューリングの一方法と、（ｂ）もし、他のオブジェクトが配送予定のときに、あるオブジェクトに対する新しい埋め込みオブジェクトが届いた場合、本発明の実施形態に従って、小さいほうのオブジェクトが最初に配送されるというウェブコンテントの配送スケジューリングの他の方法を図示している。 （ａ）他のオブジェクトが配送処理中に、あるオブジェクトに対する新しい埋め込みオブジェクト要求が届いた場合のウェブコンテントの配送スケジューリングで起きるかもしれない一つの状況と、（ｂ）他のオブジェクトが配送の処理をされているときに、新しい埋め込みオブジェクトの要求が届いた場合、埋め込みオブジェクトの小さい方と、配送されるオブジェクトの転送されていない残りの方とが、本発明の実施形態に従って最初に配送されるようなウェブコンテントの配送スケジューリングに対する他の方法を図示している。 （ａ）ＨＴＴＰ１．０プロトコルに基づいた、従来のオブジェクトのフェッチ手順の概略を図示した代表的な図と、（ｂ）本発明の実施形態による、永続的な接続方法を図示した代表的な図である。 従来のプロトコルを用いたものと、本発明の実施形態による変更した多重オブジェクト転送プロトコルを用いたものの２種のウェブサイト間のオブジェクトの転送に係わる、実験の結果を示すグラフである。 （ａ）本発明の実施形態による、プリドメイン（pre-domain）名索引と接続の先行確立（pre-establishing）を図示するブロック図と、（ｂ）本発明の実施形態による、さらなるプリドメイン（pre-domain）名索引と接続の先行確立（pre-establishing）と、（ｃ）本発明の実施形態による、さらなるプリドメイン（pre-domain）名索引と接続の先行確立（pre-establishing）と、古い接続の終了を図示したブロック図である。 本発明の実施形態による、並列のログを基準にしたプリフェッチを実行するのに使用される、３つの異なるユーザーに対する部分的なフェッチの履歴を含む一連のログ事項を示したものである。

符号の説明

１２ 末端ユーザー
１６ 原サイト
２４ ユーザー１
２６ ウェブサイト１
３０ キャッシュ
３２ ログ
３４ ユーザー
３８ サーバー
９０ ユーザー２

Claims (6)

1. 少なくとも一つの通信ネットワークを通して、コンテントを提供するコンテントプロバイダサーバーと通信するように構成されたコンテント要求元を備えるウェブコンテントのフェッチと配送のシステムであって、
   前記コンテント要求元は、コンテントのフェッチ要求により得られたウェブページに含まれるリンク済みのＵＲＬのＩＰアドレスを、当該ＵＲＬへのアクセス要求の有無にかかわらず参照しておくことを特徴とするシステム。
2. 前記コンテント要求元は、さらに、前記リンク済みのＵＲＬへの接続を、当該ＵＲＬへのアクセス要求の有無にかかわらず確立しておくことを特徴とする請求項１記載のウェブコンテントのフェッチと配送のシステム。
3. 少なくとも一つの通信ネットワークを通して、コンテントを提供するコンテントプロバイダサーバーと通信するように構成された要求元を備えるウェブコンテントのフェッチと配送のシステムであって、
   前記コンテント要求元は、確立された接続を介して前記コンテントプロバイダサーバーに要求したコンテントの配送を受けると、予め決められた数のウェブリンクが手繰られるまで前記接続を確立したままにしておくことを特徴とするシステム。
4. 少なくとも一つの通信ネットワークを通して、コンテントを提供するコンテントプロバイダサーバーと通信するように構成されたコンテント要求元におけるウェブコンテントのフェッチと配送の方法であって、
   前記コンテント要求元からコンテントのフェッチ要求を前記プロバイダサーバーに送信し、
   当該フェッチ要求により前記プロバイダサーバーから得られたウェブページに含まれるリンク済みのＵＲＬのＩＰアドレスを、当該ＵＲＬへのアクセス要求の有無にかかわらず参照しておく、
   ことを特徴とする方法。
5. さらに、前記リンク済みのＵＲＬへの接続を、当該ＵＲＬへのアクセス要求の有無にかかわらず確立しておくことを特徴とする請求項４に記載の方法。
6. 少なくとも一つの通信ネットワークを通して、コンテントを提供するコンテントプロバイダサーバーと通信するように構成されたコンテント要求元を備えるシステムにおけるウェブコンテントのフェッチと配送の方法であって、
   前記コンテント要求元と前記コンテントプロバイダサーバーとの間の接続を確立し、
   当該確立された接続を介して前記コンテントプロバイダサーバーに要求したコンテントの配送を受けると、予め決められた数のウェブリンクが手繰られるまで前記接続を確立したままにしておく
   ことを特徴とする方法。
   
   

Images