JP2013250691A - 通信装置および方法 - Google Patents

Abstract

【課題】 ネットワークセキュリティシステムの存在下でも異常な通信と判断されることのなく、サーバが管理する複数のオブジェクトをクライアントに提供することである。
【解決手段】 本発明の一態様は、クライアントに接続される第一の通信装置及びファイルを管理するサーバに接続される第二の通信装置により前記クライアントと前記サーバとの通信を中継する通信方法であって、クライアントからのファイル取得リクエストに応じて、第二の通信装置が先読み処理を実行し、第一の通信装置から送信される通知に対応させて、サーバから得られたオブジェクトを第二の通信装置から第一の通信装置に送信する。
【選択図】 図１

Description

本発明は、通信装置および方法に関する。

ウェブシステムにおいて、クライアント側で、サーバからの情報を表示しようとする場合、クライアントサーバ間で、ウェブブラウザはHTMLを解析し、オブジェクトを発見するたびにそのオブジェクトに対するGETリクエストをサーバに送信する。通常ブラウザから一つのサーバへの同時接続数は制限されているため、ウェブページの読み込みにはクライアント・サーバ間の往復が多数回行われることとなる。

クライアントとサーバが大陸間海底ケーブルなどの遅延の大きなワイドエリアネットワーク (Wide Area Network: WAN)により接続されている場合、ハイパーテキスト転送プロトコル (Hyper Text Transfer Protocol: HTTP)による通信は、効率が著しく低下する。遅延の大きなネットワークでは、クライアントがリクエストを送信してからサーバからレスポンスが返ってくるまで長い時間がかかり、クライアントはその間待機する必要を生じる。これが多数回行われるためウェブページをリクエストしてから表示が完了するまでの時間が長くなる。

例えば、クライアントとサーバが、衛星回線を通じて通信し、ＨＴＴＰプロトコルに従って、サーバから衛星回線を介してダウンロードされるウエブページのインラインオブジェクトの呼び出し遅れを防ぐために、分散プロキシサーバが、基本コンポーネントの取得時に、インラインオブジェクトを先読みする技術が特許文献１に開示されている。

一方で、ネットワークのセキュリティ確保のため、企業や通信事業者はネットワークセキュリティ機器を導入している。

例えば、特許文献２では、パケットデータサービス提供ノード１６０は、データのフローを管理するために、ディープパケット検査デバイス１５０によってデータパケット内に挿入されたアプリケーション情報を利用する。より詳細には、様々な例示的な実施形態において、パケットデータサービス提供ノード１６０は、データパケット内で見つかった情報を使用して、アプリケーションを識別し、そのパケットを許可するかまたはドロップするかを決定することなど、サービスの品質処理を実行する。特許文献２の、ディープパケット検査デバイスのようなものとして、ほかには、ファイアウォール、Intrusion Detection System (IDS)、Intrusion Protection System (IPS)、という機能が実装されるデバイスがある。これらはネットワーク上の通信を監視し、不正な通信や、攻撃とみなされる通信を検出した場合には、通信を遮断するなどの機能を持っている（特許文献３、４参照）。 ファイアウォールは主にTransmission Control Protocol (TCP)におけるポート単位の通信許可を制御する機器で、内部サーバが外部ネットワークに公開していないポートに対するアクセスを禁止し攻撃を防ぐ。IDSはパケットのヘッダまたはサーバのアクセスログを監視し、あらかじめ設定された不正アクセスのパターンにマッチするアクセスを受けた場合に管理者に通知する。IPSはIDSに通信遮断機能を付加したもので、不正アクセスのパターンを発見するとすぐに攻撃に対処することができる。

WO1999008429A US2009/0238192 特開2000-261483 特開2005-38116

企業ネットワークなどでは、ファイアウォールおよびIDS、IPSは主にその企業が設置し、ローカルエリアネットワーク(Local Area Network: LAN)とWANとの境界に設置される。そのため、これらの装置を利用する企業自身が管理することが容易である。一方DPIは企業ネットワークが接続する通信事業者のネットワークに設置されるため、ネットワーク利用者が管理することは容易ではない。

また、DPIはパケットをアプリケーション層のヘッダやデータまで監視する。これによりアプリケーション層でのプロトコル整合性や、データ部におけるウイルスなどの不正なデータの有無を検査する。前記のような異常が発見されると、通信を遮断することも可能である。そのため標準化されていない独自プロトコルや既存プロトコルの独自拡張は遮断されてしまう可能性がある。

WANにDPIなどのネットワークセキュリティシステムが設置されている場合、HTTPの独自拡張である従来技術における通信は不正な通信とみなされてしまう。従来技術ではプリフェッチしたファイルをサテライトゲートウェイコンポーネント（２０５）からアクセスポイントコンポーネント（２０２）へ転送するが、この転送がアクセスポイントコンポーネント（２０２）からのリクエストを伴わずサテライトゲートウェイコンポーネント（２０５）が一方的に送りつける形態となる。そのため、この通信はHTTPのプロトコルを守っておらず、セキュリティシステムによってアクセスポイントコンポーネント（２０２）側への攻撃とみなされる。その場合、この通信は遮断されてしまい、プリフェッチデータをアクセスポイントコンポーネント（２０２）、ひいてはブラウザ（２０１）に届けることができなくなる可能性がある。

本発明の目的は、ネットワークセキュリティシステムの存在下でも異常な通信と判断されることのなく、サーバが管理する複数のオブジェクトをクライアントに提供することである。

上記課題の少なくとも一を解決するために、本発明の一態様は、クライアントに接続される第一の通信装置及びファイルを管理するサーバに接続される第二の通信装置により前記クライアントと前記サーバとの通信を中継する通信方法であって、クライアントからのファイル取得リクエストに応じて、第二の通信装置が先読み処理を実行し、第一の通信装置から送信される通知に対応させて、サーバから得られたオブジェクトを第二の通信装置から第一の通信装置に送信する。

また、第二の態様は、クライアントに接続され、ファイルを管理するサーバに接続される第二の通信装置を介して前記クライアントと前記サーバとの通信を中継する第一の通信装置で、以下の構成を有する。具体的には、第一の通信装置は、前記クライアントから受信され、前記サーバを宛先とする前記ファイルの取得リクエストを前記第二の通信装置に転送処理部と、前記第二の通信装置で実行される、先読み処理により取得される、前記ファイルで参照される関連ファイルを、前記第一の通信装置から送信される通知に対応させて、前記関連ファイルを受信する関連ファイル受信部と、前記第一の通信装置で、前記関連ファイルを前記ファイルと対応付けて保持する保持部と、前記クライアントからの前記関連ファイルの参照要求に応じて、前記関連ファイルを前記クライアントに送信する送信部とを有する。

また、第三の態様は、クライアントに接続される第一の通信装置を介して、ファイルを管理するサーバに接続され、前記クライアントと前記サーバとの通信を中継する第二の通信装置であって、以下の構成を有する。つまり、第二の通信装置は、前記第一の通信装置で転送される前記クライアントからの前記サーバを宛先とする前記ファイルの取得リクエストに基づいて取得されるファイルを前記サーバから取得するファイル取得部と、
前記ファイルで参照される他の関連ファイルの先読み処理を実行し、関連ファイルを取得する先読み処理部と、前記関連ファイルを、前記第一の通信装置から送信される通知に対応させて、前記関連ファイルを前記第一の通信装置に送信する送信処理部と、を有する。

より具体的な一態様では、たとえば、第一ないし第三の態様において、通信はHTTP(Hyper Text Transport Protocol)に従って行われる。または、ファイルは、ＨＴＭＬ（Hyper Text Markup Language）でクライアントでウエブページを表示するための情報と、先読み対象となる関連ファイルのURLを示すリンクとを含む態様である。

本発明によれば、遅延の大きなネットワークを介した通信において、セキュリティシステムの存在下においても通信の遮断を防ぎつつ、通信を高速化することができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明の実施例１における通信方式を表すシーケンス図である。 本実施例のネットワーク構成を示す図である。 本発明の実施例１及び２におけるクライアント側プロキシのデータ管理テーブルを表す図。 本発明の実施例１及び２におけるサーバ側プロキシのデータ管理テーブルを表す図である。 本発明の実施例１におけるクライアント側プロキシのリクエスト判定部の動作を表すフローチャートである。 本発明の実施例１におけるクライアント側プロキシのリクエスト送信部の動作を表すフローチャートである。 本発明の実施例１におけるクライアント側プロキシのレスポンス解析部の動作を表すフローチャートである。 本発明の実施例１におけるクライアント側プロキシのデータ管理部の動作を表すフローチャートである。 本発明の実施例１におけるサーバ側プロキシのリクエスト判定部の動作を表すフローチャートである。 本発明の実施例１におけるサーバ側プロキシのレスポンス解析部の動作を表すフローチャートである。 本発明の実施例１におけるサーバ側プロキシのデータ管理部の動作を表すフローチャートである。 本発明の実施例２における通信方式を表すシーケンス図である。 本発明の実施例２におけるオブジェクトのクラス分類テーブルを表す図である。 本発明の実施例３における通信方式を表すシーケンス図である。 本発明の実施例４における通信方式を表すシーケンス図である。 本発明の実施例４におけるクライアント側プロキシのデータ管理テーブルを表す図である。 本発明の実施例４におけるクライアント側プロキシのリクエスト送信部の動作を表すフローチャートである。 本発明の実施例５における通信方式を表すシーケンス図である。 本発明の実施例５におけるクライアント側プロキシのリクエスト送信部の動作を表すフローチャートである。

