JP5948111B2 - パケット通信装置および方法 - Google Patents

パケット通信装置および方法 Download PDF

Info

Publication number
JP5948111B2
JP5948111B2 JP2012085993A JP2012085993A JP5948111B2 JP 5948111 B2 JP5948111 B2 JP 5948111B2 JP 2012085993 A JP2012085993 A JP 2012085993A JP 2012085993 A JP2012085993 A JP 2012085993A JP 5948111 B2 JP5948111 B2 JP 5948111B2
Authority
JP
Japan
Prior art keywords
client
request
server
file
side proxy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2012085993A
Other languages
English (en)
Other versions
JP2013218387A (ja
Inventor
裕司 大石
裕司 大石
通貴 奥野
通貴 奥野
大 明石
大 明石
伊藤　大輔
大輔 伊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2012085993A priority Critical patent/JP5948111B2/ja
Publication of JP2013218387A publication Critical patent/JP2013218387A/ja
Application granted granted Critical
Publication of JP5948111B2 publication Critical patent/JP5948111B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)

Description

本発明は、パケット通信装置および方法に関する。
ウェブシステムにおいて、クライアント側で、サーバからの情報を表示しようとする場合、クライアントサーバ間で、ウェブブラウザはHTMLを解析し、オブジェクトを発見するたびにそのオブジェクトに対するGETリクエストをサーバに送信する。通常ブラウザから一つのサーバへの同時接続数は制限されているため、ウェブページの読み込みにはクライアント・サーバ間の往復が多数回行われることとなる。
クライアントとサーバが大陸間海底ケーブルなどの遅延の大きなワイドエリアネットワーク (Wide Area Network: WAN)により接続されている場合、ハイパーテキスト転送プロトコル (Hyper Text Transfer Protocol: HTTP)による通信は、効率が著しく低下する。遅延の大きなネットワークでは、クライアントがリクエストを送信してからサーバからレスポンスが返ってくるまで長い時間がかかり、クライアントはその間待機する必要を生じる。これが多数回行われるためウェブページをリクエストしてから表示が完了するまでの時間が長くなる。
例えば、クライアントとサーバが、衛星回線を通じて通信し、ＨＴＴＰプロトコルに従って、サーバから衛星回線を介してダウンロードされるウエブページのインラインオブジェクトの呼び出し遅れを防ぐために、分散プロキシサーバが、基本コンポーネントの取得時に、インラインオブジェクトを先読みする技術が特許文献１に開示されている。
また、ＨＴＴＰ方式を拡張して、サーバ上のファイルを容易に編集可能としたWebDAV (Web Distributed Authoring and Versioning) という方式がある（非特許文献１）。WebDAVではサーバ上のファイルやフォルダをWebDAVクライアント経由で操作可能である。WebDAVでもHTTPと同様のリクエストが用いられるほか、フォルダ内のファイルに関するプロパティ情報を取得するためのPROPFINDというリクエストが用いられる。
しかしながら、ＷｅｂＤＡＶではＨＴＴＰと異なり、ファイルが基本コンポーネントとそれに付随するインラインオブジェクトのような主従関係になっておらず、特許文献１の技術を適用しても、ファイルの関係性を見出すことができないため先読みすることはできない。
そこで、本発明では、WebDAVをWAN経由で利用する場合に、適切なファイル一覧の取得方法を実現することを、一目的とする。
また、WebDAVではファイル一覧の情報を取得したとしても、次のリクエストが判明しないとそれらのファイルを転送するべきか否かを断定できないため、ファイルの転送が不要な場合にもファイルの転送を行ってしまう。そこで本発明では、必要な場合のみに複数のファイルを効率的に転送することを他の目的とする。また、WebDAVをWAN経由で利用する場合に適切なファイルの高速転送を実現することを他の目的とする。
少なくともいずれか一の課題を解決するために、本発明の一態様は、クライアントと接続されるクライアント側プロキシと、サーバと接続されるサーバ側プロキシとを含むシステムで、前記クライアントおよび前記サーバの間の通信を中継する通信方法であって、前記クライアントと前記サーバの間で前記クライアントからのリクエストに対して前記サーバがレスポンスを送信する形式の通信方法において、前記クライアントからが送信される第一のリクエストで取得される複数ファイルのリストを含むレスポンスを、クライアントに送信し、前記クライアントから、前記リストに関連する第二のリクエストを受領した場合、 前記クライアントからのリクエストを待たずに、前記サーバに対して前記リストに該当する複数ファイルを取得するためのリクエストを送信し、前記複数ファイル取得リクエストに対するレスポンスとして前記複数ファイルのリストに該当する前記複数ファイルの実体を、前記サーバからプリフェッチする、ことを特徴とする通信方法。
また別の態様は、クライアント装置とサーバ装置間で、サーバに格納されるデータの通信制御を行うプロキシシステムであって、クライアントと通信するクライアント通信部と、サーバと通信するサーバ通信部と、前記クライアントからの、第一のリクエストに対するレスポンスに含まれる複数の情報のうち、少なくともいずれか一の情報の取得要求を前記クライアントから受信した場合、前記レスポンスに含まれる複数の情報の取得要求を、サーバに送信し、前記複数の情報取得要求に対するレスポンスを、前記サーバからの受領した場合、前記クライアントに当該レスポンスを送信する、送信制御部と、を有する態様である。
ＨＴＴＰやＷｅｂＤＡＶに従う通信で、サーバからクライアントへの複数ファイルを効率的に転送する。
本発明の実施例１における通信方式を表すシーケンス図である。 本実施例におけるネットワーク構成図である。 本実施例におけるクライアント側プロキシの内部構成を表す図である。 本実施例におけるサーバ側プロキシの内部構成を表す図である。 本実施例におけるクライアント側プロキシおよびサーバ側プロキシのデータ管理テーブルを表す図である。 本発明の実施例１におけるクライアント側プロキシの動作を表すフローチャートである。 本発明の実施例１におけるサーバ側プロキシの動作を表すフローチャートである。 本発明の実施例２における通信方式を表すシーケンス図である。 本発明の実施例２におけるクライアント側プロキシの動作を表すフローチャートである。 本発明の実施例２におけるサーバ側プロキシの動作を表すフローチャートである。 本発明の実施例３における通信方式を表すシーケンス図である。 本発明の実施例３におけるクライアント側プロキシの動作を表すフローチャートである。 本発明の実施例３におけるサーバ側プロキシの動作を表すフローチャートである。 本発明の実施例４における通信方式を表すシーケンス図である。 本発明の実施例４におけるクライアント側プロキシの内部構成を表す図である。 本発明の実施例４におけるサーバ側プロキシの内部構成を表す図である。 本発明の実施例４におけるクライアント側プロキシおよびサーバ側プロキシのデータ管理テーブルを表す図である 本発明の実施例４におけるクライアント側プロキシの動作を表すフローチャートである。 本発明の実施例４におけるサーバ側プロキシの動作を表すフローチャートである。
図２は本実施例におけるネットワーク構成を表す図である。
クライアント（１１）と同一のLAN（１３）内にクライアント側プロキシ（１２）を設置し、クライアント側プロキシ（１２）がWAN（１４）との通信を行う。同様に、サーバ（１６）と同一のLAN（１７）内にサーバ側プロキシ（１５）を設置し、サーバ側プロキシ（１５）がWANとの通信を行う。クライアント側プロキシ（１２）とサーバ側プロキシ（１５）が協調して動作することにより、ＬＡＮに比べて遅延の大きなWANでも性能劣化を抑えて通信を行うことを可能とする。
本実施例では、クライアント側プロキシ（１２）とサーバ側プロキシ（１５）が協調して動作するシステムを説明するが、クライアント側プロキシ（１２）あるいはサーバプロキシ（１５）が他方のプロキシの動作を兼ねて、他方の処理を省略するプロキシシステムであってもよい。
本発明の第一の実施例における通信シーケンスを図１に示す。図１では通信にかかわる、少なくとも一以上のクライアント（１１）、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）、およびサーバ（１６）のシーケンスを示している。
クライアントがサーバ上のフォルダにアクセスする際、まず、クライアントは、そのフォルダに対してPROPFINDというリクエスト（１０１）を発行する。このリクエストは、クライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWANを介してを転送される（１１１）。
サーバ側プロキシ（１５）は、PROPFINDを受信すると、サーバ（１６）へさらに転送する（１２１）。PROPFINDを受信したサーバ（１６）はそれに対するレスポンスを生成し、クライアントに向けてＷＡＮ側へ返送する（１２２）。このレスポンスにはフォルダ内のファイル一覧が含まれる。同レスポンスはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１１２）、サーバ側プロキシ（１５）は、ＰＲＯＰＦＩＮＤに対するレスポンスを解析し、フォルダ内のファイル一覧を取得する。さらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１０２）。クライアント側プロキシ（１２）でも同様にこのレスポンスを解析し、ファイル一覧を取得する。クライアント（１１）はクライアント側プロキシ（１２）およびサーバ側プロキシ（１５）とは、別にこのレスポンスを解析してファイル一覧を取得する。
ファイル一覧を取得したクライアント（１１）は、各ファイルに対して順にリクエストを送信する。クライアント（１１）から送信された最初のファイルに対するリクエスト（１０３）は、クライアント側プロキシ（１２）によって転送され（１１３）、サーバ側プロキシ（１５）によって転送されて（１２３）サーバ（１６）によって受信される。サーバ（１６）はリクエスト（１２３）に対するレスポンスとしてファイルを送信する（１２４）。
まず、サーバ側プロキシ（１５）の動作を説明する。レスポンス（１２４）を受信したサーバ側プロキシ（１５）はこれをクライアント側プロキシ（１２）へ転送する（１１４）。同時に、サーバ側プロキシ（１５）はファイル一覧中の次のファイルに対するリクエストを、クライアント（１１）に代わってサーバ（１６）に送信する（１２５）。サーバ（１６）はこれに対するレスポンスとしてファイルを送信する（１２６）。該当ファイル（ファイル一覧のうちいずれか一のファイル）を受信したサーバ側プロキシ（１５）は、このファイルをクライアント側プロキシ（１２）へ転送（１１５）するとともに、ファイル一覧に次のファイルがあればそれに対するリクエストを送信する（１２７）。サーバ側プロキシ（１５）が同リクエストに対するレスポンスを受信（１２８）するとこれをクライアント側プロキシ（１２）へ転送する（１１６）。サーバ側プロキシ（１５）は、ファイル一覧に次のファイルがないので、ファイル一覧を破棄して動作を完了する。
次に、クライアント側プロキシ（１２）の動作を説明する。クライアント側プロキシ（１２）はファイル１のレスポンスを受信（１１４）し、ファイル１を取得すると、ファイル１をクライアント（１１）へ転送する（１０４）。クライアント（１１）はファイル２に対するリクエストを送信する（１０５）。一方でファイル２のレスポンスはサーバ側プロキシ（１５）より送信されるされる（１１５）ので、クラアント側プロキシ（１２）は、ファイル２に対するリクエストとレスポンスがそろった段階で、クライアント（１１）に対してレスポンスを送信する（１０６）。同様の動作をファイル一覧中の全てのファイルに対して繰り返し（１０７，１１６，１０８）、ファイル一覧を破棄して動作を完了する。
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
以上により、「ＰＲＯＰＦＩＮＤ」に対するレスポンスに含まれる「２０７ Ｍｕｌｔｉ−Ｓｔａｔｕｓ」に該当するファイルの指定を受けたの契機にサーバ側プロキシ１５が、「２０７ Ｍｕｌｔｉ−Ｓｔａｔｕｓ」に対応する複数ファイルの読み出しを実行し、クライアント側プロキシ１２に「２００ ＯＫ」により、それぞれファイル１−３を送る例を示した。
図３はクライアント側プロキシ（１２）の内部構成を表す図である。サーバ側プロキシ（１２）は、クライアント１１とサーバ１６の間の通信を仲介し、パケットを送受信する通信装置であって、クライアント１１とＷＡＮの間にあるのが一例である。または、クライアント側の局所ネットワークのゲートウェイ装置であってもよい。クライアントは、例えば情報処理装置、無線情報処理端末である。局所ネットワークは、有線、無線少なくともいずれかで構成されてもよい。
LAN側コネクション管理部（３０１）はクライアント（１１）との通信を行う。クライアント（１１）からのリクエストはリクエスト判定部（３０２）にて、リクエストを送信したクライアント（１１）が識別される。また、そのリクエストがPROPFINDやGETなど、プリフェッチ動作の契機となるものかどうかが判定される。
プリフェッチ動作中でないとき、受信したリクエストはそのままリクエスト送信部（３０５）に送られ、サーバ側プロキシ（１５）へ送信される。プリフェッチ動作中はリクエストは一旦データ管理部（３０４）に登録される。
データ管理部（３０４）はIPアドレスで識別されるクライアント（１１）ごとにテーブルを持ち、リクエスト・レスポンスの状態とそのデータを管理する。例えばクライアントが３台あれば３つのテーブル（３１１〜３１３）を持つ。リクエストを受信すればそのパス名をキーとしてテーブルを検索して、リクエスト受信済みのフラグを立てる。またプリフェッチされたレスポンスを受信すればレスポンス受信済みのフラグを立てる。テーブルのエントリは定期的に調べられ、リクエスト受信済みかつレスポンス受信済みであれば、レスポンスをレスポンス送信部（３０３）を介して、クライアントへ送信する。リクエスト受信時にレスポンスが登録されていなければ、リクエストをリクエスト送信部（３０５）を介してサーバ側プロキシ（１５）へ送信してもよい。
リクエスト送信部（３０５）は、リクエスト判定部（３０２）またはデータ管理部（３０４）から受け取ったリクエストをWAN側コネクション管理部（３０７）を用いて送信する。
WAN側コネクション管理部（３０７）は、WANを通じてサーバ側プロキシ（１５）との通信の制御を行う。
レスポンス解析部（３０６）ではサーバ側プロキシ（１５）から受信したレスポンスのIPアドレスを解析して、どのクライアント（１１）に対するものであるか判断する。また、PROPFINDに対するレスポンスであればその内容も解析しファイル一覧を取得してデータ管理部（３０４）に登録する。同時にレスポンス送信部（３０３）に渡してクライアント（１１）へ転送する。GETに対するレスポンスであればデータ管理部（３０４）に登録する。
レスポンス送信部（３０３）ではレスポンス解析部（３０６）またはデータ管理部（３０４）から受信したレスポンスデータをLAN側コネクション管理部（３０１）に渡してクライアント（１１）へ転送する。
図４はサーバ側プロキシ（１５）の内部構成を表す図である。サーバ側プロキシ（１５）は、クライアントとサーバの間の通信を仲介し、パケットを送受信する通信装置であって、サーバとＷＡＮの間にあるのが一例である。または、サーバ側の局所ネットワークのゲートウェイ装置であってもよい。サーバは、例えば情報処理装置である。サーバ側の局所ネットワークは、有線、無線少なくともいずれかで構成されてもよい。WAN側コネクション管理部（４０１）はクライアント側プロキシ（１２）との通信を行う。
クライアント側プロキシからのリクエストはリクエスト判定部（４０２）にて、リクエストを送信したクライアント（１１）が識別される。また、そのリクエストがPROPFINDやGETなど、プリフェッチ動作の契機となるものかどうかが判定される。
プリフェッチ動作中でないとき、受信したリクエストはそのままリクエスト送信部（４０５）に送られ、サーバへ送信される。プリフェッチ動作中の場合、リクエストは、一旦データ管理部（４０４）に登録される。
データ管理部（４０４）は、クライアント側プロキシ（１２）と同様にクライアント（１１）ごとにデータ管理テーブルを持ち、リクエスト・レスポンスの状態とそのデータを管理する。例えばクライアント（１１）が３台あれば３つのテーブル（４１１〜４１３）を持つ。プリフェッチ動作中は、テーブルは定期的に調べられ、プリフェッチ未了のエントリがあればプリフェッチを行うため、リクエスト送信部（４０５）へURLを渡す。クライアント側プロキシ（１２）からリクエストを受信した場合、該当レスポンスを送信していなければ、そのリクエストを優先的にリクエスト送信部（４０５）へ渡し、サーバ（１６）へ送信する。
リクエスト送信部（４０５）は、リクエスト判定部（４０２）またはデータ管理部（４０４）から受け取ったリクエストをLAN側コネクション管理部（４０７）を用いて送信する。LAN側コネクション管理部（４０６）は、サーバ側プロキシ（１５）とサーバ（１６）との通信を制御する。
レスポンス解析部（４０６）ではサーバ（１５）から受信したPROPFINDに対するレスポンスを解析しファイル一覧を取得してデータ管理部（４０４）に登録する。同時にレスポンス送信部（４０３）を介してクライアント（１６）へ転送する。またレスポンスがGETに対するレスポンスであればデータ管理部（４０４）に登録する。
レスポンス送信部（４０３）は、レスポンス解析部（４０６）またはデータ管理部（４０４）から受信したレスポンスデータをWAN側コネクション管理部（４０１）を介してクライアント側プロキシ（１２）へ転送する。
図５は、(a)クライアント側プロキシおよび(b)サーバ側プロキシのデータ管理部における、データ管理テーブル（３１１，４１１）を示す。クライアント側プロキシのデータ管理テーブル（３１１）は対象となるファイルごとに、ファイルのURL（３５１）、プリフェッチしたレスポンス（３５２）、および1または0の値をとる3種類のフラグを持っている。フラグは「クライアントからリクエスト受信済み（３５３）」、「サーバ側プロキシからレスポンス受信済み（３５４）」、「クライアントにレスポンス送信済み（３５５）」である。
「クライアントからリクエスト受信済み（３５３）」フラグは、そのファイルに対するリクエストをクライアントから受信したとき1に設定される。フラグの値は、０，１以外であっても、クライアントからのリクエストが受信されたかか否かを、識別できる値を用いてもよい。
「サーバ側プロキシからレスポンス受信済み（３５４）」フラグはそのファイルをサーバ側プロキシから受信したとき1に設定される。フラグの値は、１以外であっても、サーバ側プロキシからレスポンスが受信されたかか否かを、識別できる値を用いてもよい。これらのフラグの両方が1となっていれば、レスポンスはクライアント側プロキシからクライアントへ送信され、「クライアントにレスポンス送信済み（３５５）」フラグが1に設定される。「クライアントにレスポンス送信済み（３５５）」フラグが1であれば該当エントリは削除される。
サーバ側プロキシのデータ管理テーブルは対象となるファイルごとに、ファイルのURL（４５１）、プリフェッチしたレスポンス（４５２）、および1または0の値をとる3種類のフラグを持っている。フラグは「サーバにプリフェッチリクエスト送信済み（４５３）」、「クライアント側プロキシからリクエスト受信済み（４５４）」、「サーバからレスポンス受信済み（４５６）」である。
「サーバにプリフェッチリクエスト送信済み（４５３）」フラグは、そのファイルに対するリクエストをサーバに送信したとき1に設定される。フラグの値は、０，１以外であっても、サーバにプリフェッチリクエストが送信されたかか否かを、識別できる値を用いてもよい。「クライアント側プロキシからリクエスト受信済み（４５４）」フラグはクライアント側プロキシからリクエストを受信したときに1に設定される。「サーバからレスポンス受信済み（４５５）」フラグはサーバからレスポンスを受信したときに1に設定される。このフラグが1のときにレスポンスはクライアント側プロキシに送信され、エントリが削除される。
図６はクライアント側プロキシ（１２）の動作を表すフローチャートである。初期状態ではLAN側でパケットを受信するまで待機する（５０１）。クライアント側プロキシ（１２）は、ＬＡＮ側でパケットを受信すると、送信元および宛先IPアドレスごとに分離する（５０２）。そのパケットがPROPFINDリクエストであれば（５０３）、クライアント側プロキシ（１２）は、サーバ側プロキシへ転送して（５０４）、GET待ち状態へ移行する。その他のリクエストであれば（５５１）、同様にサーバ側プロキシへ転送する（５５２）が、プリフェッチの準備は行わず、サーバ側プロキシ（１５）からレスポンスを受信するのを待って（５５３）それをクライアント（１１）へ転送し（５５４）、初期状態（５０１）へ戻る。
サーバ側プロキシへ転送したPROPFIND（５０４）のレスポンスが受信されるまで、クライアント側プロキシ（１２）は、当該ＰＲＯＰＦＩＮＤ（５０４）に関する処理を待機する（５０５）。ＰＲＯＰＦＩＮＤ（５０４）のレスポンスが受信されると、クライアント側プロキシ（１２）は、そのレスポンスをクライアント（１１）へ転送する（５０６）。また、クライアント側プロキシ（１２）は、このレスポンスを解析してファイル一覧を作成し、データ管理部（４０４）に登録する（５０７）。
続いて、クライアント側プロキシ（１２）は、クライアントからのGETリクエストを待ちうける（５０８）。GETを受信すると、クライアント側プロキシ（１２）は、これをサーバ側プロキシ（１５）へ転送し（５０９）、ＧＥＴリクエストに対するレスポンスを受信するまで待機する（５１０）。クライアント側プロキシ（１２）は、受信されればクライアント（１１）へ転送（５１１）し、サーバ側プロキシ（１５）からのプリフェッチデータを待ちうける（５１２）。GET以外のリクエストを受信した場合（５５５）は、同様にサーバ側プロキシ（１５）へ転送する（５５６）が、WAN側からレスポンスを受信するのを待って（５５７）それをクライアント（１１）へ転送し（５５８）、初期状態（５０１）へ戻る。
サーバ側プロキシ（１５）からのプリフェッチデータを受信すると（５１２）、クライアント側プロキシ（１２）は、これをデータ管理部（３０４）に保存して（５１３）、クライアントからのリクエストを待ちうける（５１４）。リクエストを受信すると、リクエストに該当するファイルをデータ管理部（３０４）に保存されているプリフェッチデータから読み出し、保存していたプリフェッチデータをレスポンスとしてクライアントに送信する（５１５）。
ファイル一覧にファイルが残っていれば、５１２以降を繰り返す（５１６）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（５０１）に戻る（５１７）。
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
図７は、サーバ側プロキシ（１５）の動作を表すフローチャートである。初期状態ではWAN側でパケットを受信するまで待機する（６０１）。サーバ側プロキシ（１５）は、受信すると送信元および宛先IPアドレスごとに分離する（６０２）。そのパケットがPROPFINDリクエストであれば（６０３）、サーバ側プロキシ（１５）は、サーバ（１６）へ転送して（６０４）GET待ち状態へ移行する。その他のリクエストであれば（６５１）、サーバ側プロキシ（１５）は、サーバ（１６）へ転送する（６５２）が、プリフェッチの準備は行わず、サーバ側プロキシ（１５）は、サーバ（１６）からレスポンスを受信するのを待って（６５３）それをクライアント（１１）側へ転送し（６５４）、初期状態（６０１）へ戻る。
一方、サーバ側プロキシ（１５）は、ステップ６０３の後、サーバ（１６）へ転送したPROPFIND（６０４）のレスポンスが受信されるまで待機し（６０５）受信されるとクライアント側プロキシ（１５）へ転送する（６０６）。また、サーバ側プロキシ（１５）は、ＰＲＯＰＦＩＮＤ（６０４）に対するレスポンスを解析してファイル一覧を作成し、データ管理部（４０４）に登録する（６０７）。
続いてクライアント側プロキシ（１２）からのGETリクエストを待ちうける（６０８）。GETを受信すると、サーバ側プロキシ（１５）は、これをサーバ（１６）へ転送し（６０９）、それに対するレスポンスを受信するまで待機する（６１０）。受信されればクライアント側プロキシ（１２）へ転送し（６１１）、データ管理部（４０４）に登録されているファイル一覧に従って、次のファイルに対するプリフェッチリクエストを送信する（６１２）。GET以外のリクエストを受信した場合（６５５）は、サーバ側プロキシ（１５）は、にサーバへ転送する（６５６）が、サーバ（１６）からレスポンスを受信するのを待って（６５７）それをクライアント側プロキシ（１２）へ転送し（６５８）、初期状態（６０１）へ戻る。
一方、ステップ６１２に対してサーバ（１６）からのプリフェッチデータを受信すると（６１３）、サーバ側プロキシ（１５）は、クライアント側プロキシに送信する（６１４）。
ファイル一覧に従って、サーバ側プロキシ（１５）は、サーバから受信されていないファイルが残っていれば、６１２以降を繰り返す（６１５）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（６０１）に戻る（６１６）。
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
本発明の第二の実施例における通信シーケンスを図８に示す。図８では通信にかかわる、クライアント（１１）、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）、およびサーバ（１６）のシーケンスを示している。本実施例の方式により、実施例１の場合と比べて同等の通信効率を保ちながら、WAN上の通信をWebDAVの標準プロトコルにのっとったものとする。それによりWAN上の通信がファイアウォール、Intrusion Detection System/Intrusion Protection System、Deep Packet Inspectionなどのセキュリティシステムにより、異常な通信であると判断されて遮断されることを防ぐことができる。
手順７０１、７０２、７１１、７１２、７２１、７２２は、図１の手順１０１、１０２、１１１、１１２、１２１、１２２と同様にＰＲＯＰＦＩＮＤのリクエストとそのレスポンスと同様である。
ファイル一覧を取得したクライアント（１１）は、各ファイルに対して順にリクエストを送信する。クライアント（１１）から送信された最初のファイルに対するリクエスト（７０３）は、クライアント側プロキシ（１２）によって受信される。クライアント側プロキシ（１２）は、このリクエストを解析して、ＰＲＯＰＦＩＮＤリクエストに対するレスポンスであるファイル一覧中に含まれるファイル（ファイル１）であると判断すると、このリクエストをサーバ側プロキシ（１５）へ転送する（７１３）。さらに、クライアント側プロキシ（１２）は、クライアントからのリクエスト（７０７）で指定されるファイル（ファイル１）ではないが、ファイル一覧にある他のファイル（ファイル２、３）に対するリクエスト（７１４、７１５）も発行する。これらのリクエストは前のリクエストに対するレスポンスを待つことなくサーバ側プロキシ（１５）へ送信される（７１４，７１５）。
サーバ側プロキシ（１５）は、クライアント側プロキシ（１２）からのリクエストを受信（７１３）すると、ファイル一覧中のファイルで、クライアントからの最初のリクエストで指定されたファイル（ファイル１）に対するリクエストを、クライアント（１１）に代わってサーバ（１６）に送信する（７２３）。サーバ（１６）は、これに対するレスポンスとしてファイル１を送信する（７２４）。これを受信したサーバ側プロキシ（１５）は、このファイルをクライアント側プロキシ（１２）へ転送（７１６）する。
また、サーバ側プロキシ（１５）は、サーバ（１６）からのファイル１の受信に応じて、受信したファイル１が含まれるファイル一覧に次のファイル（ファイル２）があればそれに対するリクエストを送信する（７２５）。サーバ側プロキシ（１５）が同リクエストに対するレスポンスを受信（７２６）すると、これをクライアント側プロキシ（１２）へ転送する（７１７）。さらに、次のファイルも、ステップ７２５、７２６、７１７と同様にプリフェッチを行うと（７２７，７２８，７１８）、サーバ側プロキシ（１５）は、ファイル一覧に次のファイルがない場合、ファイル一覧を破棄して動作を完了する。このリクエストは前のリクエストに対するレスポンスを受信してから開始してもよいし、複数のリクエストを同時に送信してもよい。
クライアント側プロキシ（１２）は、ファイル１のレスポンスを受信（７１６）すると、これをクライアント（１１）へ転送する（７０４）。クライアント（１１）はファイル２に対するリクエストを送信する（７０５）。一方でファイル２のレスポンスは、サーバ側プロキシ（１５）より受信される（７１７）ので、ファイル２に対するリクエストとレスポンスがそろった段階で、クライアント（１１）に対してレスポンスを送信する（７０６）。同様の動作をファイル一覧中の全てのファイルに対して繰り返し（７１８，７０７，７０８）、ファイル一覧を破棄して動作を完了する。
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
図９は第二の実施例におけるクライアント側プロキシ（１２）の動作を表すフローチャートである。ステップ８０１ないし８０７、８５１ないし８５４は、図６のステップ５０１ないし５０７、５５１ないし５５４と同様である。
続いてクライアントからのGETリクエストを待ちうける（８０８）。クライアント側プロキシ（１２）は、GETリクエストを受信するとこれを契機にファイル一覧中のファイルに対してプリフェッチリクエストを発行する（８０９）。このリクエストは前のリクエストに対するレスポンスを待たずに送信される。ファイル一覧中の全てのファイルに対してリクエストを送信するまでこれを繰り返す（８１０）。GET以外のリクエストを受信した場合（８５５）は、同様にサーバ側プロキシ（１５）へ転送する（８５６）が、WAN側からレスポンスを受信するのを待って（８５７）それをクライアント（１１）へ転送し（８５８）、初期状態（８０１）へ戻る。
サーバ側プロキシ（１５）から最初のリクエストに対するレスポンスを受信すると（８１１）、クライアント側プロキシ（１２）は、これをクライアントへ転送する（８１２）。クライアント側プロキシ（１２）は、サーバ側プロキシ（１５）からのプリフェッチデータを受信すると（８１３）、これをデータ管理部（３０４）に保存して（８１４）、クライアントからのリクエストを待ちうける（８１５）。リクエストを受信すると、クライアント側プロキシ（１２）は、保存していたデータをレスポンスとしてクライアントに送信する（８１６）。
ファイル一覧にファイルが残っていれば、８１２以降を繰り返す（８１７）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（８０１）に戻る（８１８）。上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
図１０は第二の実施例におけるサーバ側プロキシ（１５）の動作を表すフローチャートである。ステップ９０１ないし９０７、９５１ないし９５４は、図７のステップ６０１ないし６０７、６５１ないし６５４と同様である。 続いてクライアント側プロキシ（１２）からのプリフェッチリクエストを待ちうける（９０８）。プリフェッチリクエストは、ファイル一覧に含まれるファイルの数に対応して複数送られるため、サーバ側プロキシ（１５）は、ファイル一覧に含まれるファイルの数に対応する全てのリクエストを受信するまでこれを繰り返す（９０９）。続いて、プリフェッチリクエストを順次サーバ（１６）へ転送し（９１０）、それに対するレスポンスを受信するまで待機する（９１１）。サーバ側プロキシ（１５）は、レスポンスが受信されればクライアント側プロキシ（１２）へ、それらを転送する（９１２）。GET以外のリクエストを受信した場合（９５５）は、サーバ側プロキシ（１５）は、同様にサーバ（１６）へ転送する（９５６）が、サーバ側プロキシ（１５）は、サーバ（１６）からGET以外のリクエストに対応するレスポンスを受信するのを待って（９５７）それをクライアント側プロキシ（１２）へ転送し（９５８）、初期状態（９０１）へ戻る。
ファイル一覧にサーバから取得していないファイルが残っていれば、９１０以降を繰り返す（９１３）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（９０１）に戻る（９１４）。上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
装置内の構成については実施例１の場合と同様であるので、ここでは省略する。
以上の実施例２の説明により、ＷｅｂＤＡＶに従った通信により得られた情報を用いて、プリフェッチするリクエストとレスポンスとを対応づけ、プロキシ間での通信制御を行うことを説明した。その制御により、WAN上の通信がファイアウォール、Intrusion Detection System/Intrusion Protection System、Deep Packet Inspectionなどのセキュリティシステムにより、プリフェッチするための通信が、異常な通信であると判断されて遮断されることを防ぐことができる。
本発明の第三の実施例における通信シーケンスを図１１に示す。この例では実施例２の方式をHTTPに適用している。本実施例の方式により、実施例２の場合と同様に、WAN上の通信はHTTPの標準にのっとったものとなるため、セキュリティシステムにより異常な通信として判断され遮断されることを防ぐことができる。
クライアントが、サーバからウェブページを読み込む場合、まずHTMLファイルに対してGETというリクエスト（１００１）を発行する。これはクライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWAN上を転送される（１０１１）。サーバ側プロキシ（１５）はこれを受信すると、サーバ（１６）へさらに転送する（１０２１）。HTMLに対するGETを受信したサーバ（１６）は、そのHTMLファイルをクライアントへ返送する（１０２２）。このレスポンス（１０２２）は、ＨＴＴＰに従った「２００ ＯＫ」というレスポンスであり、フォルダ内のファイル一覧が含まれる。同レスポンスはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１０１２）、サーバ側プロキシ（１５）は、このレスポンスを解析することによりフォルダ内のファイル一覧を取得する。さらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１００２）。クライアント側プロキシ（１２）でも同様にこのレスポンスを解析し、ファイル一覧を取得する。クライアント（１１）はクライアント側プロキシ（１２）およびサーバ側プロキシ（１５）とは、独立してこのレスポンスを解析してファイル一覧を取得する。
ファイル一覧を取得したクライアント（１１）は、各ファイルに対して順にリクエストを送信する。クライアント（１１）から送信された最初のファイルに対するリクエスト（１００３）は、クライアント側プロキシ（１２）によって受信される。
クライアント側プロキシ（１２）は、このリクエストを解析して、ファイル一覧中に含まれるファイルであると判断すると、このリクエストをサーバ側プロキシ（１５）へ転送する（１０１３）。クライアント１１からのリクエストで指定されるファイルが「２００ ＯＫ」のレスポンス（１０１２）で取得したファイル一覧中に含まれるファイル（file 1）であると、クライアント側プロキシ（１２）が判断すると、そのファイル一覧の他のファイル(file2, 3)に対するリクエストも発行する。これらのリクエストは前のリクエストに対するレスポンスを待つことなくサーバ側プロキシ（１５）へ送信される（１０１４，１０１５）。つまり、クライアントからファイル一覧に含まれる一のファイルを指定するリクエストがくると、クライアント側プロキシ（１２）は、ファイル一覧に含まれる他のファイルについてのリクエストも、クライアント（１１）からのリクエストを待つことなく、サーバ側プロキシ（１５）にプリフェッチリクエスト（１０１４、１０１５）を発行する。
サーバ側プロキシ（１５）は、クライアント側プロキシ（１２）からのリクエストを受信（１０１３）すると、ファイル一覧中のファイルに対するリクエストを、クライアント（１１）に代わってサーバ（１６）に送信する（１０２３）。サーバ（１６）はこれに対するレスポンスとしてファイルを送信する（１０２４）。
これを受信したサーバ側プロキシ（１５）は、このファイルをクライアント側プロキシ（１２）へ転送（１０１６）するとともに、レスポンス（１０２２）で取得したファイル一覧に他のファイルがあればそれに対するリクエストをサーバ（１６）に送信する（１０２５）。
サーバ側プロキシ（１５）は、同リクエストに対するレスポンスを受信（１０２６）すると、これをクライアント側プロキシ（１２）へ転送する（１０１７）。他のファイルも同様にプリフェッチを行う（１０２７，１０２８，１０１８）。なお、サーバ側プロキシ（１５）は。クライアント側プロキシ（１２）から送信されるプリフェッチリクエストに対応するファイルのリクエストをサーバ（１６）送信してもよい。サーバ側プロキシ（１５）は、ファイル一覧に次のファイルがないので、ファイル一覧を破棄して動作を完了する。このリクエストは前のリクエストに対するレスポンスを受信してから開始される。
クライアント側プロキシ（１２）は、ファイル１のレスポンスを受信（１０１６）すると、これをクライアント（１１）へ転送する（１００４）。クライアント（１１）は、ファイル一覧に含まれるファイル２に対するリクエストを送信する（１００５）。一方でファイル２のレスポンスはサーバ側プロキシ（１５）から送信される（１０１７）ので、クライアント側プロキシ（１２）は、ファイル２に対するリクエストを保持し、レスポンスを受領した場合に、クライアント（１１）に対して、保持しているファイル２に対するリクエストに対応するレスポンスを送信する（１００６）。同様の動作をファイル一覧に含まれるファイルに対して繰り返し（１０１８，１００７，１００８）、ファイル一覧をバッファから破棄して動作を完了する。
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
図１２は、実施例３におけるクライアント側プロキシ（１２）の動作を表すフローチャートである。初期状態ではLAN側でパケットを受信するまで待機する（１１０１）。受信すると送信元および宛先IPアドレスごとに分離する（１１０２）。そのパケットがHTMLに対するGETリクエストであれば（１１０３）サーバ側プロキシへ転送して（１１０４）GET待ち状態へ移行する。その他のリクエストであれば（１１５１）、同様にサーバ側プロキシ（１５）へ転送する（１１５２）が、プリフェッチの準備は行わず、サーバ側プロキシ（１５）からレスポンスを受信するのを待って（１１５３）それをクライアント（１１）へ転送し（１１５４）、初期状態（１１０１）へ戻る。
サーバ側プロキシへ転送したHTMLに対するGET（１１０４）のレスポンスが受信されるまで待機し（１１０５）受信されるとクライアント（１１）へ転送する（１１０６）。同時にこのレスポンスを解析してファイル一覧を作成し、データ管理部（３０４）に登録する（１１０７）。
続いてクライアントからのGETリクエストを待ちうける（１１０８）。ファイル一覧に含まれるファイルに対するGETリクエストを受信すると、クライアント側プロキシは、これを契機にファイル一覧中のファイルに対してプリフェッチリクエストを発行する（１１０９）。これらのリクエストは前のリクエストに対するレスポンスを待たずに送信される。また、クライアントからのＧＥＴリクエストで指定されるファイルだけでなく、ＧＥＴリクエストで特定されるファイル一覧に含まれるファイルに対してリクエストを送信するまでこれを繰り返す（１１１０）。GET以外のリクエストを受信した場合（１１５５）は、同様にサーバ側プロキシ（１５）へ転送する（１１５６）が、WAN側からレスポンスを受信するのを待って（１１５７）それをクライアント（１１）へ転送し（１１５８）、初期状態（１１０１）へ戻る。
サーバ側プロキシ（１５）から最初のリクエストに対するレスポンスを受信すると（１１１１）、クライアント側プロキシ（１２）は、これをクライアントへ転送する（１１１２）。サーバ側プロキシ（１５）からのプリフェッチデータを受信すると（１１１３）、クライアント側プロキシ（１２）は、これをデータ管理部（３０４）に保存して（１１１４）、クライアントからのリクエストを待ちうける（１１１５）。クライアントからのリクエストを受信すると、クライアント側プロキシ（１２）は、当該リクエストで指定されるファイルに対応する、ファイルを保存していたデータから読み出し、そのデータをレスポンスとしてクライアントに送信する（１１１６）。
クライアント側プロキシ（１２）は、ファイル一覧にファイルが残っていれば、１１１２以降を繰り返す（１１１７）。クライアント側プロキシ（１２）は、すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（１１０１）に戻る（１１１８）。
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
図１３は、実施例３におけるサーバ側プロキシ（１５）の動作を表すフローチャートである。初期状態ではWAN側でパケットを受信するまで待機する（１２０１）。受信すると送信元および宛先IPアドレスごとに分離する（１２０２）。そのパケットがHTMLに対するGETリクエストであれば（１２０３）サーバ（１６）へ転送して（１２０４）GET待ち状態へ移行する。その他のリクエストであれば（１２５１）、同様にサーバ（１６）へ転送する（１２５２）が、プリフェッチの準備は行わず、サーバ（１６）からレスポンスを受信するのを待って（１２５３）それをクライアント（１１）へ転送し（１２５４）、初期状態（１２０１）へ戻る。
サーバ（１６）へ転送したHTMLに対するGET（１２０４）のレスポンスが受信されるまで待機し（１２０５）受信されるとクライアント側プロキシ（１５）へ転送する（１２０６）。同時にこのレスポンスを解析してファイル一覧を作成する（１２０７）。
続いてクライアント側プロキシ（１２）からのプリフェッチリクエストを待ちうける（１２０８）。図１１の１０１４及び１０１５がプリフェッチリクエストである。リクエストは連続して複数送られるため、全てのリクエストを受信するまでこれを繰り返す（１２０９）。続いてこれを順次サーバ（１６）へ転送し（１２１０）、それに対するレスポンスを受信するまで待機する（１２１１）。少なくとも一のレスポンスが受信されれば、サーバ側プロキシ（１５）は、そのレスポンスをクライアント側プロキシ（１２）へ転送する（１２１２）。なお、図１１の１０２３ないし１０２８のように、サーバ側プロキシは、一のファイルのリクエストに対するサーバからのレスポンス受領後に、別のファイルのリクエストを送信していてもよい。
GET以外のリクエストを受信した場合（１２５５）は、同様にサーバへ転送する（１２５６）が、サーバ（１６）からレスポンスを受信するのを待って（１２５７）それをクライアント側プロキシ（１２）へ転送し（１２５８）、初期状態（１２０１）へ戻る。
ファイル一覧にファイルが残っていれば、１２１０以降を繰り返す（１２１３）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（１２０１）に戻る（１２１４）。 上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
装置内の構成については実施例１の場合と同様であるので、ここでは省略する。
本発明の第四の実施例を図１４に示す。この例では実施例１の複数のクライアントが、同一のフォルダをダウンロードした際に、プロキシにて読み込み済みのデータをバッファに保持し、一のクライアントからのアクセスで削除するのではなく、複数のクライアントからのアクセスのためにバッファに保持し、複数のクライアントにファイルを転送することにより、データ転送量の削減を図っている。
この例では実施例１の場合にクライアントＢ（１１ｂ）が追加されており、クライアントＡ（１１ａ）と同一のフォルダに対しダウンロードを試みている。クライアントＡ（１１ａ）のシーケンスは実施例１と同様であるので、詳細は省略する。
クライアント側プロキシ（１２）では、フォルダカウント（１４１０）という値を用いてフォルダごとの同時アクセスしているクライアント数を管理する。クライアントＡ（１１ａ）からのPROPFIND（２０１）を受信すると、クライアント側プロキシ（１２）は、フォルダカウント（１４１０）を1に更新する。この値が1である間にクライアントＢ（１１ｂ）からPROPFIND（１４０１）が送信され、これを受信したクライアント側プロキシ（１２）は、フォルダカウントを2に更新する（１４１１）。クライアント側プロキシ（１２）は、PROPFINDに対するレスポンスを保持し、これをクライアントＢ（１１ｂ）に送信する（１４０２）。これを受けて、クライアント（１１）がフォルダ内のファイルに対してGETを発行する（１４０３）。これに対するレスポンスもクライアント側プロキシ（１２）が保持しているため、クライアント側プロキシ（１２）はそれをそのまま送信する。（１４０４）。
一方でクライアントA（１１ａ）への転送はファイル3にて終了し（２０８）、クライアント側プロキシ（１２）のフォルダカウントは1となる（１４１２）。
クライアントB（１１ｂ）への転送はファイル2（１４０５、１４０６）、ファイル3（１４０７、１４０８）と続き、終了する。このときクライアント側プロキシ（１２）のフォルダカウントが1であるので、このカウンタおよびフォルダ内のファイルを削除して終了する。
図１５はクライアント側プロキシ（１２）の内部構成を表す図である。本実施例では、実施例１の構成に共有データプール（１５０１）とフォルダテーブル（１５０２）を追加したものとなっている。レスポンスデータはクライアントごとのデータ管理テーブルではなく、クライアント（１１ａ、１１ｂ）間で共有される共有データプール（１５０１）に格納される。また、フォルダテーブル（１５０２）はフォルダごとにそのフォルダにアクセスしているクライアント数を示すテーブルである。他は図３と同様である。
図１６はサーバ側プロキシ（１５）の内部構成を表す図である。本実施例では、実施例１の構成に共有データプール（１６０１）とフォルダテーブル（１６０２）を追加したものとなっている。これらはクライアント側プロキシのものと同様の機能を持つ。他は図４と同様である。
図１７(a)はクライアント側プロキシ（１２）のデータ管理部（３０４）における、データ管理テーブル（３１１〜３１３）を示す。また図１７(b)はサーバ側プロキシのデータ管理部（４０４）における、データ管理テーブル（４１１〜４１３）を示す。実施例１との違いは、これらのテーブルではレスポンスを管理しないため、レスポンス内容（３５２、４５２）の項目がない点である。
図１７(c)は共有データプール（１５０１、１６０１）のデータテーブルを示す。これは、URL（１５５１）、レスポンス内容（１５５２）、ファイルが属するフォルダの情報（１５５３）を持つ。フォルダの情報は単なるフォルダ名でも、後述するフォルダテーブルのエントリへのポインタでよい。このデータはすべてのクライアント（１１ａ、１１ｂ）で共有され、他のクライアントのリクエストによりプリフェッチされたデータであっても、データがこの中にあればこのデータをレスポンスとして送信する。
図１７(d)はフォルダテーブル（１５０２）を示す。これは、フォルダ名（１５５４）とカウンタ（１５５５）を持ち、カウンタ（１５５５）はフォルダごとにそのフォルダにアクセスしているクライアントの数を示しており、1以上の値をとる。フォルダ内全ファイルの転送が完了すると、プロキシはフォルダテーブル（１５０２）をチェックし、カウンタ（１５５５）の値が2以上であれば、他にアクセスしているクライアントがいるため同フォルダ内のファイルを削除しない。一方カウンタ（１５５５）の値が1であった場合は、他にアクセスしているクライアントがいないのでファイルを削除する。
図１８はクライアント側プロキシ（１２）の動作を表すフローチャートである。初期状態ではLAN側でパケットを受信するまで待機する（１８０１）。受信すると送信元および宛先IPアドレスごとに分離する（１８０２）。そのパケットがPROPFINDリクエストであれば（１８０３）フォルダテーブルをカウントアップする（１８０４）。その他のリクエストであれば（１８５１）、同様にサーバ側プロキシ（１５）へ転送する（１８５２）が、サーバ側プロキシ（１５）からレスポンスを受信するのを待って（１８５３）それをクライアント（１１）へ転送し（１８５４）、初期状態（１８０１）へ戻る。
フォルダカウントが2以上であれば（１８０５）、他のクライアントが読み込んだデータが存在するため、そのデータ（PROPFINDに対するレスポンス）をレスポンスとしてクライアント（１１）へ送信する（１８０６）。フォルダカウントが1であれば、PROPFINDリクエストをサーバ側プロキシ（１５）へ転送して（１８０７）GET待ち状態へ移行する。サーバ側プロキシ（１５）へ転送したPROPFINDのレスポンスが受信されるまで待機し（１８０８）受信されるとクライアント（１１）へ転送する（１８０９）。同時にこのレスポンスを解析してファイル一覧を作成する（１８１０）。
続いてクライアントからのGETリクエストを待ちうける（１８１１）。GET以外のリクエストを受信した場合（１８５５）は、同様にサーバ側プロキシ（１５）へ転送する（５５６）が、WAN側からレスポンスを受信するのを待って（５５７）それをクライアント（１１）へ転送し（５５８）、初期状態（５０１）へ戻る。
GETを受信した場合、フォルダカウントを参照し（１８１２）、2以上であれば他のクライアントが読み込んだデータが存在するため、そのデータをレスポンスとしてクライアントへ送信する（１８１３）。フォルダ内の全ファイルを転送完了するかタイムアウトするまでこれを繰り返し（１８１４）、終了したらフォルダカウントをカウントダウンする（１８１５）。
フォルダカウントが1であった場合、リクエストをサーバ側プロキシ（１５）へ転送し（１８１６）、それに対するレスポンスを受信するまで待機して（１８１７）、受信されればクライアント（１１）へ転送し（１８１７）、サーバ側プロキシ（１５）からのプリフェッチデータを待ちうける（１８１８）。 サーバ側プロキシ（１５）からのプリフェッチデータを受信すると（１８１８）、これをデータ管理部（３０４）に保存して（１８２０）、クライアントからのリクエストを待ちうける（１８２１）。リクエストを受信すると保存していたデータをレスポンスとしてクライアントに送信する（１８２２）。
ファイル一覧にファイルが残っていれば、５１２以降を繰り返す（１８２３）。すべてのデータを転送し終わるか、タイムアウトによりフォルダカウントをカウントダウンし、初期状態（１８０１）に戻る（１８２４）。
図１９はサーバ側プロキシ（１５）の動作を表すフローチャートである。初期状態ではWAN側でパケットを受信するまで待機する（１９０１）。受信すると送信元および宛先IPアドレスごとに分離する（１９０２）。そのパケットがPROPFINDリクエストであれば（１９０３）フォルダテーブルをカウントアップする（１９０４）。その他のリクエストであれば（１９５１）、同様にサーバ（１６）へ転送する（１９５２）が、サーバ（１６）からレスポンスを受信するのを待って（１９５３）それをクライアント側プロキシ（１２）へ転送し（１９５４）、初期状態（１９０１）へ戻る。
フォルダカウントが2以上であれば（１９０５）、他のクライアントが読み込んだデータが存在するため、そのデータ（PROPFINDに対するレスポンス）をレスポンスとしてクライアント側プロキシ（１２）へ送信する（１９０６）。フォルダカウントが1であれば、PROPFINDリクエストをサーバ（１６）へ転送して（１９０７）GET待ち状態へ移行する。サーバ（１６）へ転送したPROPFINDのレスポンスが受信されるまで待機し（１９０８）受信されるとクライアント側プロキシ（１２）へ転送する（１９０９）。同時にこのレスポンスを解析してファイル一覧を作成する（１９１０）。
続いてクライアント側プロキシ（１２）からのGETリクエストを待ちうける（１９１１）。GET以外のリクエストを受信した場合（１９５５）は、同様にサーバへ転送する（１９５６）が、サーバ（１６）からレスポンスを受信するのを待って（１９５７）それをクライアント側プロキシ（１２）へ転送し（１９５８）、初期状態（１９０１）へ戻る。
GETを受信した場合、フォルダカウントを参照し（１９１２）、2以上であれば他のクライアントが読み込んだデータが存在するため、そのデータをレスポンスとしてクライアント側プロキシ（１２）へ送信する（１９１３）。フォルダ内の全ファイルを転送完了するかタイムアウトするまでこれを繰り返し（１９１４）、終了したらフォルダカウントをカウントダウンする（１９１５）。
フォルダカウントが1であった場合、リクエストをサーバ（１６）へ転送し（１９１６）、それに対するレスポンスを受信するまで待機する（１９１７）。受信されればクライアント側プロキシ（１２）へ転送し（１９１８）、次のファイルに対するプリフェッチリクエストを送信する（１９１９）。 サーバ（１６）からのプリフェッチデータを受信すると（１９２０）、クライアント側プロキシに送信する（１９２１）。ファイル一覧にファイルが残っていれば、１９１９以降を繰り返す（１９２２）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（１９０１）に戻る（１９２３）。
上述の実施例により、ＨＴＴＰやＷｅｂＤＡＶに従う通信で、サーバからクライアントの利用状況に応じて複数ファイルを効率的に転送するとができる。

