JP3774807B2 - 分散型システムとオブジェクトをプレフェッチする方法 - Google Patents

Description

【０００１】
（技術分野）
本発明は、データ転送に関する。特に、デジタルネットワークを使ったデジタルデータ転送に関する。
【０００２】
（背景技術）
インターネットの発達は、多くの会社と個人に、インターネットの存在感を感じさせてきた。例えば、企業は、自社の製品とサービスに関するウェブページを作り、ユーザが注文を出せるようにした。ユーザは、コンピューター上のウェブブラウザソフトを使って、ウェブサーバからウェブページにアクセスできる。ウェブページ上では、同じサイトまたは他のウェブサイトで他の情報にリンクできる。
【０００３】
図１は、インターネットの接続を示すブロックダイアグラムである。ユーザは、ブラウザ２０からファイルリクエストを出す。ウェブブラウザ２０は、パソコン、ネットワーク端末、またはウェブブラウザソフトが実行できる他の方式の端末で構成される。リクエストは、インターネット２４のルーター２２Ａ−２２Ｎを通過する。ルーター２２Ａ−２２Ｎは、リクエストの内容を調べずに、アドレスヘッダーに従って、ウェブサーバ２６にリクエストを送るだけである。ウェブサーバ２６は、リクエストの内容を調べて、リクエストされたファイルに応答する。
【０００４】
ユーザがインターネット上の情報にアクセスしたいときは、ウェブブラウザ内の均一リソースロケーター（ＵＲＬ）に入る。ＵＲＬは、基本的にオブジェクトの場所を示すポインターである。例えば、http:＼＼www.internic.net. ＼rfc＼rfc1738.txtは、均一リソースロケーターを説明するＲＦＣ（Request For Comment）文を指すURLアドレスである。URL内において、httpは、Hyper Text Transfer Protocol(HTTP)プロトコルを使って、サイトにアクセスするということを示している。ダブルバックスラッシュは、www. internic.netのようなホスト名がつぎに来ることを示している。シングルバックスラッシュは、ディレクトリーかファイル名が続くことを示している。この場合、rfcは、ディレクトリーであり、rfc1738.txtは、このURLが、ウェブブラウザ２０によってリクエストされているときに表示されるディレクトリーのなかのファイルである。
【０００５】
ワールドワイドウェブ（World Wide Web）は、インターネットのトップに作られる。HTTPは、ワールドワイドウェブ上で、もっとも普通に使われるクライアントサーバプロトコルである。HTTPは、クライアントとサーバの間の通信を設定し、２つのシステム間に命令とファイルを送るのに使う。
【０００６】
HTTPは、ウェブブラウザがウェブサーバにアクセスし、Hyper Text Makeup Language（HTML）を使って作ったドキュメントをリクエストする方法を提供する。HTMLによるウェブページは、画像、サウンドクリップ、テキストファイルおよびその他のタイプのファイルを含むことができる。オブジェクトのなかには、ウェブブラウザ２０によってリクエストされた元のHTML親ファイル（エウブドキュメントの基本コンポーネント）の一部でないものもある。その代わり、HTML親ファイルは、これらのインラインオブジェクト（サーバ上に別のデータファイルの形で存在する）に対するリファレンスを含む。ユーザが、ウェブブラウザ上のHTML親ファイルを呼び出すと、インラインオブジェクトも呼び出され、表示されたドキュメントのなかに挿入される。このようにして、HTMLドキュメント（またはページ）は、実際にサウンド、グラフィックス、および親ファイルで決まるマルティメディアインラインオブジェクトとともにHTML親ファイルで構成される。例えば、インラインオブジェクトは、広告用のバナー、スライダー、ビュレットリスト、グラフィックイメージ、サウンドクリップなどを含む。
【０００７】
図２は、ウェブブラウザ２０へのデータ転送またはウェブブラウザからのデータ転送を示すタイミングを表わすダイアグラムである。図２において、時間は、左から右に進む。上向きの矢印は、ウェブブラウザ２０からウェブサーバ２６に向かって出るメッセージを示す。下向きの矢印は、ウェブサーバから出て、ウェブブラウザで受ける入りのメッセージを示す。見て直ぐ分かるように、入りのメッセージと出のメッセージは、それぞれすぐに転送されるように見える。実行の際は、各メッセージの転送には、認識できる程度の時間を必要とするのが普通である。
【０００８】
出されるメッセージ３０は、最初のURLリクエストを運ぶ。それに応えて、入りのメッセージ３２は、メッセージ３０で出されたリクエストに応える最初の部分を運んでくる。入りのメッセージ３４と３６は、リクエストに対する第二、第三の応答に対応する。
【０００９】
ここでは、入りのメッセージ３２は、インラインオブジェクトに対するリファレンスを含むと仮定する。ウェブブラウザ２０は、入ってくる情報を調べ、それに応えてインラインオブジェクトに対するリクエストを出すメッセージ３８を送る。ここでは、説明のために、インラインオブジェクトは、サウンドクリップであると仮定する。
【００１０】
出のメッセージ３８に従って、ウェブブラウザ２０は、出のメッセージ３０によって出された最初のリクエストに対応する追加情報を含む入メッセージ４０を受ける。最初のリクエストに対応する入りメッセージを受け入れた後、ウェブブラウザ２０は、入りメッセージ４２のなかに含まれるサウンドクリップを受け始める。ウェブブラウザ２０は、入りメッセージ４４の中にサウンドクリップに関する情報を受け続ける。
【００１１】
入りメッセージ４２は、広告バナーであるオブジェクトに対する外部からのリファレンス情報を含むと仮定する。出のメッセージ４６は、広告バナーに対するリクエストを出す。出のメッセージ４６に従って、ウェブブラウザ２０は、入りのメッセージ４８とサウンドクリップに対応する追加情報を含む入りのメッセージ５０を受ける。最後は、ウェブブラウザ２０は、入りのメッセージ５２の中に広告バナーに関する情報を受ける。
【００１２】
ウェブブラウザ２０が、ウェブサーバ２６からの情報をリクエストするたびに、遅れがでる。例えば、出のメッセージ3０とそれに対応する入りのメッセージ３２の間に、時間の遅れΔＴ_1Aが出ることがわかる。遅れには、２つの主なコンポーネントがある。（１）ウェブサーバとの接続に係わるラウンドトリップディレイ、（２）ウェブサーバの応答時間である。図２の例では、インラインオブジェクトの転送が、前にリクエストされたオブジェクトと親ファイルの転送のために遅れ、その結果、ΔＴ_2AとΔＴ_3Aは、ΔＴ_1Aより大きい。
【００１３】
下記にもっと詳しく説明されているように、ＨＴＴＰプロトコルは、ウェブブラウザに対して親ファイルを調べて、インラインオブジェクトに対する別のリクエストを出すように要求するので、かなりの遅れを出すリンクを導入すると、ウェブページをフルに呼び出して、表示させるのに大変時間がかかる。例えば、ユーザのインターネットへのアクセスチャンネルが、サテライトリンクを含んでいる場合は、インラインオブジェクトを１個しか含んでいないウェブページを呼び出すのに必要な時間は、サテライトリンクのラウンドトリップディレイの少なくとも２倍である。さらに、インラインオブジェクトを別にリクエストする必要がある場合は、通信用リンク上に不必要な情報が走る。本発明は、ＨＴＴＰプロトコルを変えることなく、これらの問題の解決策を得ようとするものである。
チェン ワン（ Zheng Wang ）及びジュン クロウクラフト（ Jun Crowcroft ）らによる、ワールドワイドウェブ内でのプレフェッチ、 Globalcom 1996 Global Internet 1996 の、 1996 年 11 月 18 日の会議資料の 28 から 32 ページの“ワン”は、クライアントは、ローカルキャッシングプロキシを使って、ウェブページのプレフェッチとキャッシングを始めたと明らかにした。キャシングプロキシは、手助けするウェブブラウザに対しては、無防備であり、そして、ＨＴＴＰプロトコルの変更を要求しない。ワンは、またブラウザとプロキシサーバの間にある別のコンポーネントを使って、どちらが、ブラウザに対してウェブページをプレフェッチするように命令を出すかを明らかにしている。さらに、ワンは、サーバ主導のプレフェッチの開始の可能性に着目しているが、サーバは、現在のＨＴＴＰプロトコルの拡張とクライアントサーバソフトウエアの変更を求めるであろうと結論付けている。
ワン (Wang) のクライアント主導のプレフェッチ技術は、サテライトリンクのような待ち時間の比較的長いリンク上でのインラインオブジェクトの呼び出しの問題に対する十分な解決策とはならない。例えば、ワンのキャッシングプロキシを使って、サテライトリンク上で、インラインオブジェクトをプレフェッチすると、インラインオブジェクトは、親（ＨＴＭＬ）ファイルがサテライトリンクのクライアント側に着くまでは、リクエストされない。オブジェクトリクエストメッ セージは、そのときサテライトリンクを前方（クライアントからサーバに）に横切らなければならない。そして、インラインオブジェクトは、その後、反対方向にサテライトリンクを横切らなければならない。このようにして、一度親ファイルが、サテライトリンクのクライアント側に着くと、サテライトリンクのラウンドトリップ遅れが、インラインオブジェクトが、ブラウザに着く前に、再度（通常のプレフェッチを使わないときのように）起こる。
【００１４】
（発明の開示）
本発明は、分散型システムとドキュメントのインラインオブジェクトをプレフェッチする方法を提供することにより、上記の問題を解決する。実施例において、システムは、サテライトリンクを含むインターネットアクセスシステムの中で使うための分散型プロキシサーバの形で存在する。分散型プロキシサーバは、サテライトリンクのクライアント（ブラウザ）側で動き、ウェブブラウザと通信するアクセスポイントコンポーネントを含み、さらに、サテライトリンクのインターネット（ウェブサーバ）側で走り、ウェブサーバと通信するサテライトゲートウェイコンポーネントを含む。操作においては、ウェブサーバが、ユーザからリクエストされているウェブページの親ファイルを返すと、サテライトゲートウェイコンポーネントは、親ファイルを分析して、インラインオブジェクトに対するリファレンスのすべてを識別し、これらのオブジェクトをウェブサーバからプレフェッチする。このようにして、オブジェクトは、ブラウザが、親ファイルを受け、インラインオブジェクトに対するリクエストを出すのを待つことなしに、リクエストされる。
【００１５】
サテライトゲートウェイは、サテライトリンク上でプレフェッチされたオブジェクトを、アクセスポイントコンポーネントに送ると、アクセスポイントコンポーネントは、ブラウザが、リクエストするまでインラインオブジェクトをキャッシュする。アクセスポイントコンポーネントが、キャッシュの中にあるオブジェクトに対するリクエストを受けると、アクセスポイントコンポーネントは、サテライトリンク上にオブジェクトリクエストを伝えることなく、オブジェクトを返す。このようにして、分散型プロキシサーバは、インラインオブジェクトに対するリクエストに係わる遅れを減らし、サテライトリンク上を走る情報の量を減らす。
【００１６】
実施例のシステムは、サテライトリンクと関連しながら動くが、基礎的な方法とアーキテクチャを使えば、有線リンクを含む他のリンク上でもパフォーマンスは上げることができる。さらに、実施例は、ＨＴＴＰを使ったシステムで動くが、本発明インラインオブジェクトが基本コンポーネントと別にリクエストされる他のタイプのドキュメント呼び出しプロトコルとともに使うこともできる。
【００１７】
本発明では、ドキュメントのインラインオブジェクトがリクエストされ、ドキュメントの基本コンポーネントとは別に呼び出される、クライアントサーバタイプのドキュメント呼び出しシステムにおいて、通信接続によって起こるパフォーマンスの低下を減らすための分散型のシステムを提供する。分散型システムは、通信接続のクライアント側で走り、クライアントと通信する第一のコンポーネント（クライアントからのドキュメントリクエストを受け、それを処理するために通信用リンク上に送るためにある）で構成される。また、システムには、通信接続のサーバ側で走り、ドキュメントサーバと通信する第二コンポーネントも含まれ、この第二コンポーネントは、通信用リンク上で第一コンポーネントから出されるドキュメントリクエストを受け、このリクエストをドキュメントサーバに送るためにあり、このリクエストにより、ドキュメントサーバはリクエストされたドキュメントの基本コンポーネントを返す。操作においては、第二コンポーネントは、（i）基本コンポーネントを分析して、インラインオブジェクトに対するリファレンスを識別し、（ii）インラインオブジェクトをプレフェッチし、（iii）基本コンポーネントとプレフェッチされたインラインオブジェクトを第一コンポーネントに送ることにより、ドキュメントサーバが返す基本コンポーネントを処理する。第一コンポーネントは、キャッシュメモリー内の第二コンポーネントから受けたプレフェッチされたインラインオブジェクトを保存し、インラインオブジェクトをキャッシュメモリーからクライアントに送ることにより、クライアントからのオブジェクトリクエストに応える。
【００１８】
本発明の特徴、目的、利点は、下記の詳細な説明を図と関連付けて読むと、より明確になる。図においては、同じ部分は、同じ参照符号が付けられている。
【００１９】
（実施例の詳細な説明）
デジタルデータを送るためのワイヤレスの通信システムの利用は、ますます普及してきている。ワイヤレスシステムでは、コストと利用のし易さという点で、もっとも価値があるのは、ワイヤレスリンクそのものである。従って、ワイヤレスリンクによる通信システムのデザイン上の大きな目標は、ワイヤレスリンクの容量を効率よく使うことである。さらに、ワイヤレスリンクを行う際の遅れは、ネットワークのその他の遅れよりもかなり大きいために、ワイヤレスリンクを使う際の遅れを減らすことが望まれている。
【００２０】
スタンドアロン型コンピューターは、たいへん強力なツールであるが、互いに接続してネットワークを作るとさらに強力になる。接続台数が増えると、ネットワークの需要がさらに増える。コンピューターが、互いに近くにあると、専用配線で接続できる。ネットワークからある距離離れているコンピューターは、普通の電話回線を通じてネットワークにアクセスできる。しかし、電話回線のバンド幅は、コンピューターとネットワーク間のデータ通信の速度を制限する。
【００２１】
それゆえ、デジタルデータネットワークにアクセスするもうひとつの方法が開発されている。例えば、サテライトリンクを使うと、データネットワーク内のデジタルデータを送ることができる。地学的同調人工衛星を使うと、約０．５秒のラウンドトリップ遅れが生じる。現在、デジタルデータネットワークで使われているプロトコルは、このような大きな遅れを念頭において開発されていない。大きな遅れを出す接続法を使うと、平均データ転送速度が、許容できるレベル以下になってしまう。本発明は、デジタルデータシステムにアクセスするときに大きな遅れを生む接続法を利用することにより起こる効率の悪さを減らす方法を提供し、デジタルデータシステム接続を効率的に利用できるようにする。
【００２２】
図３は、サテライトリンクで構成されるインターネット接続のダイアグラムを示す。図３において、ウェブブラウザ２０は、サテライト端末６０に接続されている。サテライト端末６０は、地学的同調人工衛星６２を通して地球上のステーション６４と接続されている。地球上のステーション６４は、インターネット２４の一連のルーター２２Ａ−２２Ｎに接続されている。インターネット２４は、ウェブサーバ２６とつながっている。地学的同調人工衛星を利用すると、人工衛星６０と地球上のステーション６４の間の信号の通信当たり、約２７０／１０００秒の遅れが出る。このように、ウェブブラウザ２０とウェブサーバ２６の間のデータ通信では、すくなくとも０．５秒のラウンドトリップ遅れが出る。
【００２３】
図４は、サテライトリンクシステム上で図２に示すデータの通信を示すタイミングダイアグラムである。インラインオブジェクトに対するネストされたリクエストの性質によって、システムは、ラウンドトリップ遅れと等しい最初のシステム遅れを招くだけではなく、インラインオブジェクトに対するリクエストが、つぎに行われるときに、さらに遅れを生じてしまう。
【００２４】
入りのメッセージ３０’は、ワイヤレスリンクにより送られる最初のURLリクエストを運ぶ。リンクのラウンドトリップ遅れにより、出のメッセージ３0’で運ばれるリクエストに対する最初の応答を運ぶ入りのメッセージ３２’は、遅れΔＴ_1Bの後に受け入れられる。入りのメッセージ３２’は、サウンドクリップであるインラインオブジェクトに対する外部からのリファレンスで構成されると仮定する。それに応えて、ウェブサーバ２０は、インラインオブジェクトに対するリクエストを運ぶ出のメッセージ３８’を送る。リンクのラウンドトリップ遅れにより、出のメッセージ３８’で運ばれるリクエストに対する最初の応答を運ぶ入りのメッセージ４２’は、遅れΔＴ_2Bの後に受け入れられる。応答のための入りのメッセージ４２’は、広告用バナーであるインラインオブジェクトに対する外部からのリファレンスを含むと仮定する。出のメッセージ４６’は、広告用バナーに対するリクエストを運ぶ。リンクのラウンドトリップ遅れにより、出のメッセージ４６’で運ばれるリクエストに対する最初の応答を運ぶ入りのメッセージ５２’は、遅れΔＴ_3Bの後に受け入れられる。
【００２５】
図４の遅れΔＴ_1B、ΔＴ_2B、ΔＴ_3Bは、図２のΔＴ_1A、ΔＴ_2A、ΔＴ_3Aよりかなり大きいことに注意すること。この差は、主に、ワイヤレスリンクに係わるラウンドトリップ遅れによる。リクエストが出されるたびに、第一応答は、少なくとも、ラウンドトリップの分だけ遅れる。このようにして、比較的大きい遅れを生じるリンクを利用すると、最初の決まった遅れとともに、平均的なデータ転送速度がかなり遅くなる。
【００２６】
図５は、プロキシサーバ６６を含むインタネット接続を示すブロックダイアグラムである。プロキシサーバ６６は、複数のウェブブラウザ２０Ａ−２０Ｎをインターナット２４にインターフェースするように設計されている。また、プロキシサーバ６６は、インターネット２４による進入からウェブブラウザ２０Ａ−２０Ｎ（およびウェブブラウザが走るネットワークも含めて）を守るように設計することもできる。例えば、プロキシサーバ６６は、他のインターネットユーザが、内部のネットワークにアクセスできないようにするワンウエイサーバにもできる。内部ユーザによるリクエストに応えて受けたパケットだけが、インターネット２４からプロキシサーバを通して、返される。プロキシサーバで受けた他のデータは、ウェブブラウザ２０Ａ−２０Ｎ上には通らない。
【００２７】
プロキシサーバ６６は、あるユーザ集合のために、ひとつの接続のポイントだけ提供するので、プロキシサーバ６６で、ウイルススキャン、コンテンツフィルター、アクセスコントロールのような機能を果たすのは、ウェブブラウザ２０Ａ−２０Ｎ個々で行うより簡単である。このように、会社は、プロキシサーバ６６をネットワークの中央制御ポイントとして使うことにより、社内ネットワークを制御できる。
【００２８】
プロキシサーバ６６は、ウェブブラウザ２０Ａ−２０Ｎが、プロキシサーバの存在に気づかないという意味で、システムユーザにわからないように設計できる。ウェブアクセスは、プロキシサーバを通して継ぎ目なしに起こる。ウェブブラウザ２０Ａ−２０Ｎは、プロキシサーバに気づかないけれども、最後の結果は、ウェブブラウザ２０Ａ−２０Ｎは、プロキシサーバー６６とインターネット２４からの組み合わされた情報を受けることになる。
【００２９】
しばしば、キャッシングは、ウェブブラウザ２０で感知されるように、システムのパーフォーマンスを上げるために使われる。キャッシングという言葉は、プロキシサーバ６６によって、ローカル保存メディア（代表的なのは、ディスクであるが、短期キャッシング用のメインメモリー）上で受けたドキュメントのコピーを保存するプロセスを指す。プロキシサーバ６６は、ウェブブラウザ２０Ａ−２０Ｎのそれぞれが、インターネットにアクセスする中心の場所を提供するので、プロキシサーバ６６は、アクセスしたドキュメントを頻繁にキャッシュし、そのドキュメントをそのドキュメントをリクエストした他のウェブブラウザ２０に対して直ぐに使えるようにできる。例えば、金融サービス機関では、多くの異なったブラウザが、いつもウォールストリートジャーナルのホームページにアクセスしている。プロキシサーバ６６にキャッシング能力があれば、ウォールストリートジャーナルのホームページは、１日の最初のリクエスト後にキャッシュできる。その後にリクエストする人は、インターネットからではなく、ローカルキャッシュからウォールストリートジャーナルを受けることになる。一般に、キャッシングは、待ち時間を減らし、ネットワーク用のバンド幅を節約することにより、システムの効率を改善する。
【００３０】
プレフェッチと言われる一種のキャッシングは、クライアントからリクエストされたと思われるドキュメントのキャッシングも含む。前にリクエストされた親ファイル内のインラインオブジェクトは、その例のひとつである。プロキシサーバが、元々の親ファイルを調べると、そのドキュメントが、インラインオブジェクトに対するリファレンスを含んでいるかどうかがわかり、ウェブブラウザからの実際のリクエストが着く前に、インラインオブジェクトの呼び出しが開始できる。
【００３１】
インラインオブジェクトをプレフェッチすると、リクエストの予言がかなり高い確率で当たる。ウェブブラウザが、インラインオブジェクトを自動的にロードできる構成になっていないまれなケースでは、リクエストの予言は失敗する。また、ユーザがインラインオブジェクトをすべてリクエストする前に、呼び出しを邪魔した場合は、いくつかのオブジェクトは、ウェブブラウザでリクエストされない。しかし、通常、親ドキュメントによってリファレンスされた各インラインオブジェクトは、ウェブブラウザでリクエストされる。
【００３２】
キャッシング能力を持つ従来の技術のプロキシサーバを、ワイヤレスサテライトリンクを持つインターネット接続に統合しようとする試みた場合、システム効率は、そんなに改善されない。例えば、図３を再度リファレンスして、プロキシサーバが、地球上のステーション６４とルーター２２Ａの間に挿入されていることを確認されたい。ウェブブラウザ２０によって、最初のリクエストが出されると、そのリクエストは、ワイヤレスリンク上のサテライト端末６０から、地球上のステーション６４に送られる。地球上のステーション６４は、このリクエストをプロキシサーバに送り、プロキシサーバは、それをインターネット２４に送る。インターネット２４からの応答が受信されると、プロキシサーバは、それを地球上のステーション６４に送る。また、プロキシサーバは、最初のリクエストに対する応答のなかの情報を分析して、インラインオブジェクトが存在するか決める。プロキシサーバは、インラインオブジェクトに対するリクエストを代理として送り、それが着いたオブジェクトを保存する。その間、最初のリクエストに対する応答は、ワイヤレスリンクを通じて、ウェブブラウザ２０に送られる。ウェブブラウザ２０が、応答を受けると、ウェブブラウザは、ワイヤレスリンクを通じてインラインオブジェクトに対するリクエストを送り返す。プロキシサーバがリクエストを受けると、プロキシサーバは、プレフェッチされ、キャッシュされた情報に応答する。このようにして、インターネット上で行われる伝送に係わる遅れはすべて取り除かれる。インラインオブジェクトに対応する情報は、ワイヤレスリンクを通って、ウェブブラウザ２０に達する。従って、ワイヤレスリンクのラウンドトリップ遅れは避けられない。ワイヤレスリンクのラウンドトリップ遅れは、図３のシステムの待ち時間を決定する際に、もっとも重要なファクターになるので、サテライトリンクのゲートウェイ側にプロキシサーバがあっても、システムの効率はそれ程改善されない。
【００３３】
また、サテライト端末６０とウェブブラウザ２０の間には、従来の技術によるプロキシサーバが挿入されているということを確認すること。ウェブブラウザ２０が、最初のリクエストを出すと、そのリクエストは、プロキシサーバに送られ、プロキシサーバは、それをサテライト端子６０に送る。サテライト端子６０は、それをワイヤレスリンクに乗せて地球上のステーション６４に送る。地球上のステーション６４は、このリクエストをインターネット２４に送る。インターネット２４からの応答を受けると、地球上のステーション６４は、その応答をワイヤレスリンクに乗せてサテライト端子とプロキシサーバに送る。プロキシサーバは、その応答をウェブブラウザ２０に送る。また、プロキシサーバは、情報を分析してインラインオブジェクトの存在を確認する。プロキシサーバは、インラインオブジェクトに対する代理リクエストを、ワイヤレスリンクに乗せて送ることにより、インラインオブジェクトをプレフェッチする。ウェブブラウザ２０が最初の応答を受けると、ウェブブラウザは、インラインオブジェクトに対するリクエストをプロキシサーバに送る。プロキシサーバが、ウェブブラウザからのリクエストを受けると、プロキシサーバは、リクエストを横取りして、ワイヤレスリンクに乗せて送らない。プロキシサーバは、代わりのリクエストとワイヤレスリンクを通るそれに対する応答を待ち、ウェブブラウザに情報を送る。このようにして、プロキシサーバからの最初の応答をウェブブラウザ２０に伝送する際の遅れとウェブブラウザ２０からのリクエストをプロキシサーバに伝送する際の遅れはすべて除去される。しかし、ワイヤレスリンクのランドトリップ遅れは、避けられない。ワイヤレスリンク上のラウンドトリップは、図３のシステムの待ち時間を求める際のもっとも重要なファクターであるから、サテライトリンクのサテライト端子側にプロキシサーバがあっても、システムの効率はそれ程改善されない。
【００３４】
図６は、本発明による分散型プロキシサーバを含むデジタルデータネットワークを示すブロックダイアグラムである。図６では、ウェブブラウザ２０Ａ−２０Ｎは、分散型プロキシサーバ６８によって、インターネットに接続する。分散型プロキシサーバ６８は、２つのコンポーネントを持つ。１）アクセスポイントコンポーネント７０（アクセスポイント）と２）サテライトゲートウェイコンポーネント７２（サテライトゲートウェイ）である。アクセスポイント７０とサテライトゲートウェイ７２は、１個以上のワークステーションまたは対応するソフトウエアを走らせるパソコン上に実装される。アクセスポイント７０とサテライトゲートウェイ７２の機能のすべてまたは一部は、アプリケーション指定のハードウエアを使って、選択的に実装できる。アクセスポイント７０とサテライトゲゲートウェイ７２は、人工衛星６２上のワイヤレスリンクを通して接続される。ウェブブラウザ２０Ａ−２０Ｎは、ローカルエリアネットワークによってアクセスポイント７０（図示されていない）と接続されるのが望ましい。図６に示されているように、アクセスポイント７０は、サテライトゲートウェイ７２によってプレフェッチされたオブジェクトを一時的に保存するためのオブジェクトキャッシュ７１を実装する。
【００３５】
分散型プロキシサーバ６８は、サテライトリンクに接続する際のラウンドトリップ遅れの効果を減らすことによって、効率のよいデータ転送を容易にする。アクセスポイント７０とサテライトゲートウェイ７２は、また、従来の技術によるプロキシサーバによって行われるサービスも提供する。実施例では、分散型プロキシサーバ６８を使用しているということは、インターネットに接続されている、ウェブサーバ２６やウェブブラウザ２０のような実体には、知られている。
【００３６】
図７は、リクエストされたウェブページが、インラインオブジェクトをリファレンスする親ファイルコンポーネントでできている本発明に従ったデータ転送の実施例を示すデータフローダイアグラムである。ブロック８０において、ウェブブラウザ２０は、ウェブページをリクエストする。アクセスポイント７０は、リクエストを受け、それをブロック８２のワイアレスリンク上のサテライトゲートウェイ７２に送る。幾分かの遅れの後、そのリクエストは、サテライトゲートウェイで受け取られる。ブロック８４では、サテライトゲートウェイ７２は、リクエストをインターネット２４に送る。サテライトゲートウェイ７２は、この機能を実行するためのネットワークコミュニケーションモジュールでできている。
【００３７】
ウェブサーバ２６は、リクエストを受け、親ファイルに応答する。サテライトゲートウェイ７２は、インタネット２４からの親ファイルを受け、それをブロック８６のアクセスポイント７０に送る。ファイルが、ワイヤレスリンクを横切った後、アクセスポイント７０は、ブロック８８のウェブブラウザ２０に親ファイルを送る。ブロック９０では、ウェブブラウザは、親ファイルを受ける。
【００３８】
ブロック８６の転送より以前、最中、または後に、サテライトゲートウェイは、この親ファイルを分析し、インラインオブジェクトに対するリファレンスを抽出し、ブロック９２のインタネット２４上のインラインオブジェクトに対するリクエストを送る。例えば、サテライトゲートウェイ７２は、これらの機能を果たすために、分析モジュール、代わりのリクエストを出すモジュールでできている。また、ブロック９２では、サテライトゲートウェイ７２は、プレフェッチしているインラインオブジェクトを識別するアクセスポイント７０に、メッセージを送る。例えば、サテライトゲートウェイ７２は、メッセージを作って、それをアクセスポイント７０に送るメッセージモジュールを有する。ブロック９４では、アクセスポイント７０は、プレフェッチされたオブジェクトのリストを受け、後にリファレンスするために、例えば、キャッシングモジュール内に保存する。
【００３９】
ブロック９６では、ウェブブラウザ２０は、インラインオブジェクトに対するリクエストを送る。ブロック９８では、アクセスポイント７０は、リクエストをプレフェッチされたオブジェクトと比較する。リクエストが、プレフェッチされたオブジェクトのリストに対応する場合は、そのリクエストは、横取りされ、ワイヤレスリンク上に送られない。リクエストされたオブジェクトが、リストに載っているものに対応せず、キャッシュ内にない場合は、アクセスポイント７０は、ワイヤレスリンク上にリクエストを送る。この機能は、メッセージ分析および比較モジュールにより実行される。
【００４０】
図７の例では、フェッチされたか現在フェッチされてりるオブジェクトのリスト上に、インラインオブジェクトがあるので、アクセスポイント７０は、リクエストを横取りしてサテライトリンク上にリクエストを送らない。その間、ブロック１００では、インラインオブジェクトが、サテライトゲートウェイ７２で受け取られ、自動的にアクセスポイント７０に送られる。サテライトゲートウェイ７２は、インラインオブジェクトに対するリクエストを受けずに、アクセスポイント７０がサテライトゲートウェイ７２を通じてリクエストしていなかった情報を含めて、最初のリクエストに対する返答をアクセスポイント７０に送っている。このような返答は、”チュビー レスポンス（chubby response）”と言う。例えば、サテライトゲートウェイ７２は、これらの機能を果たすチュビー レスポンス作成モジュールを有する。ブロック１０２では、アクセスポイント７０は、オブジェクトを受け、それをウェブブラウザ２０に送る。ブロック１０４では、ウェブブラウザ２０は、インラインオブジェクトを受ける。このようにして、サテライトリンク上で、リクエストの伝送を待つ際の遅れは避けられ、インラインオブジェクトは、親ファイルの後直ぐに転送される。さらに、普通、インラインオブジェクトに対するワイヤレスリクエストによって占められるバンド幅は、他の用途にも使われる。
【００４１】
図７に示すようなデータフローを使って得られる効率は、図８のタイミングダイアグアムを参照すれば、簡単にわかる。図８は、本発明による分散型プロキシサーバ上を転送されるのと同様に行われる、図２、４のデータ伝送を示すタイミングダイアグラムである。ウェブブラウザ２０で感知されるデータフローに加えて、データフローをもっと明確に説明するために、アクセスポイント７０とサテライトゲートウェイ７２によって感知されるデータフローを示す。
【００４２】
ウェブブラウザから出るメッセージ１３０は、最初のＵＲＬリクエストを運ぶ。アクセスポイント７０は、それに対応する出のメッセージ１３０’をワイヤレスリンク上にに送る。サテライトゲートウェイ７２は、対応する出のメッセージ１３０’’をインターネット上に送る。ワイヤレスリンクの導入による、出のメッセージ１３０’と１３０’’の間の遅れに注意すること。入りのメッセージ１３２’’は、でのメッセージ１３０’に対する応答の最初の部分を運ぶ。いりのメッセージ１３４’’と１３６’’は、応答の第二、第三の部分を運ぶ。入りのメッセージ１３２’’は、サウンドクリップと仮定したインラインオブジェクトに対する外部からのリファレンスを運ぶ。サテライトゲートウェイ７２は、入りのメッセージ１３２’’を分析して、外部からのリファレンスを認識する。出のメッセージ１３８’’では、サテライトゲートウェイ７２は、サウンドクリップに対するイナターネット２４上の代わりのリクエストを送る。このようにして、サウンドクリップをプレフェッチする。
【００４３】
入りのメッセージ１３２’’、１３４’’、１３６’’は、それぞれ入りのメッセージ１３２’、１３４’、１３６’としてアクセスポイント７０に受け入れられ、ワイヤレスリンクによる遅れがもう一度生じる。アクセスポイント７０は、これらのメッセージをウェブブラウザ２０に送り、 それぞれ入りのメッセージ１３２、１３４、１３６として受け入れられる。入りのメッセージ１３２に対する応答では、ウェブブラウザ２０は、サウンドクリップをリクエストしている出のメッセージ１３８を送る。出のメッセージ１３８がウェブブラウザ２０から送られる時には、出のメッセージ１３８’’は、既にサテライトゲートウェイ７２によって、インターネット２４に送られている。従って、アクセスポイント７０は、リクエストを横取りし、それをゲートウェイ７２に送らない。このよにして、サテライトリンンク上に送られるデータ量を減らす。そのために、図８では、対応するメッセージ１３８’’は、アクセスポイント７０からサテライトゲートウェイ７２には送られない。サテライトゲートウェイ７２では、入りのメッセージ１４０’’が、元のリクエストに対する四番めおよび最後の応答として受け取られ、アクセスポイント７０に送られ、入りのメッセージ１４０’として受けられる。
【００４４】
入りのメッセージ１４２’’と１４４’’は、サウンドクリップに対するリクエストに対する応答として受けられ、る。入りのメッセージ１４２’’は、広告バナーと仮定したインラインオブジェクトに対する外部からのリファレンスを運ぶ。再度、サテライトゲートウェイ７２は、入りのメッセージ１４２’’を分析して、広告バナーに対する外部からのリファレンスを検出する。出のメッセージ１４６’’は、広告バナーに対する代わりのリクエストを運んでいるサテライトゲートウェイ７２によって、送られる。
【００４５】
その間、入りのメッセージ１４２’’と１４４’’は、インラインオブジェクトに対するアクセスポイント７０からのリクエストを待つことなく、自動的にアクセスポイント７０に送られる。このようにして、インラインオブジェクトは、ワイヤレスリンクを通して、プレフェッチされ、事前転送され、ウェブブラウザ２０が感知する待ち時間を大きく減らす。入りのメッセージ１４２’’と１４４’’は、それぞれアクセスポイント７０で、入りのメッセージ１４２’、１４４’として受け入れられる。入りのメッセージ１４２’と１４４’は、ウェブブラウザ２０によって出のメッセージ１３８のなかでリクエストされた後、ウェブブラウザ２０に送られる。メッセージ１４２’と１４４’は、それぞれ、入りのメッセージ１４２、１４４としてウェブブラウザ２０に受け入れられる。広告バナーに対する外部からのリファレンスを含む入りのメッセージ１４２の受け入れに対する応答として、ウェブブラウザ２０は、広告バナーをリクエストしているでのメッセージ１４６を送る。アクセスポイント７０は、再度リクエストを横取りして、対応する出のメッセージ１４６’は、アクセスポイント７０からサテライトゲートウェイ７２に対して送られない。
【００４６】
その間、サテライトゲートウェイ７２は、サウンドクリップに対するリクエストの応答として、入りのメッセージ１４８’’と１５０’’を引き続き受け、それらを、アクセスポイント７０に送る。アクセスポイント７０は、これらのメッセージを、ワイヤレスリンクによる遅れを伴って、入りのメッセージ１４８’と１５０’として受ける。アクセスポイント７０は、これをウェブブラウザ２０に送り、ウェブブラウザ２０は、これを入りのメッセージ１４８と１５０として受け入れる。出のメッセージ１４６’’のなかに出された広告バナーに対するリクエストへの応答として、入りのメッセージ１５２’’が、サテライトゲートウェイで受け取られ、それに対応するリクエストを待つことなく、自動的にアクセスポイント７０に送られる。アクセスポイント７０は、入りのメッセージ１５２’として、広告バナー情報をを受け、出のメッセージ１４６で運ばれるリクエストに対する応答として、ウェブブラウザ２０にそれを送り、ウェブブラウザ２０は、これを入りのメッセージ１５２として受ける。
【００４７】
図８と図４に示す従来の技術を比較すると、本発明を使うことによる効率アップがわかる。図４の入りのメッセージ３０’と３２’の間の実質的な遅れΔＴ_1Aに対して、図８では、入りのメッセージ１３０と１３２の間の実質的な遅れΔＴ_ICがあることに注意すること。この遅れの大部分は、ワイヤレスリンクを使うことによるラウンドトリップディレイによるものである。しかし、図４のでのメッセージ３８’と入りのメッセージ４２’の間の実質的な遅れΔＴ_2Bは、図８の出のメッセージ１３８と入りのメッセージ１４２の間の遅れΔＴ_2Cには出ていない。これは、情報がプレフェッチされ、また、チュビー レスポンスとして事前に転送されているからである。さらに、図４の出のメッセージ４６’と入りのメッセージ５２’の間の実質的な遅れΔＴ_3Bは、図８のでのメッセージ１４６と入りのメッセージ１５２の間の実質的な遅れΔＴ_3Cには出ていないが、これも同じ理由による。図８の遅れΔＴ_2CとΔＴ_3Cは、図２の遅れΔＴ_2AとΔＴ_3Aに匹敵する。このようにして、本発明を利用することにより、平均のデータ速度が上がり、システム利用について回る遅れが減る。
【００４８】
図７では、アクセスポイント７０は、「インラインオブジェクトは、インラインオブジェクトに対するリクエストがブロック９６のウェブブラウザ２０によって出される前に、ブロック９４でプレフェッチされた」ということを知らされる。しかし、場合によっては、ウェブブラウザ２０は、プレフェッチの連絡を受ける前に、インライオブジェクトをリクエストすることがある。そのような場合は、アクセスポイント７０は、予めプログラム化された時間、例えば３秒間、このリクエストを保存する。時間内にオブジェクトが、プレフェッチオブジェクトのリストに現れないか、アクセスポイント７０で受けたオブジェクトではない場合は、アクセスポイント７０は、サテライトゲートウェイ７２にリクエストを送る。リクエストの伝送を遅らせることにより、ワイアレスリンク上から伝送するリクエストの数を減らせる。
【００４９】
プレフェッチされ、チュビー レスポンスとして送られるオブジェクトに係わる、ウェブブラウザ２０からの関連リクエストの問題は、他の実施例で避けられる。ある実施例では、アクセスポイント７０は、入りのファイルを分析して、サテライトゲートウェイ７２に似たやり方でインラインオブジェクトの存在を確認する。アクセスポイント７０は、サテライトゲートウェイ７２は、これらのインラインオブジェクトをすべてプレフェッチすると仮定する。例えば、ブロック８８で、アクセスポイント７０で親ファイルを受けると、アクセスポイント７０は、親ファイルを分析してインラインオブジェクトに対するリファレンスをすべて抽出する。アクセスポイント７０は、ゲートウェイ７２は、インラインオブジェクトをプレフェッチ中であるとして、すべてインラインオブジェクトを含むプレフェッチされたオブジェクトのリストを作る。アクセスポイント７０は、常にウェブブラウザ２０の前で親ファイルを受けるので、アクセスポイント７０は、ウェブブラウザ２０からリクエストを受ける前にプレフェッチオブジェクトのリストを作る。プレフェッチオブジェクトのリストに現れるリクエストは受け入れられるが、オブジェクト自身は、与えられた時間内にアクセスポイント７０で受け入れられない場合は、アクセスポイント７０は、サテライトゲートウェイ７２にリクエストを送る。この実施例では、サテライトゲートウェイ７２からの連絡用データは、図７のブロック９２のアクセスポイント７０に送られ、サテライトリンク上から伝送されるデータの量は、このようにして減らされるということに注意しなければならない。関連した問題が避けられるので、アクセスポイント７０は、利用できない、あるいはリストにないオブジェクトに対するリクエストを受けても、オブジェクトに対するリクエストの送り出しが遅れずに済む。システムの利用に伴う待ち時間は、このようにして全体的に減る。
【００５０】
さらに、アクセスポイント７０の分析機能を高めることなく、関連問題が解決される他の実施例もある。再度、図７に戻ってみると、サテライトゲートウェイ７２は、ブロック８６のインタネット２４からの親ファイルを受けると、まず親ファイルを調べて、親ファイル情報をアクセスポイント７０に送る前に、インラインオブジェクトに対する外部からのリファレンスがあったかどうか見極める。リファレンスがない場合は、サテライトゲートウェイ７２は、直ぐにアクセスポイント７０に親ファイルを送る。１個以上のリファレンスがあると、サテライトゲートウェイ７２は、アクセスポイント７０に対する親ファイルの転送を開始する前に、リクエストを出して、１個以上のインラインオブジェクトに対応するデータを受ける。このようにして、インラインオブジェクトは、首尾一貫して直接親ファイルに従い、ウェブブラウザ２０によるリクエストがあった場合に、アクセスポイント７０で利用できる。ある実施例では、サテライトゲートウェイ７２は、アクセスポイント７０への親ファイル転送を開始する前に、インラインオブジェクトをすべて受ける。もうひとつの実施例では、サテライトゲートウェイ７２は、アクセスポイント７０への親ファイル転送を開始する前に、１個以上のインラインオブジェクトをすべて受ける。さらに他の実施例では、サテライトゲートウェイ７２は、アクセスポイント７０への親ファイル転送を開始する前に、１個以上のインラインオブジェクトの一部に対応する決まった量のデータを受ける。関連する問題を避けることに加えて、この方法では、サテライトゲートウェイ７２からアクセスポイント７０に連絡用メッセージを送らなくても、ワイアレスリンク上を走る情報の流れを減らせる。関連した問題が起こらないので、アクセスポイント７０は、利用できないオブジェクトに対するリクエストを受けても、オブジェクトに対するリクエストを遅れて出すことがなくなる。システム使用に伴う待ち時間は、このようにして全体的に減る。
【００５１】
これらの実施例において、親ウェブページが表示された後、すぐにウェブブラウザ２０でインラインオブジェクトが利用できるということは、ユーザに対する応答がすぐに出せるという利点がある。
【００５２】
また別の実施例では、サテライトゲートウェイ７２で親ファイルを受けると、サテライトゲートウェイ７２は、親ファイルを分析し、インラインオブジェクトのリクエストを開始する。インラインオブジェクトが受け取られると、サテライトゲートウェイ７２は、アクセスポイント７０にインラインオブジェクトを送る。サテライトゲートウェイ７２が、他のインラインオブジェクトの中のネストされたインラインオブジェクトを含むインラインオブジェクトのすべてまたは一部をリクエストし、受け、転送した後、サテライトゲートウェイ７２は、アクセスポイント７０に親ファイルを送り始める。親ファイルの転送前に、プレフェッチインラインオブジェクトを転送すると、ウェブブラウザ２０がリクエストしてくる前に、すべてのインラインオブジェクトがアクセスポイント７０で利用できる。さらに、この実施例では、連絡用メッセージを使ったり、アクセスポイント７０に機能を追加したりする必要がなく、アクセスポイント７０は、意図的な遅れを挿入することなく、未知のオブジェクトに対するリクエストも送れる。
【００５３】
上に述べたように、データは、通常ＨＴＴＰプロトコルに従った現在の標準的なデジタルデータネットワーク上で転送される。ＨＴＴＰプロトコルは、リクエスト／レスポンス式プロトコルである。クライアントが、サーバにリクエストを送ると、サーバは、応答を返してくる。この簡単なプロトコルでは、各データ伝送開始時に、マルチステップのハンドシェイクルーティンの使用を避けている。しかし、ＨＴＴＰプロトコルのなかには、クライアントが、リクエストを出していないデータの転送を、チュビー レスポンスメッセージの中で受けるという条件はない。
【００５４】
実施例では、サテライトゲートウェイ７２をアクセスポイント７０に接続させているリンクは、チュビー レスポンスメッセージを使って、リクエストされていないデータを送る方法も含んでいる。そのような機能を持たせるために、サテライトゲートウェイ７２をアクセスポイント７０に接続させているリンクは、純粋なＨＴＴＰプロトコルの外にある。分散型プロキシサーバ６８が、ウェブブラウザ２０とウェブサーバ２６に対して透明性を持っているということは、重要なことである。従って、分散型プロキシサーバ６８は、ＨＴＴＰのようなよく知られたデータ転送プロトコルを、少なくとも、外部で感知されるように、サポートすることも重要である。しかし、サテライトゲートウェイ７２とアクセスポイント７０は、一般のアクセスプロバイダーによってコントロールされるピアーユニットであるから、アクセスポイント７０とサテライトゲートウェイ７２を接続するリンクが、工業標準プロトコルに従って働く必要はない。従って、技術に熟練した人は、チュビー レスポンスを使って、サテライトゲートウェイ７２とアクセスポイント７０の間にリクエストされないデータの転送を起こす、よく知られた技術に従ってプロトコルを開発できる。
【００５５】
図６では、１個のウェブブラウザ２０が、分散型プロキシサーバ６８に連結している。さらに、サテライトゲートウェイ７２は、複数のアクセスポイント７０ユニットを補助することができる。アクセスポイント７０は、1個のハウシング内にまとめられる実施例もあり、そのハウシングは、ハウジングがあるビルの外にあるアンテナに連結する。ローカルエリアネットワークは、複数のウェブブラウザ２０をハウジングに連結する。もう一つの実施例では、アクセスポイント７０は、同じマシンまたはウェブブラウザ２０が働くハウジングに実装される。さらに、他の実施例では、アクセスポイント７０の機能とモジュールは、複数のコンピューターユニットに分配される。一般に、アクセスポイントの機能とモジュールは、サブジェクトリンクの一方の側の実体に分配でき、ゲートウェイの機能とモジュールは、リンクのもう一方の側の実体に分配される。アクセスポインントとゲートウェイのいずれかが、直接サブジェクトリンクと中間実体に連結される必要はないし、また、サブジェクトリンクが、アクセスポイントとゲートウェイを分ける必要もない。
【００５６】
上に述べた技術と同じ技術は、他の外部ファイルに対してつぎに出されるリクエストの可能性が、インラインオブジェクトに対して出されるリクエストの可能性より低くても、その外部ファイルに応用できる。例えば、多くのウェブページは、ユーザが選んでアクセスする他のウェブページに連結するハイパーリンクを含む。製造会社のホームページは、は、雇用ページ、製品情報のページ、会社案内のページおよび広報のページにつながるハイパーリンクを有する。ホームページにアクセスするユーザは、ハイパーリンクでリファレンスされるページのひとつにアクセスするらしい。サテライトゲートウェイ７２は、すべてのインラインオブジェクトを呼び出した後、予言的なリンクされたウェブページのプレフェッチとアクセスポイント７０への転送を、インラインオブジェクトと同じように開始する。データ量は、限りないカスケードを防ぐために制限される。ユーザが、予言的にプレフェッチされリンクの一つをリクエストすると、ユーザは、アクセスポイント７０から直接情報を受け取り、それによって、ワイヤレスリンクの使用に伴うラウンドトリップ遅れが避けられる。一般に、プレフェッチされたオブジェクトは、テキストまたはデジタルフィル、画像、サウンドクリップ、プログラムモジュール、外部機能付きのデータパッケージである。
【００５７】
上記の例は、インターネット上のウェブサーバにアクセスしているウェブブラウザにより説明されているが、本発明の原理は、データ端子が、リンクすると実質的に遅れが生じるデータネットワーク上の外部データに対するリファレンスを含むデータファイルをリクエストする状況にも応用できる。そのような場合は、リクエストユニットは、ファイルリクエストを出せるデジタル機器であれば種類は問わない。また、応答ユニットは、ファイルを転送できれば、どんなタイプでもよい。例えば、図のインターネット２４は、公共または私的なローカルエリアネットワークまたはインターネット以外のワイドアリアネットワークでもよい。
【００５８】
技術に熟練した人がこの発明の開示を調べれば、何万例の実施例があることが直ぐにわかる。例えば、望ましい実施例は、サテライトリンクで説明されているが、本発明は、有線、無線に関係なくかなりの遅れを生むリンクに直接応用できる。
【００５９】
さらに、上に述べたように、本発明を使うと、アクセスポイントからゲートウェイに流れるデータの量が減る。このデータ量の現象は、アクセスポイントとゲートウェイ間のパスの遅れが実質的にないシステムでも重要である。例えば、ケーブルモデムは、かなり非対称のリンクである。インターネットからユーザ経のダウンストリームリンクは、かなり高いバンド幅を持っているが、ユーザからインターネットへのアップストリームのバンド幅は制限されている。従って、遅れが問題にならないばあいでも、アップストリームの情報の流れを減らすために、分散型プロキシサーバを組み込むと有利である。
【００６０】
本発明は、発明の精神と添付した請求項で定義された本質的な特徴から逸脱することなく、他の形態でも実施できる。下記の特許請求の範囲では、プロセスのステップを参照するのに使っている参照符号は、説明を簡便にするためのみに使っており、ステップを実施する順序を意味するものではない。
【図面の簡単な説明】
【図１】 インターネット接続を示すブロックダイアグラムである。
【図２】 データの転送とウェブブラウザからのデータ転送を示すタイミングダイアグラムである。
【図３】 サテライトリンクでできているインターネット接続を示すブロックダイアグラムである。
【図４】 サテライトリンクをシステムに取り入れた後の図２に示すデータ通信を示すタイミングダイアグラムである。
【図５】 プロキシサーバで構成されるインターネット接続を示すブロックダイアグラムである。
【図６】 本発明による分散型プロキシサーバで構成されるデジタルデータネトワークを示すブロックダイアグラムである。
【図７】 本発明によるデータ転送の実施例を示すデータフローダイアグラムである。
【図８】 本発明による分散型プロキシサーバ上でのデータ転送と同じように行われる、図２、４に示すデータ通信を示すタイミングダイアグラムである。