図2は、実施例１におけるネットワーク構成を表す図である。クライアント（１１）と同一のLAN（１３）内にクライアント側プロキシ（１２）を設置し、クライアント側プロキシ（１２）がWAN（１４）との通信を行う。同様に、サーバ（１６）と同一のLAN（１７）内にサーバ側プロキシ（１５）を設置し、サーバ側プロキシ（１５）がWANとの通信を行う。クライアント側プロキシ（１２）とサーバ側プロキシ（１５）が協調して動作することにより、遅延の大きなWANでも性能劣化を抑えて通信を行うことを可能とする。クライアント側プロキシ(12)及びサーバ側プロキシ（１５）は、通信装置であって、たとえば、クライアントあるいはサーバそれぞれのLAN（Local AreaNetwork）のゲートウエイ装置であってもよい。クライアント（１２）は、ウエブページを表示する表示部を備える情報処理装置である。一方、サーバ（１６）はHTMLファイルとそのファイルと関連する外部ファイルとを記録する記憶部とを有する情報処理装置である。

次に、クライアント側プロキシ（１２）の内部構成を説明する。LAN側コネクション管理部（２１）はクライアント（１１）との通信を担当する。

クライアント（１１）からのリクエストはリクエスト判定部（２２）にて、プリフェッチ動作の契機となるHTMLファイルに対するGETであるか、個別の外部ファイルに対するリクエストであるかが判定される。

プリフェッチ動作中でないとき、受信したリクエストはそのままリクエスト送信部（２３）に送られ、サーバ側プロキシ（１５）へ送信される。プリフェッチ動作中はリクエストは一旦データ管理部（２７）に登録される。

WAN側コネクション管理部（２４）はWANを通じてサーバ側プロキシ（１５）との通信を担当する。リクエスト送信部（２３）はリクエスト判定部（２２）またはデータ管理部（２７）から受け取ったリクエストをWAN側コネクション管理部（２４）を用いて送信する。

レスポンス解析部（２５）ではサーバ側プロキシ（１５）から受信したレスポンスがHTMLファイルであればその内容を解析しファイル一覧を取得し、データ管理部（２７）に登録する。同時にレスポンス送信部（２６）に渡してクライアント（１１）へ転送する。その他の外部ファイルであればデータ管理部（２７）に登録する。レスポンス送信部（２６）ではレスポンス解析部（２５）またはデータ管理部（２７）から受信したレスポンスデータをLAN側コネクション管理部（２１）に渡してクライアント（１１）へ転送する。

データ管理部（２７）は、IPアドレスで識別されるクライアント（１１）ごとにテーブルを持ち、リクエスト・レスポンスの状態とそのデータを管理する。例えばクライアント（１１）が３台あれば３つのテーブル（２８ａ〜ｃ）を持つ。リクエストを受信すればそのパス名をキーとしてテーブルを検索して、リクエスト受信済みのフラグを1に設定する。またプリフェッチされたレスポンスを受信すればレスポンス受信済みのフラグを1に設定する。テーブルのエントリは定期的に調べられ、リクエスト受信済みかつレスポンス受信済みであれば、レスポンスをレスポンス送信部（２６）へ渡し、クライアント（１１）へ送信する。リクエスト受信時にレスポンスが登録されていなければ、リクエストをリクエスト送信部（２３）へ渡してサーバ側プロキシ（１５）へ送信してもよい。

サーバ側プロキシ（１５）の内部構成を図2を用いて説明する。WAN側コネクション管理部（３１）はクライアント側プロキシ（１２）との通信を担当する。クライアント側プロキシ（１２）からのリクエストはリクエスト判定部（３２）にて、プリフェッチ動作の契機となるHTMLファイルに対するGETであるか、個別の外部ファイルに対するリクエストであるかが判定される。プリフェッチ動作中でないとき、受信したリクエストはそのままリクエスト送信部（３３）に送られ、サーバ（１６）へ送信される。プリフェッチ動作中はリクエストは一旦データ管理部（３７）に登録される。

リクエスト送信部（３３）はリクエスト判定部（３２）またはデータ管理部（３７）から受け取ったリクエストをLAN側コネクション管理部（３４）を介して送信する。LAN側コネクション管理部（３４）はサーバ（１６）との通信を担当する。

レスポンス解析部（３５）ではサーバ（１６）から受信したHTMLファイルを解析しファイル一覧を取得してデータ管理部（３７）に登録する。同時にレスポンス送信部（３６）に渡してクライアント側プロキシ（１２）へ転送する。またレスポンスがGETに対するレスポンスであればデータ管理部（３７）に登録する。レスポンス送信部（３６）ではレスポンス解析部（３５）またはデータ管理部（３７）から受信したレスポンスデータをWAN側コネクション管理部（３１）に渡してクライアント側プロキシ（１２）へ転送する。言い換えると、レスポンス送信部（３６）ではレスポンス解析部（３５）またはデータ管理部（３７）よりWAN側に送信するデータを受信し、同データをWANコネクション管理部（３１）よりクライアント側プロキシ（１２）へ送信する。

データ管理部（３７）は、クライアント側プロキシ（１２）と同様にクライアント（１１）ごとにデータ管理テーブルを持ち、リクエスト・レスポンスの状態とそのデータを管理する。例えばクライアント（１１）が３台あれば３つのテーブル（３８ａ〜ｃ）を持つ。プリフェッチ動作中は、テーブルは定期的に調べられ、プリフェッチ未了のエントリがあればプリフェッチを行うため、プリフェッチリクエストを生成し、リクエスト送信部（３３）へ渡す。クライアント側プロキシ（１２）からリクエストを受信した場合、該当レスポンスをプリフェッチしていなければ、そのリクエストを優先的にリクエスト送信部（３３）へ渡し、サーバ（１６）へ送信してもよい。 本発明の第一の実施例における通信シーケンスを図１に示す。図１では通信にかかわる、クライアント（１１）、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）、およびサーバ（１６）のシーケンスを示している。

クライアントがサーバ（１６）上のウェブページにアクセスする際、まずそのページ本体を記述するHTMLファイルにGETというリクエスト（１０１）が発行される。これはクライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWAN（１４）上を転送される（１２１）。クライアント側プロキシ（１２）は、ウェブページに含まれる外部ファイルをプリフェッチするため、サーバ側プロキシ（１５）にプリフェッチリクエストを送信する（１２２）。ただし、この時点では前記外部ファイルの数およびその名前が不明であるため、仮に「files.dat」という名前のファイルを１つだけリクエストする。

サーバ側プロキシ（１５）は、前記HTMLファイルに対するリクエストを受信すると、サーバ（１６）へさらに転送する（１４１）。前記リクエストを受信したサーバ（１６）は、それに対するレスポンスとして前記HTMLファイルをサーバ側プロキシへ（１５）返送する（１４２）。前記レスポンスはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１２３）、サーバ側プロキシ（１５）は前記レスポンスを解析（１６１）することによりウェブページに埋め込まれている外部ファイルの一覧を取得し、サーバから先読みすべき関連ファイルを特定する。前記レスポンスはさらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１０２）。クライアント（１１）はサーバ側プロキシ（１５）とは別に前記レスポンスを解析（１６２）して外部ファイル一覧を取得する。外部ファイル一覧を取得したクライアント（１１）は、その各外部ファイルに対してリクエストを送信する（１０３）。

外部ファイル一覧を取得したサーバ側プロキシ（１５）は、クライアント側プロキシ（１２）からのプリフェッチリクエスト（１２２）に応答するため、外部ファイルのプリフェッチを行う。ウェブページに外部ファイルfile1〜file3が含まれていたとすると、サーバ（１６）にこれらの外部ファイルに対するGETを送信し（１４３、１４５、１４７）、サーバ（１６）からそれぞれレスポンス（１４４、１４６、１４８）を得る。サーバ側プロキシ（１５）はこれらの外部ファイルを連結し（１６３）、プリフェッチリクエスト（１２２）に対するレスポンスとして、クライアント側プロキシ（１２）に送信する（１２４）。

クライアント側プロキシ（１２）ではプリフェッチレスポンス（１２４）を受信すると、これを展開して元の外部ファイルを得る（１６４）。外部ファイルを取得したクライアント側プロキシ（１２）では、クライアント（１１）からのリクエスト（１０３、１０５、１０７）に対して対応する外部ファイルをレスポンスとして送信する（１０４、１０６、１０８）。外部ファイルを受信したクライアント（１１）は、それらの外部ファイルを用いてウェブページの描画を行う。