Claims (13)

  1. クライアントとサーバの間で前記クライアントからのリクエストに対して前記サーバがレスポンスを送信する形式の通信方法において、
    前記クライアントと前記サーバとに接続され、前記クライアントおよび前記サーバの間の通信を中継するプロキシシステムが、
    前記サーバから取得したファイル一覧を含むレスポンスを、前記クライアントに送信し、
    前記クライアントからの、前記ファイル一覧に含まれる第一のファイルを指定する第一のリクエストの受信を契機として、
    前記クライアントから、前記ファイル一覧に含まれる前記第一のファイル以外の第二のファイルを指定する第二のリクエストを受信しなくても、前記ファイル一覧に含まれる、前記第二のファイルをプリフェッチするための第三のリクエストを前記サーバへ送信し、
    前記サーバから、前記第三のリクエストに対するレスポンスである前記第二のファイルをプリフェッチする
    ことを特徴とする通信方法。
  2. 請求項１の通信方法であって、
    前記プロキシシステムは、サーバ側プロキシとクライアント側プロキシとを含み、
    前記プリフェッチは、前記サーバ側プロキシで行い、
    前記サーバ側プロキシは、
    一つ以上のファイル取得を要求する第三のリクエストを前記サーバへ送信し、
    前記第三のリクエストに対するレスポンスとしてプリフェッチした一つ以上の前記第二のファイルを前記クライアント側プロキシに送信し、
    前記クライアント側プロキシは、
    前記サーバ側プロキシから前記一つ以上の第二のファイルを受信して保存し、
    受信した前記第二のファイルの一つを取得するための前記第二のリクエストを前記クライアントから受信した場合に、保存している該当する前記第二のファイルの一つを前記クライアントに送信する
    ことを特徴とする通信方法。
  3. 請求項２の通信方法であって、
    前記クライアント側プロキシは、
    前記クライアントから前記第一のリクエストを受信した後に、前記クライアントから、前記第二のリクエストを受信した場合、
    前記第二のリクエストに対するレスポンスとなるべき前記第二のファイルを前記サーバ側プロキシから受信していない場合に、前記第二リクエストを前記サーバ側プロキシに転送する
    ことを特徴とする通信方法。
  4. 請求項３の通信方法であって、
    前記サーバ側プロキシは、
    前記クライアント側プロキシから前記第二のファイルを指定する前記第二のリクエストを受信した場合に、
    当該サーバ側プロキシが、前記第二のファイルを指定する前記第三のリクエストを未送信の場合に、前記第二のリクエストを前記第三のリクエストとして他のリクエストより優先的に前記サーバに送信する
    ことを特徴とする通信方法。
  5. 請求項１の通信方法であって、
    前記プロキシシステムは、サーバ側プロキシとクライアント側プロキシとを含み、
    前記クライアント側プロキシは、
    一つ以上のファイル取得を要求する第三のリクエストを前記サーバ側プロキシへ送信し、
    前記サーバ側プロキシは、
    前記第三のリクエストを前記サーバに転送し、
    前記サーバから前記第三のリクエストに対するレスポンスとして一つ以上の前記第二のファイルを受信し、
    前記一つ以上の第二のファイルを前記クライアント側プロキシへ転送し、
    前記クライアント側プロキシは、
    前記サーバ側プロキシから前記一つ以上の第二のファイルを受信して保存し、
    受信した前記第二のファイルの一つを取得するための前記第二のリクエストを前記クライアントから受信した場合に、保存している該当する前記第二のファイルの一つを前記クライアントに送信する
    ことを特徴とする通信方法。
  6. 請求項５の通信方法であって、
    前記クライアント側プロキシは、前記第三のリクエストにより複数のファイル取得を要求する場合、
    前記第三のリクエストにより複数のファイル取得を要求する場合、
    前記第三のリクエストとして、一つのファイル取得を要求するリクエストを送信し、
    当該リクエストに対するレスポンスである一つの前記第二のファイルを受信する前に、次のファイル取得を要求する次のリクエストを、前記第三のリクエストとして送信する
    ことを特徴とする通信方法。
  7. 請求項２の通信方法であって、
    前記クライアント側プロキシは、
    複数の前記クライアントに接続され、
    前記ファイル一覧に含まれ、プリフェッチされた前記第二のファイルを保存し、
    第一の前記クライアントがリクエストしたファイルと同一のファイルに対するリクエストを、第二の前記クライアントから受信した場合に、
    前記第二のクライアントに対して、保存した前記ファイルを送信する
    ことを特徴とする通信方法。
  8. 請求項２の通信方法であって、
    前記クライアント側プロキシは、複数の前記クライアントに接続され、
    前記サーバ側プロキシは、
    前記ファイル一覧に含まれプリフェッチされた前記第二のファイルを保存し、
    第一の前記クライアントがリクエストしたファイルと同一のファイルに対する、第二の前記クライアントからのリクエストを受信した場合に、
    前記第二のクライアントに対するレスポンスとして、保存した前記ファイルを送信する
    ことを特徴とする通信方法。
  9. 請求項２記載の通信方法であって、
    前記クライアント側プロキシ及び前記サーバ側プロキシは、ＷｅｂＤＡＶに従う通信であって、
    前記第一のリクエストは、ＰＲＯＰＦＩＮＤであり、
    前記ファイル一覧は、前記ファイルの実体の場所を示すＵＲＬであって、「２０７ ＭｕｔｌｉＳｔａｔｕｓ」というレスポンスに含まれ、
    前記第２のリクエストは、当該ファイルの実体の取得を要求するためのＧＥＴリクエストである
    ことを特徴とする通信方法。
  10. 請求項２記載の通信方法であって、
    前記クライアント側プロキシ及び前記サーバ側プロキシは、ＨＴＴＰプロトコルに従う通信であって、
    前記第一のリクエストがＨＴＭＬファイルに対するＧＥＴリクエストであり、
    前記前記ファイル一覧は、「２００ ＯＫ」というレスポンスに含まれ、
    前記第２のリクエストは、当該ファイルの実体の取得を要求するためのＧＥＴリクエストである
    ことを特徴とする通信方法。
  11. クライアントとサーバ間で、前記サーバに格納される情報の通信制御を行うプロキシシステムであって、
    前記クライアントと通信するクライアント通信部と、
    前記サーバと通信するサーバ通信部と、
    通信制御部と、を有し、
    前記通信制御部は、
    前記クライアントからの、第一のリクエストに対して前記サーバから取得したレスポンスが示す、前記サーバに格納されている複数の情報のうち、一つの第一の前記情報の取得要求を前記クライアントから受信したことを契機として、前記レスポンスが示す、前記第一の情報を含む複数の前記情報の取得要求を、前記サーバに送信し、
    前記複数の情報取得要求に対するレスポンスである前記複数の情報を前記サーバから受信した場合、前記クライアントに当該複数の情報を送信する
    ことを特徴とするプロキシシステム。
  12. 請求項１１記載のプロキシシステムであって、
    前記通信制御部は、
    バッファを備え、
    ＷｅｂＤＡＶプロトコルに従う、前記クライアントからの送信される前記第一のリクエストであるＰＲＯＰＦＩＮＤに対する前記サーバからのレスポンスに基づいて、特定されるフォルダに含まれるファイルのＵＲＬを用いて、前記フォルダに含まれるいずれか一のファイルの取得要求を前記クライアントから受信した場合、前記フォルダに含まれる他のファイルも前記サーバからプリフェッチして前記バッファに保存し、
    前記クライアントからの前記他のファイルの取得要求に応じて、保存したファイルをクライアントに送信する
    ことを特徴とするプロキシシステム。
  13. 請求項１２記載のプロキシシステムであって、
    前記クライアント通信部は、複数の前記クライアントと通信し、
    前記通信制御部は、前記複数のクライアントから、ＰＲＯＰＦＩＮＤを受信した場合、前記バッファに保存したファイルを当該複数のクライアントにそれぞれ送信し、当該ファイルを前記バッファから削除する
    ことを特徴とするプロキシシステム。