Claims (16)

1. クライアントサイド（７０）およびクライアントサイド（７２）と離れたサーバサイドを備える通信用リンク（６２）を含むインターネットアクセスシステムにおいて、
   インラインオブジェクトを含むドキュメントに対するクライアントリクエストを処理する方法であって、
   前記クライアントリクエストはクライアント（２０）よって出され、ドキュメントサーバ（２６）に向かうものであり、
   前記ドキュメントはインラインオブジェクトに対するリファレンスを含む基本コンポーネントからなり、
   さらに前記方法が、
   通信リンク（６２）のクライアント（２０）側において、
   （ａ）クライアントリクエストを受け、そのリクエストを通信リンク（６２）上でサーバ（２６）側（７２）に送り（８２）、
   通信リンクのサーバ側において、
   （ｂ）クライアントリクストを受け、インターネット（２４）上でドキュメントサーバ（２６）にリクエストを送り（８４）、
   （ｃ）ドキュメントサーバから基本コンポーネントを受け（８８）、基本コンポーネントを分析してオブジェクトに対するリファレンスを識別し（９２）、通信用リンク（６２）上でクライアント（２０）に届けるために、クライアント（２０）側に基本コンポーネントを送り（８８）、
   （ｄ）ステップ（ｃ）で識別したリファレンスを用い、ドキュメントサーバ（２６）からインラインオブジェクトをプレフェッチし（９２）、クライアント（２０）がオブジェクトをリクエストするのを待つことなく、クライアント（２０）に届けるために、通信リンク（６２)上でオブジェクトをクライアント（２０）に送る、
   ステップからなり、
   前記方法が、少なくともドキュメントサーバに意識されないように処理されることを特徴とする方法。