上記方法によりWAN（１４）上のトラフィックは正常なHTTP通信となり、セキュリティシステムによる遮断を免れることができる。
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。 クライアント側プロキシ（１２）のデータ管理部におけるデータ管理テーブル（２８）を図3に示す。テーブル（２８）はクライアント（１１）のIPアドレス（４１）およびサーバ（１６）のIPアドレス（４２）を持ち、それらの組合せによって識別される。また、プリフェッチに用いるポート番号（４３）も持つ。また対象となる外部ファイルごとに、ファイルのURL（４４）、プリフェッチしたレスポンス（４５）、1または0の値をとる2種類のフラグ（４６、４７）、およびクライアント（１１）がリクエストを行ったLAN側のポート番号（４８）を保持する。フラグは「クライアントからリクエスト受信済み（４６）」および「サーバ側プロキシからレスポンス受信済み（４７）」である。

「クライアントからリクエスト受信済み（４６）」フラグはその外部ファイルに対するリクエストをクライアント（１１）から受信したとき1に設定される。「サーバ側プロキシからレスポンス受信済み（４７）」フラグはそのファイルをサーバ側プロキシ（１５）から受信したとき1に設定される。これらのフラグの両方が1となっていれば、レスポンスはクライアント側プロキシ（１２）からクライアント（１１）へ送信され、該当エントリは削除される。

サーバ側プロキシ（１５）のデータ管理部におけるデータ管理テーブル（３８）を図4に示す。テーブル（２８）はクライアント（１１）のIPアドレス（４１）およびサーバ（１６）のIPアドレス（４２）を持ち、それらの組合せによって識別される。また、プリフェッチレスポンスの送信に用いるポート番号（４３）およびクライアント側プロキシ（１２）からプリフェッチリクエストを受信したことを示すフラグ（５１）も持つ。

また対象となるファイルごとに、ファイルのURL（５２）、プリフェッチしたレスポンス（５３）、1または0の値をとる２種類のフラグ（５４、５５）、およびサーバ（１６）からのプリフェッチに使用するLAN側のポート番号（５６）を持つ。フラグは「サーバにプリフェッチリクエスト送信済み（５４）」、「クライアント側プロキシからリクエスト受信済み（５５）」である。

「サーバにプリフェッチリクエスト送信済み（５４）」フラグはそのファイルに対するリクエストをサーバ（１６）に送信したとき1に設定される。「クライアント側プロキシからリクエスト受信済み（５５）」フラグはクライアント側プロキシ（１２）からリクエストを受信したときに1に設定される。プリフェッチデータの送信が完了するとエントリはすべて削除される。

図5クライアント側プロキシ（１２）における各部の動作を表すフローチャートである。図5はクライアント側プロキシ（１２）におけるリクエスト判定部（２２）の動作を示すフローチャートである。リクエスト判定部（２２）ではLANコネクション管理部（２１）よりクライアント（１１）からのリクエストを受信し（３０１）、同リクエストがウェブページ本体であるHTMLファイルに対するリクエストであるかどうか判定する（３０２）。HTMLファイルに対するリクエストであった場合は同リクエストをリクエスト送信部（２３）へ転送し（３０３）、また、リクエスト送信部（２３）へプリフェッチリクエストの送信を指示する（３０４）。HTMLファイルに対するリクエストでなかった場合は外部ファイルに対するリクエストとして、データ管理部へ転送し、プリフェッチテーブルに登録する（３０５）。

図6はクライアント側プロキシ（１２）におけるリクエスト送信部（２３）の動作を表すフローチャートである。リクエスト送信部（２３）はリクエスト判定部（２２）またはデータ管理部（２７）よりリクエストを受信すると（３１１）、同リクエストがファイルに対するGETであるか外部ファイルに対するプリフェッチのリクエストであるかを判定する（３１２）。プリフェッチのリクエストであった場合はそのリクエストを生成すし（３１４）、WANコネクション管理部（２４）よりサーバ側プロキシ（１５）に送信する（３１３）。外部ファイルに対するGETであった場合はそのままWANコネクション管理部（２４）よりサーバ側プロキシ（１５）に送信する（３１３）。

図7は、クライアント側プロキシ（１２）におけるレスポンス解析部（２５）の動作を表すフローチャートである。レスポンス解析部（２５）はWANコネクション管理部（２４）より、サーバ側プロキシ（１５）から受信したレスポンスを受信（３３１）する。同レスポンスがHTMLファイルであるかを判定し（３３２）、HTMLファイルであった場合はレスポンス送信部（２６）へ転送する（３３３）。そうでなければプリフェッチされた外部ファイルであるのでそれを展開し（３３４）、データ管理部（２７）へ転送する（３３５）。

図8はクライアント側プロキシ（１２）におけるデータ管理部（２７）の動作を表すフローチャートである。データ管理部（２７）はリクエスト判定部（２２）またはレスポンス解析部（２５）よりデータを受信すると（３４１）、受信データのIPアドレスより対応するクライアント（１１）のテーブルを選択する（３４２）。

次に、入力データがリクエストであれば（３４３）、テーブルを検索してリクエストされたURLが登録されているか調べる（３４４）。登録されていなかった場合はテーブルに登録する（３４５）。この状態でリクエストのエントリが存在するので、同エントリにクライアント（１１）がリクエストに用いたポート番号を登録し（３４６）、リクエスト受信済みフラグ（４６）を設定する（３４７）。

入力データがプリフェッチされた外部ファイルであれば、テーブルを検索してプリフェッチされたURLが登録されているか調べる（３４８）。登録されていなかった場合はテーブルに登録する（３４９）。この状態でプリフェッチされた外部ファイルのエントリが存在するので、その内容を登録し（３５０）、レスポンス受信済みフラグ（４７）を設定する（３５１）。

入力データがない場合は（３４１）テーブルおよびそのエントリを一つ選択し（３５２）、フラグの状態を調べる。リクエスト受信済み（４６）かつレスポンス受信済みであれば（３５３）、テーブル中のレスポンスをレスポンス送信部へ転送し、クライアント（１１）へ送信し（３５４）、エントリを削除する（３５５）。なお、エントリの削除はレスポンスの送信直後ではなく、後にフラグ状態を調べて行ってもよい。以上が、クライアント側プロキシ（１２）の具体的な動作の説明である。

図9〜図１１は、サーバ側プロキシ（１５）における各部の動作を表すフローチャートである。図9はサーバ側プロキシ（１５）におけるリクエスト判定部（３２）の動作を表すフローチャートである。リクエスト判定部（３２）ではWANコネクション管理部（３１）よりリクエストを受信すると（４０１）、同リクエストが、HTMLファイルを含むサーバ（１６）上のファイルに対するリクエストであるか、またはプリフェッチのリクエストであるかを判定する（４０２）。ファイルに対するリクエストであった場合はリクエスト送信部へ転送し（４０３）、プリフェッチリクエストであった場合はデータ管理部へ転送する。

図10はサーバ側プロキシ（１５）におけるレスポンス解析部（３５）の動作を表すフローチャートである。レスポンス解析部（３５）ではLANコネクション管理部（３４）よりレスポンスを受信し（４３１）、同レスポンスがHTMLファイルであるか外部ファイルであるかを判定する（４３２）。HTMLファイルであった場合は前記HTMLファイルをレスポンス送信部（３６）へ転送する（４３３）。また前記HTMLファイルを解析して外部ファイル一覧を作成し（４３４）、データ管理部（３７）へ転送してプリフェッチテーブル（３８）に登録する。

図11はサーバ側プロキシ（１５）におけるデータ管理部（３７）の動作を表すフローチャートである。データ管理部（３７）はリクエスト判定部（３２）またはレスポンス解析部（３５）よりデータを受信すると（４４１）、受信データのIPアドレスより対応するクライアント（１１）のテーブルを選択する（４４２）。入力データがリクエストであれば（４４３）、プリフェッチリクエスト受信済みフラグ（５１）を設定する（４４４）。

入力データがプリフェッチされた外部ファイルであれば、ポート番号より対応するエントリを選択し（４４５）、レスポンス受信済みフラグ（４７）を設定する（４４６）。

入力データがない場合は（４４１）テーブルの全てのエントリについてフラグの状態を調べる（４４７）。未取得の外部ファイルがあった場合は（４４８）、プリフェッチを行うためプリフェッチリクエストを生成する（４４９）。また、プリフェッチに使用するサーバ側プロキシ（１５）のポート番号を取得しテーブルに登録する（４５０）。そしてリクエスト送信部へ転送して（４５１）サーバ（１６）に送信し、プリフェッチリクエスト送信済みフラグを1に設定する（４５２）。

未取得の外部ファイルがなかった場合は、全ての外部ファイルを連結し（４５３）、レスポンス送信部へ転送して（４５４）クライアント側プロキシ（１２）へ送信する。送信が完了するとテーブルのエントリを削除する（４５５）。なお別途プリフェッチレスポンス送信済みを表すフラグを用いれば、エントリの削除はプリフェッチレスポンスの送信直後ではなく、後にフラグ状態を調べて行ってもよい。

以上が、実施例１の説明である。実施例１によると、クライアント側プロキシ（１２）からのGET Filesのリクエスト（１２２）と、サーバ側プロキシ（１５）で、先読みされた一以上の外部ファイルをまとめてプリフェッチレスポンスとなる２００OK（１２４）のメッセージとが対応することで、プロキシ間の通信が不正な通信と判断されず、クライアント側へ先読みファイルを提供することができる。

実施例１の方法では、全ての外部ファイルのプリフェッチが完了するまで転送が行われず、外部ファイルがクライアント（１１）に転送開始されるまでに待ち時間が発生してしまう。そこで、WAN上の転送を分割して、プリフェッチが完了する前に取得済みの外部ファイルから送信することで上記の待ち時間を削減する。また、実施例２では、プロキシ間の通信が不正な通信と判断されず、クライアント側へ先読みファイルを提供する。

本発明の第二の実施例では、HTMLファイルが参照する外部ファイルをあらかじめ決められた複数のクラスに分け、そのクラスごとに1つ以上の外部ファイルをまとめて転送する方法を示す。クラス（属性）の例として、次の分類を行う。1つ目はウェブページの表示を記述するCSS、2つ目はウェブページ中に表示される画像、3つ目はウェブページの表示には直接かかわらないスクリプトなどその他のファイルである。なお、クラスの分類と設定は管理者が手動で行うことを想定しているが、プロキシ装置により自動的に行ってもよい。クラス数および分類方法も任意である。

本実施例における通信シーケンスを図12に示す。図12では通信にかかわる、クライアント（１１）、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）、およびサーバ（１６）のシーケンスを示している。

クライアント（１１）がサーバ（１６）上のウェブページにアクセスする際、まずそのページ本体を記述するHTMLファイルにGETというリクエスト（１０１）が発行される。これはクライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWAN（１４）上を転送される（１２１）。クライアント側プロキシ（１２）は、ウェブページに含まれる外部ファイルをプリフェッチするため、サーバ側プロキシ（１５）に、事前に設定されたクラス分のプリフェッチリクエストを送信する。図12では3つのクラスを用いているため、3つのプリフェッチリクエスト（５０１〜５０３）を送信している。

サーバ側プロキシ（１５）はHTMLファイルに対するリクエストを受信すると、サーバ（１６）へさらに転送する（１４１）。前記リクエストを受信したサーバ（１６）は、それに対するレスポンスとしてHTMLファイルをサーバ側プロキシ（１５）へ返送する（１４２）。前記HTMLファイルはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１２３）、サーバ側プロキシ（１５）はこのHTMLファイルを解析（１６１）することによりウェブページに埋め込まれている外部ファイル一覧を取得する。前記HTMLファイルはさらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１０２）。クライアント（１１）はサーバ側プロキシ（１５）とは別にこのHTMLファイルを解析（１６２）して外部ファイル一覧を取得する。外部ファイル一覧を取得したクライアント（１１）は、その各外部ファイルに対してリクエストを送信する（１０３）。

外部ファイル一覧を取得したサーバ側プロキシ（１５）は、そのURLをもとに各外部ファイルのクラス分けを行う。そしてクラスごとにプリフェッチおよびクライアント側プロキシ（１２）からのプリフェッチリクエストに対するレスポンスの生成・送信を行う。クラス分けの結果、file1.cssおよびfile2.cssがCSSクラスに分類される。サーバ側プロキシ（１５）はこれらに対するリクエストを行い（１４３、１４５）、それぞれレスポンスを得る（１４４，１４６）。次にこれらのレスポンスを連結し（１６３）、クライアント側プロキシ（１２）に、CSSクラスに対するプリフェッチリクエスト（５０１）へのレスポンスとして送信する（５０４）。続いて同様に、画像クラスに分類されたfile4.jpgおよびfile5.pngをプリフェッチし（１４７、１４９）、そのレスポンスを得ると（１４８、１５０）、それを連結し（１６５）プリフェッチリクエスト（５０２）に対するレスポンスとして送信する（５０５）。その他のクラスに分類されたファイルについても同様にプリフェッチ（１５１〜１５４）と転送（１６７、５０６）を行う。

クライアント側プロキシ（１２）ではプリフェッチレスポンス（５０４）を受信すると、これを展開して元の外部ファイルを得る（１６４、１６６、１６８）。外部ファイルを取得したクライアント側プロキシ（１２）では、クライアント（１１）からのリクエスト（１０３、１０５、１０７、１０９、１１０、１１３）に対して対応する外部ファイルをレスポンスとして送信する（１０４、１０６、１０８、１１０、１１２、１１４）。外部ファイルを受信したクライアント（１１）はそれらの外部ファイルを用いてウェブページの描画を行う。

上記方法によりWAN（１４）上のトラフィックは正常なHTTP通信となり、セキュリティシステムによる遮断を免れることができる。

上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。

装置内の構成については実施例１の場合と同様であるので、ここでは省略するが、プリフェッチ状況を管理するためのテーブル（２８、３８）は項目が、実施例１に比べて追加される。

実施例２でのクライアント側プロキシ（１２）のデータ管理部におけるデータ管理テーブル（２８）は、実施例１で既に説明したものに、さらに図3に示すように各外部ファイルのクラス分類（５１１）を保持する。

実施例２での、サーバ側プロキシ（１５）のデータ管理部におけるデータ管理テーブル（３８）を図９(b)に示す。データ管理テーブル（３８）はは実施例１のものに追加して各外部ファイルのクラス分類（５１１）を保持する。

さらに、本実施例では、クライアント側プロキシ（１２）およびサーバ側プロキシ（１５）にて、図13のクラステーブル（５１３）を保持する。クラステーブル（５１３）はクラスごとに優先度（５１４）、クラス名（５１５）、およびクラス分けのルール（５１６）を保持する。つまり、クラステーブル（５１３）は、クラスとその優先度との対応付けを保持する。エントリをテーブルに登録する際には、このルール（５１６）と比較してマッチしたクラスに分類される。また、プリフェッチは優先度（５１４）の順に実行される。

クライアント側プロキシ（１２）の動作は実施例１と同様であるので、ここではフローチャート等は省略する。

サーバ側プロキシ（１５）の動作もレスポンス解析部（３５）およびデータ管理部（３７）以外は実施例１と同様であるので、そのフローチャート等は省略する。本実施例におけるサーバ側プロキシ（１５）のレスポンス解析部（３５）の動作を説明する。

実施例２のサーバ側プロキシ（１５）のレスポンス解析部（３５）は、図10のフローチャートのテーブル登録（４３５）の前に、サーバ側から受信したレスポンスに含まれるHTMLファイルを解析し（４３４）、データ管理部（３７）が保持するクラステーブル（５１３）を用いて、HTMLファイルの解析結果で特定された各外部ファイルのクラスを判別する。そして、レスポンス解析部（３５）は、判別されたクラスも含めて、図10の４３５と同様に、先読み対象である外部ファイルの情報をプリフェッチテーブル（３８）内の図3のデータ管理テーブル（５１２）に登録する。その他の処理は、図10と同様である。

本実施例におけるサーバ側プロキシ（１５）のデータ管理部（３７）の動作を説明する。本実施例でのデータ管理部（３７）は、447,448,455以外は図11と同様である。

４４７の代わりに、データ管理部（３７）は、テーブル中のエントリで、クラスの優先度が最大のものに未取得のエントリがあるか調べる。未取得の外部ファイルがあった場合は（５３３）、図11の４４９ないし４５２の処理と同様である。

優先度が最大のクラスに未取得の外部ファイルがなかった場合は、データ管理部（３７）は、図11の453及び454と同様の処理を行い、送信が完了するとテーブルの該当クラスのエントリを削除する（５３４）。なお別途プリフェッチレスポンス送信済みを表すフラグを用いれば、エントリの削除はプリフェッチレスポンスの送信直後ではなく、後にフラグ状態を調べて行ってもよい。

以上が実施例２の説明である。実施例２では、クライアント側プロキシ（１２）とサーバ側プロキシ（１５）は、先読み対象の外部ファイル（関連ファイル）を当該外部ファイルの拡張子でグルーピングされる共通の情報を共有する。それぞれのプロキシは、プロキシ間の通信が遮断されないように、そのグループごとにクライアント側プロキシからの通知であるファイル取得のリクエストとサーバ側プロキシと先読みファイルの送信とを対応させる。

本発明の第三の実施例では実施例１のような転送待ち時間短縮のため、HTTP/1.1において標準化されている方式で、データの分割転送が可能なチャンク転送を用いる。チャンク転送はレスポンスがダイナミックに生成される場合など、転送されるレスポンスのサイズがあらかじめ分からない場合に用いられる。リクエスト・レスポンスの形式としては、一つのリクエストに対して一つのレスポンスとなっているが、レスポンスは送信可能な部分から順次送られる。レスポンスにおいて一回に送信されるデータの固まりをチャンクと呼び、チャンクの先頭にはそのチャンクのサイズを示す16進数の値が記載される。
本実施例における通信シーケンスを図14に示す。図14では通信にかかわる、クライアント（１１）、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）、およびサーバ（１６）のシーケンスを示している。
クライアント（１１）がサーバ（１６）上のウェブページにアクセスする際、まずそのページ本体を記述するHTMLファイルにGETというリクエスト（１０１）が発行される。これはクライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWAN（１４）上を転送される（１２１）。クライアント側プロキシ（１２）は、ウェブページに含まれる外部ファイルをプリフェッチするため、サーバ側プロキシ（１５）に、１つのプリフェッチリクエストを送信する（１２２）。

サーバ側プロキシ（１５）はHTMLファイルに対するリクエストを受信すると、サーバ（１６）へさらに転送する（１４１）。前記リクエストを受信したサーバ（１６）は、それに対するレスポンスとしてHTMLファイルをサーバ側プロキシ（１５）へ返送する（１４２）。前記HTMLファイルはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１２３）、サーバ側プロキシ（１５）はこのHTMLファイルを解析（１６１）することにより外部ファイル一覧を取得する。前記HTMLファイルはさらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１０２）。クライアント（１１）はサーバ側プロキシ（１５）とは別にこのHTMLファイルを解析（１６２）して外部ファイル一覧を取得する。外部ファイル一覧を取得したクライアント（１１）は、その各ファイルに対してリクエストを送信する（１０３）。

外部ファイル一覧を取得したサーバ側プロキシ（１５）は、クライアント側プロキシ（１２）からのプリフェッチリクエスト（１２２）に応答するため、外部ファイルのプリフェッチを行う。

ウェブページに外部ファイルfile1〜file5が含まれていたとすると、サーバ（１６）にこれらの外部ファイルに対するGETを送信し（１４３、１４５、１４７、１４９、１５１）、サーバ（１６）からそれぞれレスポンス（１４４、１４６、１４８、１０５、１５２）を得る。ここでチャンクの生成と転送は一定時間ごとに行われるとする。file2を取得した後に一定時間となり、サーバ側プロキシ（１５）は、初回のチャンクを生成する（６０１）。初回のチャンクにはHTTPレスポンスのステータスコードおよびその他のヘッダがヘッダ内に記載され、メッセージボディの先頭にチャンク送信までに取得していたファイルサイズを、チャンクサイズとして記載する。それに続いてレスポンス本体が送られる。生成したチャンクはクライアント側プロキシ（１２）へ送信される（６００ａ）。

クライアント側プロキシ（１２）ではチャンク（６００ａ）を受信すると、これを展開して元の外部ファイルを得る（６０２）。ファイルを取得したクライアント側プロキシ（１２）では、クライアント（１１）からのリクエスト（１０３、１０５）に対して対応する外部ファイルをレスポンスとして送信する（１０４、１０６）。外部ファイルを受信したクライアント（１１）はそれらの外部ファイルを用いてウェブページの描画を行う。

続いてサーバ側プロキシ（１５）では、file5まで受信した後一定時間となり、チャンクの生成を行う（６０３）。2回目以降のチャンクにはHTTPヘッダは含まれず、チャンクサイズとレスポンス本体のみとなる。サーバ側プロキシ（１５）はこれを送信し（６００ｂ）、クライアント側プロキシ（１２）にて受信される。2回目以降チャンクを受信したクライアント側プロキシ（１２）は、初回のチャンクと同様にこれを展開し、元の外部ファイルを得る（６０４）。また、クライアント（１１）からのリクエスト（１０７、１０９、１１１）に応じてレスポンスを返す（１０８、１１９、１１２）。

外部ファイルの転送を完了したサーバ側プロキシ（１５）は、チャンク転送を終了するためにチャンク末尾を示す情報を含むメッセージを生成する（６０５）。チャンク末尾のメッセージは、数字の0のみが記載されたメッセージである。これをクライアント側プロキシ（１２）へ送信する。チャンク末尾のメッセージを受信したクライアント側プロキシ（１２）は、チャンクの受信を終了する。

上記方法によりWAN（１４）上のトラフィックは、クライアント側プロキシ（１２）の一のリクエストに対し、複数のメッセージが一連のメッセージとして当該リクエストに対応する一のレスポンスと、ネットワークでは認識され、正常なHTTP通信となり、セキュリティシステムによる遮断を免れることができる。

上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。

装置内の構成およびデータ管理テーブルの構造については実施例１の場合と同様であるので、ここでは省略する。

本実施例におけるクライアント側プロキシ（１２）のレスポンス解析部（２５）の動作を説明する。それ以外の部分は実施例１と同様であるので、ここでは省略する。レスポンス解析部（２５）は、図7の３３１及び３３２と同様に、サーバ側プロキシ（１５）から受信したレスポンスがウェブページ本体を記述するHTMLファイルであるかを判定する。そうでなければ、レスポンス解析部（２５）は、チャンク転送されるプリフェッチデータで、チャンクの先頭または途中かチャンクの末尾であるかを判定する。チャンクの先頭または途中であれば、レスポンス解析部は、図7の334及び335と同様に、プリフェッチデータを展開しデータ管理部（２７）へ転送する。プリフェッチデータがチャンク末尾であれば終了して次の処理を開始する。その他の処理は、図7と同様である。

サーバ側プロキシ（１５）におけるデータ管理部（３７）の動作を説明する。データ管理部（３７）は、図11の４４７と同様に、テーブルの全てのエントリについてフラグの状態を調べる。その結果、フラグにより特定された未送信の外部ファイルがあった場合は、図14のチャンク生成処理６０１、６０３、６０３を以下の手順で行い、外部ファイルの送信またはプリフェッチリクエストの送信を行う。まずプリフェッチデータの送信が一定時間経過しているかどうかを判定する。一定時間経過していれば、取得済みのプリフェッチデータを連結してチャンクを生成し、レスポンス送信部へ転送してクライアント側プロキシ（１２）へ送信する。送信が完了するとテーブルのエントリを削除する。なお別途プリフェッチレスポンス送信済みを表すフラグを用いれば、エントリの削除はプリフェッチレスポンスの送信直後ではなく、後にフラグ状態を調べて行ってもよい。それ以外の処理は、図11と同様である。

なお、チャンクの転送は一定時間ごとでなく、取得したファイルサイズが一定値を超えるごとなど、他の基準を用いて、あるいはそれらの組み合わせによって行ってもよい。

以上が実施例３の説明である。実施例３によると、クライアント側プロキシ（１２）の一のリクエストに対し、複数のメッセージが一連のメッセージとして当該リクエストに対応する一のレスポンスと、ネットワークでは認識され、正常なHTTP通信となり、セキュリティシステムによる遮断を免れることができる。そして、本実施例では、先読みファイルのデータをクライアント側に提供することが出来、クライアントでウェブページの表示の高速化に寄与することができる。

本発明の第四の実施例では実施例１のような転送待ち時間短縮のため、クライアント側プロキシ（１２）が一定時間間隔でプリフェッチリクエストを送信する。サーバ側プロキシ（１５）はそれに対するレスポンスとして、プリフェッチリクエスト受信までに取得した外部ファイルをまとめて転送する。

本実施例における通信シーケンスを図15に示す。図15では通信にかかわる、クライアント（１１）、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）、およびサーバ（１６）のシーケンスを示している。

クライアント（１１）がサーバ（１６）上のウェブページにアクセスする際、まずそのページ本体を記述するHTMLファイルにGETというリクエスト（１０１）が発行される。これはクライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWAN（１４）上を転送される（１２１）。クライアント側プロキシ（１２）は、ウェブページに含まれる外部ファイルをプリフェッチするため、サーバ側プロキシ（１５）に、１回目のプリフェッチリクエストを送信する（７０１）。

サーバ側プロキシ（１５）はHTMLファイルに対するリクエストを受信すると、サーバ（１６）へさらに転送する（１４１）。前記リクエストを受信したサーバ（１６）は、それに対するレスポンスとしてHTMLファイルをサーバ側プロキシ（１５）へ返送する（１４２）。前記HTMLファイルはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１２３）、サーバ側プロキシ（１５）はこのHTMLファイルを解析（１６１）することにより外部ファイル一覧を取得する。前記HTMLファイルはさらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１０２）。クライアント（１１）はサーバ側プロキシ（１５）とは別にこのHTMLファイルを解析（１６２）して外部ファイル一覧を取得する。外部ファイル一覧を取得したクライアント（１１）は、その各外部ファイルに対してリクエストを送信する（１０３）。

外部ファイル一覧を取得したサーバ側プロキシ（１５）は、ウェブページに含まれる外部ファイルのプリフェッチを行う。サーバ側プロキシ（１５）は外部ファイルfile1およびfile2に対してプリフェッチリクエストを送信し（１４３、１４５）、それぞれレスポンスを得る（１４４、１４６）。このとき、クライアント側プロキシ（１２）からの1回目のプリフェッチリクエスト（７０１）を受信する。これに対してレスポンスを送信するため、サーバ側プロキシ（１５）は受信済みの外部ファイルを連結し（１６３）、クライアント側プロキシ（１２）へ送信する（７０２）。

クライアント側プロキシ（１２）は、1回目のプリフェッチリクエスト（７０１）に対するレスポンス（７０２）が到着する前に一定時間経過し、２回目のプリフェッチリクエスト（７０３）を送信する。その後、1回目のプリフェッチリクエスト（７０１）に対するレスポンス（７０２）が到着し、これを展開して元の外部ファイルを得る（１６４）。クライアント側プロキシ（１２）はクライアント（１１）からのリクエスト（１０３、１０５）に対し、取得済みの外部ファイルをレスポンスとして送信する（１０４、１０６）。

一方、サーバ側プロキシ（１５）はプリフェッチを続け、外部ファイルfile3およびfile4に対してリクエストを送信し（１４７、１４９）、レスポンスを得る（１４８、１５０）。その後、クライアント側プロキシ（１２）から2回目のプリフェッチリクエスト（７０３）が到着する。これに対するレスポンスを、1回目のプリフェッチリクエストに対するレスポンスと同様に生成し（１６５）、送信する（７０４）。

この間、クライアント側プロキシ（１２）ではプリフェッチリクエストの送信後一定時間が経過したため、3回目のプリフェッチリクエストを送信する（７０５）。その後、2回目のプリフェッチリクエスト（７０３）に対するレスポンス（７０４）が到着し、これを展開する（１６６）。クライアント側プロキシ（１２）はクライアント（１１）からのリクエスト（１０７、１０９）に応答して、取得済みの外部ファイルをレスポンスとして送信する（１０８、１１０）。

サーバ側プロキシ（１５）はクライアント側プロキシ（１２）より3回目のプリフェッチリクエストを受信するが、この時点でウェブページに含まれる外部ファイルは全て送信済みであったとする。送るべき外部ファイルが存在しないため、サーバ側プロキシ（１５）はレスポンスとして”404 Not Found”というステータスコードを返す（７０６）。これを受信したクライアント側プロキシ（１２）は、それ以降プリフェッチリクエストの送信を停止する。

本実施例の方法では、クライアント側プロキシ（１２）がプリフェッチリクエストを送信する際、未取得の外部ファイルに対してクライアント（１１）からリクエストを受信していた場合、サーバ側プロキシ（１５）に通知してクライアント側プロキシ（１２）主導でプリフェッチすることが可能である。具体的にはクライアント側プロキシ（１２）は、クライアント（１１）からリクエストされたファイル名をプリフェッチリクエストの外部ファイル名に含めることにより通知する。サーバ側プロキシ（１５）はこの通知を受け取った時、該当外部ファイルを他のプリフェッチリクエストに対するレスポンスとして送信済みであれば何もしない。

該当外部ファイルを取得済みであれば、そのプリフェッチリクエストに対するレスポンスに含めて送信する。該当外部ファイルを取得していなければ、サーバ（１６）に対しプリフェッチを行う。クライアント側プロキシ（１２）への該当外部ファイルの送信は、そのプリフェッチリクエストに対するレスポンスに含めてもよいし、そのレスポンスには含めず次のレスポンスに含めてもよい。

上記方法によりWAN（１４）上のトラフィックは正常なHTTP通信となり、セキュリティシステムによる遮断を免れることができる。

上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。

プロキシ内の構成については実施例１の場合と同様であるので、ここでの説明は省略する。

クライアント側プロキシ（１２）のデータ管理部（２７）におけるデータ管理テーブル（２８）を図16に示す。データ管理テーブル（２８）は実施例１のものに追加してプリフェッチを行うかどうかを示すプリフェッチフラグ（７１０）を保持する。また、サーバ側プロキシ（１５）のデータ管理部（３７）におけるデータ管理テーブル（３８）の構造は実施例１と同様であるので、ここでの説明は省略する。

本実施例のクライアント側プロキシ（１２）では、リクエスト送信部（２３）およびレスポンス解析部（２５）以外の部分は実施例１と同様であるので、説明は省略する。

本実施例におけるクライアント側プロキシ（１２）のリクエスト送信部（２３）の動作を図17に示す。リクエスト送信部（２３）はリクエスト判定部（２２）またはデータ管理部（２７）よりデータを受信した場合（７１１）、同データがリクエスト判定部（２２）からのHTMLファイルまたは外部ファイルに対するGETであるか、データ管理部（２７）からの外部ファイルに対するプリフェッチのリクエストであるかを判定する（３１２）。プリフェッチのリクエストであった場合はそのリクエストを生成し（３１４）、WANコネクション管理部（２４）よりサーバ側プロキシ（１５）に送信する。外部ファイルに対するGETであった場合はプリフェッチフラグを1に設定したうえで（７１２）、WANコネクション管理部（２４）よりサーバ側プロキシ（１５）に送信する（３１３）。

リクエスト判定部（２２）またはデータ管理部（２７）よりリクエストを受信しなかった場合、プリフェッチフラグが1であるかを確認する（７１３）。1であった場合はプリフェッチリクエスト送信から一定時間経過したかどうか調べ（７１４）、一定時間経過していればプリフェッチリクエストを生成し（３１４）、WANコネクション管理部（２４）よりサーバ側プロキシ（１５）に送信する（３１３）。

クライアント側プロキシ（１２）におけるレスポンス解析部（２５）の動作を説明する。レスポンス解析部（２５）は、図7と同様、サーバ側プロキシ（１５）から受信したレスポンスを受信すると、そのレスポンスがウェブページ本体を記述するHTMLファイルであるかを判定する（３３２）。判定結果、HTMLファイルでなければプリフェッチデータである。その場合まずレスポンスのステータスコードを確認し（７１５）、”404”以外であれば図7と同様、レスポンスを展開し（３３４）、データ管理部（２７）へ転送する（３３５）。ステータスコードが”404”であれば、レスポンス解析部（２５）は、プリフェッチフラグを0に設定する（７１６）。それ以外の処理は、図7と同様である。 サーバ側プロキシ（１２）におけるデータ管理部（３７）の動作を説明する。図11と異なる点は、データ管理部（３７）がレスポンスに未取得のファイルが含まれているか否かを判別するステップ（４４８）より後の処理である。データ管理部（３７）は、未取得のファイルが含まれていなかった場合は、ステップ４４１に戻る。

一方、未取得のファイルがあった場合（４４８）、データ管理部（３７）は、プリフェッチリクエスト受信済みフラグを調べ、1でなければ図11の４４９ないし４５２の処理を行う。以下の手順でプリフェッチデータの送信またはプリフェッチリクエストの送信を行う。

プリフェッチリクエスト受信済みフラグが１である場合、データ管理部（３７）は、その時点で取得済みの外部ファイルをレスポンスとして送信する。まず、データ管理部（３７）は、取得済みの外部ファイルを連結してプリフェッチリクエストに対するレスポンスを生成し（４５３）、レスポンス送信部へ転送して（４５４）クライアント側プロキシ（１２）へ送信する。送信が完了するとテーブルのエントリを削除する。なお別途プリフェッチレスポンス送信済みを表すフラグを用いれば、エントリの削除はプリフェッチレスポンスの送信直後ではなく、後にフラグ状態を調べて行ってもよい。

以上の説明が実施例４の説明である。実施例４によると、クライアント側プロキシからの複数の先読みファイルの取得リクエストと、該当の先読みファイルを含むレスポンスあるいは先読みファイルが存在しないことを示す情報を含むレスポンス（７０６）とが対応するので、プロキシ間の通信が不正な通信と判断されない。そして、本実施例では、先読みファイルのデータをクライアント側に提供することが出来、クライアントでウエブページの表示の高速化に寄与することができる。

本発明の第五の実施例では、クライアント側プロキシ（１２）とサーバ側プロキシ（１５）の間の転送において、その関係を逆転し、サーバ側プロキシ（１５）がクライアント側プロキシ（１２）にファイルアップロードのリクエストを行う。同リクエストに対して、クライアント側プロキシ（１２）が成功のレスポンスを送信することにより、正常なHTTP通信とすることができる。これにより、サーバ側プロキシ（１５）がプリフェッチしたファイルを即座にクライアント側プロキシ（１２）に転送し、実施例１のような待ち時間を短縮することができる。

本実施例における通信シーケンスを図18に示す。図18では通信にかかわる、クライアント（１１）、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）、およびサーバ（１６）のシーケンスを示している。

クライアント（１１）がサーバ（１６）上のウェブページにアクセスする際、まずそのウェブページ本体を記述するHTMLファイルにGETというリクエスト（１０１）が発行される。これはクライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWAN（１４）上を転送される（１２１）。

サーバ側プロキシ（１５）はHTMLファイルに対するリクエストを受信すると、サーバ（１６）へさらに転送する（１４１）。前記リクエストを受信したサーバ（１６）は、それに対するレスポンスとしてHTMLファイルをサーバ側プロキシ（１５）へ返送する（１４２）。前記レスポンスはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１２３）、サーバ側プロキシ（１５）はこのHTMLファイルを解析（１６１）することによりウェブページに埋め込まれている外部ファイル一覧を取得する。前記HTMLファイルはさらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１０２）。クライアント（１１）はサーバ側プロキシ（１５）とは別にこのHTMLファイルを解析（１６２）して外部ファイル一覧を取得する。外部ファイル一覧を取得したクライアント（１１）は、その各外部ファイルに対してリクエストを送信する（１０３）。

サーバ側プロキシ（１５）は、作成した外部ファイル一覧中の最初のファイルに対しリクエストを送信し（１４３）、そのレスポンスを得る（１４４）。続いてサーバ側プロキシ（１５）はこのファイルをクライアント側プロキシ（１２）にPUTコマンドで送信する（８０１）。

クライアント側プロキシ（１２）はPUTコマンドを受信すると、それに対するレスポンスとしてステータスコード”201 Created”をサーバ側プロキシ（１５）に送信する（８０２）。また、クライアント側プロキシ（１２）がクライアント（１１）からリクエストを受信すると（１０３）、受け取った外部ファイルをレスポンスとして返す（１０４）。

一方、サーバ側プロキシ（１５）では、次の外部ファイルに対してプリフェッチリクエストをサーバ（１６）に送信する（１４５）。そのレスポンスを受信すると（１４６）、クライアント側プロキシ（１２）にPUTで送信する（８０３）。クライアント側プロキシ（１２）はそれに対するレスポンスを送信し（８０４）、クライアント（１１）からのリクエストを受信すると（１０５）、それに対するレスポンスを送信する（１０６）。

以降の外部ファイルについても同様に転送を行い（１４７、１４８、８０５、８０６、１０７、１０８）、全ての外部ファイルを転送すると終了する。

装置内の構成については実施例１の場合と同様であるので、ここでは省略する。

実施例５のクライアント側プロキシ（１２）のデータ管理部におけるデータ管理テーブル（２８）は、図3のプリフェッチ用ポート番号４３を不要とする点が、実施例１と異なる。

サーバ側プロキシ（１５）のデータ管理部におけるデータ管理テーブル（３８）も図4のプリフェッチ用ポート番号４３を不要とする点が、実施例１と異なる。

クライアント側プロキシ（１２）における各部の動作を以下説明する。なおレスポンス送信部（２６）は実施例１のものと同一であるので、ここでは説明を省略する。

クライアント側プロキシ（１２）におけるリクエスト判定部（２２）の動作を説明する。実施例５では、図5のプリフェッチ指示（３０４）が不要となり、その他は図5と同様である。図18のGetリクエスト（１２１）の送信後、ファイルを取得するためのリクエストは不要となり、PUT file (801)の受信を待機すればよい。

図19は、クライアント側プロキシ（１２）におけるリクエスト送信部（２３）の動作を表すフローチャートである。リクエスト送信部（２３）はリクエスト判定部（２２）よりリクエストを受信した場合（８１１）、同リクエストをそのままWANコネクション管理部（２４）よりサーバ側プロキシ（１５）に送信する（３１３）。リクエスト送信部(23)は、所定の時間内にリクエスト判定部（２２）よりリクエストを受信しなかった場合、データ管理部（２７）よりPUT受信済みが通知されたかどうかを判断する（８１２）。通知された場合はPUTに対するレスポンスを生成し（８１３）、WANコネクション管理部（２４）よりサーバ側プロキシ（１５）に送信する（３１３）。

クライアント側プロキシ（１２）におけるレスポンス解析部（２５）の動作を説明する。実施例５では、図7のプリフェッチデータの展開（３３４）が不要となる。その他は図5と同様である。図18のGetリクエスト（１２１）の送信後、レスポンス解析部（２５）は、Getリクエストに対するレスポンス（１２３）やPUTコマンド（８０１，８０３，８０５）がHTMLファイルであるかを判定し（３３２）、HTMLファイルであればレスポンス送信部（２６）へ転送し、（３３３）。データ管理部（２７）へ転送する（３３５）。

クライアント側プロキシ（１２）におけるデータ管理部（２７）の動作を説明する。本実施例のクライアント側プロキシ（１２）の動作は図8とほぼ同様である。異なる点は、まず、図8の３４３の代わりに、データの受信がクライアントからの外部ファイルに対するリクエストか、サーバ側からのPUT受信であるかを判別する点である。判別結果、クライアントからのリクエストである場合は、データ管理部（２７）は図7の処理344以降の処理を行う。つまり、データ管理部（２７）は、リクエストされた外部ファイルのURLをテーブルに登録されていなければ登録し、同エントリにクライアント（１１）がリクエストに用いたポート番号を登録し（３４６）、リクエスト受信済みフラグ（４６）を設定する（３４７）。

一方、入力データがPUTによるプリフェッチされた外部ファイルであれば、データ管理部（２７）は、図8の348ないし３５０と同様の処理を行う。PUTコマンドに含まれる外部ファイルのエントリに外部ファイルのURLをテーブルとPUT受信の内容を登録する（３４９及び３５０）。その後、図18の８０２、８０４、８０６のように、リクエスト送信部より、PUTに対するレスポンスをサーバ側プロキシ（１５）に送信する。以上の説明が、クライアント側プロキシ（１２）の実施例５における構成及び動作である。

サーバ側プロキシ（１５）におけるデータ管理部（３７）の動作を説明する。。実施例１の図11と同様であるが、一部異なる点について説明する。データ管理部（３７）はレスポンス解析部（３５）よりデータを受信した場合（４４１）、図11と同様の処理を行う。

所定の時間、レスポンス解析部（３５）から入力データがない場合は（８２１）、データ管理部（３７）は、テーブル３８の先頭エントリを選択し（８２２）、該当エントリが未取得の外部ファイルである場合は、サーバ（１６）に対してプリフェッチを行うためプリフェッチリクエストを生成する（４４９）。その後の処理は、図11の４５０ないし４５２と同様である。

一方、該当エントリが取得済みであった場合は、クライアント側プロキシ（１２）へ送るためのPUTリクエストを生成し、レスポンス送信部（３６）へ転送して（４５４）クライアント側プロキシ（１２）へ送信する。送信が完了するとテーブル３８の該当エントリを削除する。なお別途プリフェッチレスポンス送信済みを表すフラグを用いれば、エントリの削除はプリフェッチレスポンスの送信直後ではなく、後にフラグ状態を調べて行ってもよい。

また、クライアント側プロキシ（１２）にて未取得の外部ファイルをクライアント（１１）からリクエストされた場合、そのリクエストをサーバ側プロキシ（１５）に転送してもよい。このリクエストを受信したサーバ側プロキシ（１５）は、該当する外部ファイルをPUTにより送信済みであれば、前記リクエストに対して”404 Not Found”のレスポンスを送信する。クライアント側プロキシ（１２）には前記PUTリクエストが受信され、ファイルを取得することができる。一方サーバ側プロキシ（１５）が該当する外部ファイルを送信していなければ、クライアント側プロキシ（１２）が転送したリクエストに対するレスポンスとして外部ファイルを送信する。

以上の説明が、サーバ側プロキシ（１５）の実施例５における構成及び動作である。実施例５では、サーバプロキシ（１５）からの先読み対象ファイルを含むPUTリクエストと、クライアント側プロキシからのPUTリクエストに対する２０１Createdとが対応することで、プロキシ間の通信が不正な通信と判断されず、先読みファイルのデータをクライアント側に提供することが出来、クライアントでウエブページの表示の高速化に寄与することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。たとえば、 クライアントとサーバの間のクライアント側にクライアント側プロキシを設置し、サーバ側にサーバ側プロキシを設置したネットワークであって、
前記クライアント側プロキシおよび前記サーバ側プロキシが前記クライアントおよび前記サーバの間の通信を中継する方法であって、
前記クライアントと前記サーバの間で前記クライアントからの１つ以上の外部ファイルを参照するドキュメント取得のリクエストに対して前記サーバがレスポンスを送信する形式の通信方法において、
前記クライアントの送信した第一のリクエストを契機として、前記クライアント側プロキシが、前記第一のリクエストをサーバ側プロキシに中継するとともに、前記クライアントからの第二のリクエストを待たずに、前記サーバに対して前記ドキュメントが参照する１つ以上の外部ファイルを取得するための１つ以上のプリフェッチリクエストを送信し、
前記サーバ側プロキシは前記ドキュメントを取得して解析し、前記１つ以上の外部ファイルを前記サーバからプリフェッチし、
前記プリフェッチした前記１つ以上の外部ファイルを、前記プリフェッチリクエストに対するレスポンスとして、クライアント側プロキシへ、前記プリフェッチリクエストの数と前記プリフェッチリクエストに対するレスポンスの数が一致するよう送信する、という態様である。