JP2012085993A 2012-04-05 2012-04-05 パケット通信装置および方法 Expired - Fee Related JP5948111B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012085993A JP5948111B2 (ja) 2012-04-05 2012-04-05 パケット通信装置および方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012085993A JP5948111B2 (ja) 2012-04-05 2012-04-05 パケット通信装置および方法

Publications (2)

Publication Number Publication Date
JP2013218387A JP2013218387A (ja) 2013-10-24
JP5948111B2 true JP5948111B2 (ja) 2016-07-06

Family

ID=49590441

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012085993A Expired - Fee Related JP5948111B2 (ja) 2012-04-05 2012-04-05 パケット通信装置および方法

Country Status (1)

Country Link
JP (1) JP5948111B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20260095366A1 (en) * 2024-09-30 2026-04-02 Zoom Communications, Inc. Identifying Firewall Issues Impacting Communication Sessions

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015001784A (ja) * 2013-06-13 2015-01-05 富士通株式会社 情報処理システム、情報処理装置、及び情報処理プログラム
WO2016132501A1 (ja) * 2015-02-19 2016-08-25 富士通株式会社 通信装置、情報処理方法、及び、情報処理プログラム
JP6620788B2 (ja) * 2017-06-15 2019-12-18 富士通クライアントコンピューティング株式会社 データ提供システム、情報処理方法および情報処理プログラム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4514872B2 (ja) * 2000-01-26 2010-07-28 シャープ株式会社 情報取得装置および情報取得方法、ならびに情報取得プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2003186785A (ja) * 2001-12-14 2003-07-04 Sanyo Electric Co Ltd ローカルサーバ、情報配信システムおよびユーザ端末装置
JP5172169B2 (ja) * 2007-02-16 2013-03-27 シャープ株式会社 コンテンツ表示装置、テレビジョン受像機、コンテンツ表示方法、コンテンツ表示制御プログラム、および記録媒体
JP5439761B2 (ja) * 2008-07-25 2014-03-12 富士通株式会社 コンテンツ再生装置、コンテンツ再生方法およびコンテンツ再生プログラム
JP5442541B2 (ja) * 2010-06-21 2014-03-12 日本電信電話株式会社 Ｗｅｂ情報取得方法および装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20260095366A1 (en) * 2024-09-30 2026-04-02 Zoom Communications, Inc. Identifying Firewall Issues Impacting Communication Sessions