2. さらに、通信リンクのクライアント側で
   （ｄ）で送られたオブジェクトを受け、キャッシングし、
   オブジェクトに対するリクエストへの応答として、クライアント（２０）にオブジェクトを送る（１０２）ステップを有する請求項１記載の方法。
3. 通信リンク（６２）のクライアント側にオブジェクトが着くのを待つ間に、通信リンク（６２）上のオブジェクトに対するクライアントリクエストの伝達（９８）を受け入れるステップを更に備えること請求項１に記載の方法。
4. 通信用リンクは、サテライトリンク（６２）であり、サテライトリンク上で、オブジェクトに対するクライアント（２０）リクエストを送る際の遅れを避ける請求項１記載の方法。
5. ステップ（ａ）は、サテライトリンクへのユーザアクセスポイントで走る実行可能なコンポーネントによって実施され、ステップ（ｂ）から（ｄ）は、サテライトからインターネットへのゲートウェイコンポーネントによって実施される請求項４記載の方法。
6. さらに、複数の追加されたドキュメントのインラインオブジェクトのそれぞれにステップ（ｄ）を繰り返す請求項１記載の方法。
7. ステップ（ａ）は、標準的なインターネットプロトコルを使ったウェブブラウザプログラム（２０）との通信を含む請求項１記載の方法。
8. ドキュメントは、第二のドキュメントとリンクするハイパーテキストリンクを含み、さらに、サーバ（２６）側で、第二ドキュメントをプレフェッチし、クライアント（２０）側に送る請求項１記載の方法。
9. ドキュメントのインラインオブジェクトがリクエストされ、ドキュメントの基本コンポーネントと別に呼び出される、クライアントサーバタイプのドキュメント呼び出しシステムにおいて、
   通信用リンク（６２）によって生まれる効率の低下を食い止める分散システム（６８）であって、
   前記分散システムは、
   通信用リンク（６２）のクライアント側で走り、クライアント（２０）と通信する第一コンポーネント（７０）であって、クライアント（２０）からのドキュメントリクエストを受け、そのリクエストを処理するための通信リンク（６２）上で送る第一のコンポーネントと（７０）；
   通信用リンク（６２）のサーバ側で走り、ドキュメントサーバ（２６）と通信する第二コンポーネント（７２）であって、通信リンク（６２）上で第一コンポーネント（７０）からのドキュメントリクエストを受け、そのリクエストをドキュメントサーバに送るための第二コンポーネント（７２）と；を備え、
   前記リクエスト（７２）によって、ドキュメントサーバ（２６）は、リクエストされたドキュメントの基本コンポーネントを戻し、
   前記第二コンポーネントは、少なくとも(i)基本コンポーネントを分析してインラインオブジェクトに対するリファレンスを識別し、(ii)インライオブジェクトをプレフェッチし、(iii)プレフェッチされたインラインオブジェクトを、クライアントがインラインオブジェクトに対するリクエストを出すのを待つことなく、第一コンポーネント（７０）に送り；
   また、第一コンポーネント（７０）は、第二コンポーネントから受けたプレフェッチされたインラインオブジェクトを、キャッシュメモリー（７１）に保存し、インラインオブジェクトをキャッシュメモリー（７１）からクライアント（２０）に送ることにより、クライアント（２０）からのオブジェクトリクエストに応え、；
   前記分散システムが、少なくともドキュメントサーバ（２６）に意識されないように実行されることを特徴とする分散システム。
10. 第一のコンポーネント（７０）が、通信リンク（６２）上のプレフェッチされたオブジェクトに対するクライアントリクエストの伝達を受け入れ、通信リンク（６２）の通信量を減らす請求項９に記載の分散システム。
11. 通信用リンクは、サテライトリンク（６２）であり、第一、第二コンポーネント（７０，７２）は、サテライトリンク上でインラインオブジェクトに対するリクエストを出す際の遅れを減らす請求項９記載の分散型システム。
12. 第一コンポーネント（７０）は、サテライトリンク（６２）へのクライアントアクセスポイントで走り、第二コンポーネント（７２）は、サテライトからインターネットへのゲートウェイシステムの一部である請求項１２記載の分散型システム。
13. 通信用リンク（６２）は、ケーブルをベースとするリンクであって、前記ケーブルをベースとするリンクは、ケーブルモデムにより、インターネットへのアクセスを提供する請求項９記載の分散型システム。
14. ドキュメント呼び出しシステムは、ハイパーテキストシステムであり、第二コンポーネント（７２）は、さらにリクエストされたドキュメント内でハイパーテキスト的にリファレンスされるドキュメントをプレフェッチするように構成されている請求項９記載の分散型システム。
15. 第一コンポーネント（７０）及び第二コンポーネント（７２）は、クライアント（２０）及びドキュメントサーバ（２６）とそれぞれ通信するために、標準のワールドワイドウェブプロトコルを実行する請求項９記載のシステム。
16. 第二コンポーネント（７２）が、プレフェッチされたオブジェクトの通信リンク（６２）上で第一コンポーネント（７０）を識別する請求項９記載の分散型システム。

Images