例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１１ クライアント
１２ クライアント側プロキシ
１３ クライアント側LAN
１４ WAN
１５ サーバ側プロキシ
１６ サーバ
１７ サーバ側LAN
２１ クライアント側プロキシにおけるLANコネクション管理部
２２ クライアント側プロキシにおけるリクエスト判定部
２３ クライアント側プロキシにおけるリクエスト送信部
２４ クライアント側プロキシにおけるWANコネクション管理部
２５ クライアント側プロキシにおけるレスポンス解析部
２６ クライアント側プロキシにおけるレスポンス送信部
２７ クライアント側プロキシにおけるデータ管理部
３１ サーバ側プロキシにおけるLANコネクション管理部
３２ サーバ側プロキシにおけるリクエスト判定部
３３ サーバ側プロキシにおけるリクエスト送信部
３４ サーバ側プロキシにおけるWANコネクション管理部
３５ サーバ側プロキシにおけるレスポンス解析部
３６ サーバ側プロキシにおけるレスポンス送信部
３７ サーバ側プロキシにおけるデータ管理部

Claims (15)

1. クライアントに接続される第一の通信装置及びファイルを管理するサーバに接続される第二の通信装置により前記クライアントと前記サーバとの通信を中継する通信方法であって、
   前記第一の通信装置で、前記クライアントから受信され、前記サーバを宛先とする前記ファイルの取得リクエストを、前記第二の通信装置に送信し、
   前記第二の通信装置で、前記ファイルの取得リクエストに基づいて取得されるファイルを前記サーバから取得し、
   前記ファイルで参照される他の関連ファイルの先読み要求を送信し
   前記先読み要求に対する応答を受信し、
   前記応答に含まれる関連ファイルを、前記第一の通信装置から送信される通知に対応させて、前記関連ファイルを前記第一の通信装置に送信し、
   前記第一の通信装置で、前記関連ファイルを前記ファイルと対応付けて保持し、
   前記クライアントからの前記関連ファイルの参照要求に応じて、前記関連ファイルを前記クライアントに送信する、
   ことを特徴とする通信方法。
2. 請求項1記載の通信方法であって、
   前記第二の通信装置は、
   前記ファイルで参照される他の関連ファイルが複数ある場合、2以上のファイルを集約して前記第一の通信装置に送信する、ことを特徴とする通信方法。
3. 請求項１または２記載の通信方法であって、
   前記第二の通信装置からの前記他の関連ファイルの送信は、前記取得リクエスト数に対応する、ことを特徴とする通信方法。
4. 請求項１ないし３記載の通信方法であって、
   前記通知は、関連ファイルの取得リクエストであって、
   前記通信は、HTTP(Hyper Text Transport Protocol)に従って行い、
   前記ファイルは、ＨＴＭＬ（Hyper Text Markup Language）で前記クライアントでウエブページを表示するための情報と、前記他のファイルのURLを示すリンクとを含む、ことを特徴とする通信方法。
5. 請求項１記載の通信方法であって、
   前記通知は、関連ファイルの取得リクエストであって、
   前記取得リクエストは、関連ファイルの属性を指定する情報を含み、
   前記第二の通信装置は、
   前記属性に対応する前記他のファイルを前記第一の通信装置に送信する、ことを特徴とする通信方法。
6. 請求項5記載の通信方法であって、
   前記第一の通信装置で、
   前記属性は優先度と対応付けられ、前記優先度に従って、前記取得リクエストを順次送信し、
   前記第二の通信装置で、前記優先度と前記属性とにしたがって、前記サーバから取得する関連ファイルを順次送信する、ことを特徴とする通信方法。
7. 請求項６記載の通信方法であって、
   前記関連ファイルのうち、前記ファイルを前記クライアントで表示させるために用いる関連ファイルを取得するための取得リクエストを他の関連ファイルよりも優先して送信する、ことを特徴とする通信方法。
8. 請求項７記載の通信方法であって、前記ファイルを前記クライアントで表示させるために用いる関連ファイルは、CSS（Cascading Style Sheet）である、ことを特徴とする通信方法。
9. 請求項1ないし３記載の通信方法であって、
   前記通知は、関連ファイルの取得リクエストであって、
   前記通信は、HTTP(Hyper Text Transport Protocol)に従って行い、
   前記ファイルは、ＨＴＭＬ（Hyper Text Markup Language）で前記クライアントでウエブページを表示するための情報と、前記他の関連ファイルのURLを示すリンクとを含み、
   前記第二の通信装置で、前記関連ファイルの取得リクエストに対応させて、送るべき他のファイルがないことを示す情報を送信し、
   前記第一の通信装置で、前記関連ファイルの取得リクエストを所定の時間ごとに送信し、
   前記情報の受信に応じて、他の関連ファイルの取得リクエストの送信処理を停止する、ことを特徴とする通信方法。
10. 請求項１記載の通信方法であって、
    前記通知は、関連ファイルの取得リクエストであって、
    前記ファイルは、ＨＴＭＬ（Hyper Text Markup Language）で前記クライアントでウエブページを表示するための情報と、前記他の関連ファイルのURLを示すリンクとを含み、
    前記第二の通信装置で、前記関連ファイルの取得リクエストの一に対応させる応答を分割し、分割されたメッセージの一は、最後のメッセージであることを示す情報を含む、ことを特徴とする通信方法。。
11. 請求項１０記載の通信方法であって、、
    前記分割されたメッセージのうち最初のメッセージは、HTTPヘッダを含むが、それ以外のメッセージは、HTTPヘッダを含まず、前記第二の通信装置で、所定の時間ごとに前記分割されたメッセージを送信する、ことを特徴とする通信方法。
12. 請求項1ないし３記載の通信方法であって、
    前記通信は、HTTP(Hyper Text Transport Protocol)に従って行い、前記通知は、関連ファイルの受領通知であって、前記ファイルは、ＨＴＭＬ（Hyper Text Markup Language）で前記クライアントでウエブページを表示するための情報と、前記他の関連ファイルのURLを示すリンクとを含み、
    前記第二の通信装置で、前記関連ファイルをアップロードリクエストとして前記第一の通信装置に送信し、
    前記第一の通信装置で、前記アップロードリクエストに対応させて前記受領通知を前記第二の通信装置に送信する、ことを特徴とする通信方法。
13. 請求項１ないし１２記載の通信方法であって、
    前記第一の通信装置で、前記参照要求が、未取得の関連ファイルに対する要求である場合、
    前記未取得の関連ファイルに対するリクエストを前記第二の通信装置に送信し、
    前記第二の通信装置で、前記関連ファイルに対するリクエストを他の前記関連ファイルの送信処理より優先的に処理する通信方法。
14. クライアントに接続され、ファイルを管理するサーバに接続される第二の通信装置を介して前記クライアントと前記サーバとの通信を中継する第一の通信装置であって、
    前記クライアントから受信され、前記サーバを宛先とする前記ファイルの取得リクエストを前記第二の通信装置に転送する転送処理部と、
    前記第二の通信装置で実行される、先読み処理により取得される、前記ファイルで参照される関連ファイルを、前記第一の通信装置から送信される通知に対応させて、前記関連ファイルを受信する関連ファイル受信部と、
    前記第一の通信装置で、前記関連ファイルを前記ファイルと対応付けて保持する保持部と、
    前記クライアントからの前記関連ファイルの参照要求に応じて、前記関連ファイルを前記クライアントに送信する送信部とを有し、
    前記通信は、HTTP(Hyper Text Transport Protocol)に従って行い、前記ファイルは、ＨＴＭＬ（Hyper Text Markup Language）で前記クライアントでウエブページを表示するための情報と、前記他のファイルのURLを示すリンクとを含む、ことを特徴とする第一の通信装置。
15. クライアントに接続される第一の通信装置を介して、ファイルを管理するサーバに接続され、前記クライアントと前記サーバとの通信を中継する第二の通信装置であって、
    前記第一の通信装置で転送される前記クライアントからの前記サーバを宛先とする前記ファイルの取得リクエストに基づいて取得されるファイルを前記サーバから取得するファイル取得部と、
    前記ファイルで参照される他の関連ファイルの先読み処理を実行し、関連ファイルを取得する先読み処理部と、
    前記関連ファイルを、前記第一の通信装置から送信される通知に対応させて、前記関連ファイルを前記第一の通信装置に送信する送信処理部と、を有し、
    前記通信は、HTTP(Hyper Text Transport Protocol)に従って行い、前記ファイルは、ＨＴＭＬ（Hyper Text Markup Language）で前記クライアントでウエブページを表示するための情報と、前記他のファイルのURLを示すリンクとを含む、ことを特徴とする第二の通信装置。

Images