Also Published As

Publication number Publication date
JP2013218387A (ja) 2013-10-24

Similar Documents

Publication Publication Date Title
US10778554B2 (en) Latency measurement in resource requests
TWI444079B (zh) 用於在應用層連結/聚合多個介面的方法、處理器、電腦程式產品及裝置
EP2272239B1 (en) Server selection for routing content to a client using application layer redirection
US10630758B2 (en) Method and system for fulfilling server push directives on an edge proxy
Bormann et al. CoAP (constrained application protocol) over TCP, TLS, and WebSockets
US9253065B2 (en) Latency measurement in resource requests
US8924528B1 (en) Latency measurement in resource requests
US10645145B2 (en) Method and apparatus for accelerating data transmission in a network communication system
US20180375952A1 (en) Method and apparatus for reducing network resource transmission size using delta compression
CN103312807B (zh) 数据传输方法、装置及系统
US8984164B2 (en) Methods for reducing latency in network connections and systems thereof
EP2988518B1 (en) System and method for all-in-one content stream in content-centric networks
US20110280247A1 (en) System and method for reducing latency via multiple network connections
JP5948111B2 (ja) パケット通信装置および方法
CN103533080A (zh) 用于lvs的服务器调度方法及装置
US8539099B2 (en) Method for providing on-path content distribution
CN108605039B (zh) 在spdy连接上检测恶意软件
WO2013180255A1 (ja) 通信装置および方法
US10110646B2 (en) Non-intrusive proxy system and method for applications without proxy support
US20110282926A1 (en) Relay apparatus, recording medium storing a relay program, and a relay method
JP2013088998A5 (ja)
CN107612831B (zh) 一种访问源站的数据报文的传输方法及装置
Netravali Understanding and improving web page load times on modern networks
Blanchet Postellation: an enhanced delay-tolerant network (dtn) implementation with video streaming and automated network attachment
WO2015117677A1 (en) Method and software for transmitting website content

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20141107

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20151020

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20151218

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160510

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160606

R151 Written notification of patent or utility model registration

Ref document number: 5948111

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees