JP2015091019A - 中継装置及びデータ転送方法 - Google Patents

Abstract

【課題】ユーザ端末に中継装置の存在及びサービス経路の切り替えを意識させることなく、また、ネットワークを大幅に変更することなく、通信経路の切り替えを実現する。
【解決手段】端末とサーバとの間のデータを転送する中継装置であって、中継装置は、第１のネットワークに確立されたＴＣＰコネクションを用いて端末と通信し、第２のネットワークに含まれる一つの通信経路上に確立されたＴＣＰコネクションを用いてサーバと通信し、中継装置は、ＴＣＰコネクションを用いて送受信されるパケットを管理するＴＣＰ管理部と、リクエストパケットの解析の結果に基づいて第２のネットワークの通信経路を切り替えるか否かを判定する判定部と、新たな通信経路上に新たなＴＣＰコネクションを確立し、リクエストパケットをサーバに送信するリクエスト送信部と、新たなＴＣＰコネクションを用いてパケットを端末に転送するデータ中継部と、を備える。
【選択図】図１

Description

本発明はパケットの中継装置及びデータ転送方法に関する。

現在、通信事業者は、ＡＤＳＬ、ＦＴＴＨ、及び無線網などのアクセス回線を介してユーザ端末をインターネットに接続するインターネット接続サービスを提供している。インターネットのコンテンツは、コンテンツ事業者によって提供されており、動画配信など広帯域なコンテンツが増加しているため、これらのトラフィックが通信事業者の通信機器の帯域を圧迫している。

通信事業者の提供するインターネット接続サービスはベストエフォートであるため、広帯域なコンテンツのトラフィックによって、他のユーザトラフィックの廃棄又は遅延などの影響を及ぼす可能性がある。このため、通信事業者はトラフィック増加に対応するために設備投資が必要である。しかし、コンテンツにより収益を得るコンテンツ事業と異なり、通信事業者のインターネット接続サービスは、主に定額制又は上限金額が設定される定額従量制で提供されているため、通信事業者の設備投資には限界がある。

従って、通信事業者は単純な回線の増強ではなく、動画などのデータを特定してオフロード用のサービス経路（通信経路）に振り分けることによって、他のユーザトラフィックに影響を与えないトラフィックオフロードの検討が進められるものと考えられる。また、アプリケーション又はデータの種類によって、通常経路、広帯域経路、及び低遅延経路など特徴の異なるサービス経路を切り替え、使用するサービス網ごとに異なる料金を徴収する新たな課金方法の検討も進められるものと考えられる。

従来、アプリケーション及びデータの種類を特定するために、レイヤ４の情報であるポート番号が用いられている。しかし、Ｗｅｂプログラミングの普及によって、動画を含む多くの通信がＨＴＴＰ上で転送されおり、ポート番号ではアプリケーション及びデータの種類を十分に特定できなくなりつつある。そこで、ＨＴＴＰ（レイヤ７）上の情報を用いてアプリケーション及びデータの種類の識別し、通信経路切り替える技術が必要である。

ＨＴＴＰ上の情報に基づいてアプリケーション及びデータの種類の識別する技術として、プロキシサーバを用いる技術が知られている。プロキシサーバは、コンテンツフィルタリング、ユーザ端末のＩＰアドレスの隠ぺい、並びに、Ｗｅｂサーバ及び通信回線に対する負荷の低減を行う中継装置である。ユーザ端末は、ユーザ端末自身とプロキシサーバとの間にＴＣＰコネクションを確立し、プロキシサーバに対してコンテンツを要求する。プロキシサーバは、プロキシサーバ自身とＷｅｂサーバとの間にＴＣＰコネクションを確立し、ユーザ端末の代わりにＷｅｂサーバにコンテンツを要求する。

プロキシサーバを用いるものと類似した技術に透過プロキシサーバを用いる技術が知られている。透過プロキシサーバを用いた通信では、ユーザ端末は透過プロキシサーバ宛のパケットではなく、Ｗｅｂサーバ宛のパケットを送信する。透過プロキシサーバは、プロキシサーバと同様の機能を有し、ユーザ端末からＷｅｂサーバに対するＨＴＴＰ通信（宛先ポート番号８０）を監視し、ＨＴＴＰ通信のパケットを受信した場合、送信元ＩＰアドレスを透過プロキシサーバのＩＰアドレスで置き換え、Ｗｅｂサーバに当該パケットを送信する。また、透過プロキシサーバは、Ｗｅｂサーバからのパケットを受信した場合、宛先ＩＰアドレスをユーザ端末のＩＰアドレスに置き換え、ユーザ端末に当該パケットを送信する。

前述した動作によって、ユーザ端末とＷｅｂサーバとの間では直接通信は行われていないにも関わらず、ユーザ端末は、Ｗｅｂサーバとの間でコネクションを確立し、Ｗｅｂサーバからコンテンツを直接取得しているように認識する。

プロキシサーバ及び透過プロキシサーバは、ＨＴＴＰ上の通信を監視することによってアプリケーション及びデータの種類を識別する機能を有するが、サービス経路の切り替える機能は有さない。

ＨＴＴＰ上の通信に基づいてアプリケーション及びデータの種類を識別し、サービス経路を切り替える技術として特許文献１に記載の技術がある。特許文献１には、「送信元端末からのデータを中継装置で終端してコンテンツ内容をネットワークコントローラに渡し、ネットワークコントローラは中継に必要となるフロー情報を割り当てるとともに、スイッチに対してフロー転送指示を設定する。割り当てたフロー情報は中継装置に通知され、中継装置は指定されたフロー情報を用いて宛先端末までの通信フローを設定し、送信元端末から宛先端末までのデータを中継する」ことが記載されている。

国際公開第２０１１／０３７１０５号

特許文献１では、ユーザ端末は、Ｗｅｂサーバではなく中継装置との間にＴＣＰコネクションを確立し、当該ＴＣＰコネクションを用いて中継装置にコンテンツを要求する。このため、ユーザは、予め、中継装置のＩＰアドレスを知っている必要があるという課題がある。また、ユーザ端末が中継装置と通信し、中継装置に対してコンテンツを要求するようにユーザ端末を変更する必要があるという課題がある。

また、特許文献１のネットワークは自律分散ではなく、コントローラによって集中管理されるネットワークであるため、ネットワークに対するコントローラ、及び当該コントローラと通信するスイッチの導入が必要であるという課題がある。通信事業者のインターネット接続サービスはＩＰネットワーク等の大規模なネットワークを用いて提供されるため、特許文献１を適用する場合には装置の大幅な変更が必要となる。

一方、ユーザ端末が直接Ｗｅｂサーバにコンテンツを要求し、通信の途中でサービス経路を切り替える方法として、複数のネットワークインタフェースを持つ透過プロキシサーバを用いる切替方法が考えられる。透過プロキシサーバが異なるＩＰアドレスを割り当てられる複数のネットワークインタフェースを持つ場合、ユーザ端末から受信したパケットの送信元ＩＰアドレスを透過プロキシサーバのＩＰアドレスに変更することによって、Ｗｅｂサーバが透過プロキシサーバに送信するパケットの宛先ＩＰアドレスを変更することができる。これによって、Ｗｅｂサーバから透過プロキシサーバへの通信経路を切り替えることができる。また、透過プロキシサーバがＷｅｂサーバへのパケットの送信に用いるネットワークインタフェースを変更することによって、透過プロキシサーバからＷｅｂサーバへのサービス経路を切り替えることができる。

しかし、前述した方法は透過プロキシサーバとＷｅｂサーバとの間でＴＣＰコネクションが確立されるため、ＴＣＰコネクションの確立時に置き換えるＩＰアドレスを選択しなければならず、ＨＴＴＰ上のアプリケーション及びデータの種類の識別が可能となるＨＴＴＰリクエストの解析後に置き換えるＩＰアドレスを変更することができない。つまり、ＨＴＴＰ上のアプリケーション及びデータの種類に基づいて、サービス経路を切り替えることができないという課題がある。

従って、本発明は、ユーザ端末の構成及び設定を変更することなく、かつ、サービス経路の切り替えを意識させることなく、また、通信事業者のＩＰネットワークに大幅な変更をすることなく、ＨＴＴＰリクエストの解析結果に基づいて、サービス経路を切り替える中継装置を提供することを目的とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、ＴＣＰを利用して通信するアプリケーションが稼働する端末と、前記アプリケーションが要求するデータを送信するサーバとの間で送受信するデータを転送する中継装置であって、前記中継装置は、プロセッサ、前記プロセッサに接続されるメモリ、及び前記プロセッサに接続され、他の装置と接続するための複数のネットワークインタフェースを備え、前記中継装置は、第１のネットワークを介して前記端末と接続し、第２のネットワークに含まれる複数の通信経路を介して前記サーバと接続し、前記中継装置は、前記第１のネットワーク及び前記第２のネットワークに含まれる一つの前記通信経路を介して前記端末と前記サーバとの間に確立されたＴＣＰコネクションを用いて送受信されるパケットを監視するＴＣＰ管理部と、前記ＴＣＰ管理部によって、前記端末上で稼働する前記アプリケーションが前記サーバにデータの送信を要求するリクエストパケットの受信が検知された場合、前記リクエストパケットを解析し、前記解析の結果に基づいて前記リクエストパケットを送信する前記第２のネットワークの通信経路を切り替えるか否かを判定する判定部と、前記判定部によって新たな前記第２のネットワークの通信経路に切り替えると判定された場合、新たな通信経路上に前記中継装置及び前記サーバが通信するための新たなＴＣＰコネクションを確立し、前記新たなＴＣＰコネクションを用いて前記リクエストパケットを前記サーバに送信するリクエスト送信部と、前記新たなＴＣＰコネクションを用いて、前記アプリケーションが要求するデータを含むデータ格納パケットを前記端末に転送するデータ中継部と、を備えることを特徴とする。

本発明によれば、端末に中継装置の存在及び通信経路の切り替えを意識させることなく、また、通信事業者のネットワークに大幅な変更をすることなく、リクエストの解析結果に基づいて通信経路を切り替えることができる。

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明の実施例における通信システムの構成例を示す説明図である。 本発明の実施例における中継装置のハードウェア構成及びソフトウェア構成を説明するブロック図である。 本発明の実施例のコネクション管理テーブルの構成例を示す説明図である。 本発明の実施例のルールテーブルの構成例を示す説明図である。 本発明の実施例の代理応答テーブルの構成例を示す説明図である。 本発明の実施例におけるＡＣＫ受信通知又はＦＩＮ受信通知の通知内容の一例を示す説明図である。 本発明の実施例におけるＨＴＴＰメッセージの一例を示す説明図である。 本発明の実施例におけるＨＴＴＰメッセージの一例を示す説明図である。 本発明の実施例におけるＨＴＴＰメッセージの一例を示す説明図である。 本発明の実施例の監視部が実行する監視処理の詳細を説明するフローチャートである。 本発明の実施例の監視部が実行するユーザ側代理応答処理を説明するフローチャートである。 本発明の実施例のルール判定部が実行するルール判定処理を説明するフローチャートである。 本発明の実施例のＨＴＴＰリクエスト送信部が実行するＨＴＴＰリクエスト送信処理を説明するフローチャートである。 本発明の実施例のデータ中継部が実行するデータ中継処理を説明するフローチャートである。 本発明の実施例の応答部が実行する応答処理を説明するフローチャートである。 本発明の実施例の通信システムにおけるサービス経路が切り替えられない場合の通信の流れを示すシーケンス図である。 本発明の実施例の通信システムにおけるサービス経路が切り替えられない場合の通信の流れを示すシーケンス図である。 本発明の実施例の通信システムにおけるサービス経路が切り替えられる場合の通信の流れを示すシーケンス図である。 本発明の実施例の通信システムにおけるサービス経路が切り替えられる場合の通信の流れを示すシーケンス図である。 本発明の実施例の通信システムにおけるサービス経路が切り替えられない場合の通信の流れを示すシーケンス図である。 本発明の実施例の通信システムにおけるサービス経路が切り替えられる場合の通信の流れを示すシーケンス図である。

以下、実施例を図面を参照して詳細に説明する。

図１は、本発明の実施例における通信システムの構成例を示す説明図である。

本実施例の通信システムは、複数のユーザ端末１、複数のルータ２、中継装置３、複数のサービス経路４、インターネット５、及び複数のＷｅｂサーバ６から構成される。

中継装置３は、パケットの中継処理を実行する装置であり、ルータ２−１と、サービス経路４−１及びサービス経路４−２と接続される。中継装置３は、サービス経路４−１及びサービス経路４−２のそれぞれに接続するネットワークインタフェースを有し、また、後述するようにルールテーブル（Ｔ２）（図２参照）を保持する。ルールテーブル（Ｔ２）（図２参照）には、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）上の通信に基づいてアプリケーション及びデータを識別し、サービス経路４−１からサービス経路４−２に切り替えるための情報が格納される。

サービス経路４は、通信事業者によって提供される通信経路である。なお、サービス経路４は、同一の通信事業者によって提供されてもよいし、異なる通信事業者によって提供されてもよい。本実施例では、通常の通信はサービス経路４−１を介して行われ、後述するルールに一致する通信はサービス経路４−２を介して行われる。

なお、サービス経路４を切り替えるためのルールは、通信事業者が予め設定しておいてもよいし、ルールテーブルを保持するデータサーバに問い合わせてもよい。また、ユーザが、ユーザ端末１が使用するサービス経路４を選択するためルールを設定してもよい。

ユーザ端末１は、ルータ２−１を介して中継装置３と接続される。ユーザ端末１は、プロセッサ（図示省略）、メモリ（図示省略）、及びインタフェース（図示省略）等のハードウェアを備える。ユーザ端末１上では、ＴＣＰを用いて通信を行うアプリケーション（図示省略）が稼働する。本実施例では、ユーザ端末１−１からユーザ端末１−ｎのｎ個存在する。また、ユーザ端末１−ｎにはＩＰアドレス「１０．０．０．ｎ」が予め設定される。

なお、本発明は、ユーザ端末１と中継装置３との間の接続方式には限定されず、ユーザ端末１と中継装置３との間は有線又は無線のいずれで接続されてもよい。また、ユーザ端末１と中継装置３との間の少なくとも一部が無線で接続されてもよい。

ルータ２−２は、複数のサービス経路４とインターネット５とを接続し、ユーザ端末１宛てのパケットをサービス経路４−１を介して転送するように予め設定される。

Ｗｅｂサーバ６は、ユーザ端末１の要求に応じて様々なコンテンツを配信する計算機であり、インターネット５及びルータ２−２を介して中継装置３に接続される。Ｗｅｂサーバ６は、プロセッサ（図示省略）、メモリ（図示省略）、記憶装置（図示省略）、及びインタフェース（図示省略）等のハードウェアを備える。なお、Ｗｅｂサーバ６は、ストレージシステムと接続されてもよく、この場合、Ｗｅｂサーバ６は記憶装置（図示省略）を備えていなくてもよい。本実施例では、Ｗｅｂサーバ６−１からＷｅｂサーバ６−ｍのｍ個の存在し、それぞれが個別のドメインを持つ。例えば、Ｗｅｂサーバ６−ｍにはＩＰアドレスとして「１０．０．１．ｍ」、ドメインとして「ｓｅｒｖｅｒｍ．ｃｏｍ」が予め設定される。なお、Ｗｅｂサーバ６によって配信されるコンテンツには、テキスト情報、画像、及び動画などが含まれる。

ここで、本発明の概要について説明する。

本実施例の通信システムにおいて、ユーザ端末１がＨＴＴＰを用いてＷｅｂサーバ６の保持するコンテンツを要求する場合、ユーザ端末１はＷｅｂサーバ６との間で３ウェイハンドシェイクと呼ばれるＴＣＰコネクションを確立するための通信を行う。

中継装置３は、ハンドシェイクの通信を監視し、後述するコネクション管理テーブル（Ｔ１）（図２参照）にコネクション情報を登録する。ＴＣＰコネクションの確立中、中継装置３は、ユーザ端末１から受信したパケットをサービス経路４−１経由でＷｅｂサーバ６に転送し、また、Ｗｅｂサーバ６から受信したパケットをユーザ端末１に転送する。このとき、中継装置３は、パケットの監視のみを行い、当該パケットの操作等の特別な処理は実行しない。

ユーザ端末１とＷｅｂサーバ６との間でＴＣＰコネクションが確立されると、ユーザ端末１は、Ｗｅｂサーバ６にＨＴＴＰリクエストを含むパケットを送信する。以下の説明において、ＨＴＴＰリクエストを含むパケットをＨＴＴＰリクエストパケットとも記載する。なお、ユーザ端末１とＷｅｂサーバ６との間の通信では、ＴＣＰコネクションの確立時に用いられるＡＣＫ番号及びシーケンス番号が引き続き用いられる。

中継装置３は、ＨＴＴＰリクエストパケットを受信すると、ルールテーブル（Ｔ２）（図２参照）に格納される条件を参照して、サービス経路４−１及びサービス経路４−２のどちらを介した通信を行うかを判定する。

ＨＴＴＰリクエストが条件に該当しない場合、中継装置３は、サービス経路４−１を介した通信を行う。中継装置３は、コネクション管理テーブル（Ｔ１）からコネクション情報を削除し、サービス経路４−１を介してＷｅｂサーバ６にＨＴＴＰリクエストパケットを転送する。コネクション管理テーブル（Ｔ１）には、ＨＴＴＰリクエストパケットの送信後に受信するパケットのコネクション情報が存在しないため、中継装置３はＷｅｂサーバ６から受信したパケットをユーザ端末１に転送し、ユーザ端末１から受信したパケットをサービス経路４−１を介してＷｅｂサーバ６に転送する。

一方、ＨＴＴＰリクエストが条件に該当する場合、中継装置３は、サービス経路４−２を介した通信の対象として、代理応答テーブル（Ｔ３）（図２参照）に代理応答情報を登録する。その後、中継装置３は、ＨＴＴＰリクエストパケットのヘッダ情報に基づいて、Ｗｅｂサーバ６宛てのＲＳＴパケットを生成し、サービス経路４−１を介してＷｅｂサーバ６に当該ＲＳＴパケットを送信する。これによって、中継装置３とＷｅｂサーバ６との間のＴＣＰコネクションが切断される。ただし、中継装置３は、ユーザ端末１に対してＲＳＴパケットは送信しない。これによって、ユーザ端末１と中継装置３との間のＴＣＰコネクションを維持させる。

そして、中継装置３は、中継装置３とＷｅｂサーバ６との間を接続するサービス経路４−２上に新たなＴＣＰコネクションを確立する。中継装置３は、代理応答情報のＷｅｂサーバ側情報（Ｔ３４）（図５参照）に基づいて、ユーザ端末１から受信したＨＴＴＰリクエストパケットの送信元ＩＰアドレス、送信元ポート番号、シーケンス番号、及びＡＣＫ番号を書き換えて、サービス経路４−２を介して当該ＨＴＴＰリクエストパケットをＷｅｂサーバ６に転送する。また、中継装置３は、Ｗｅｂサーバ６からＡＣＫパケットを受信すると、代理応答情報のユーザ端末側情報（Ｔ３３）（図５参照）に基づいて、当該ＡＣＫパケットの宛先ＩＰアドレス、宛先ポート番号、シーケンス番号、及びＡＣＫ番号を書き換えて、当該ＡＣＫパケットをユーザ端末１に転送する。

その後、Ｗｅｂサーバ６からのコンテンツの配信が完了し、ユーザ端末１によってＴＣＰコネクションが切断されるまでの間、中継装置３は、サービス経路４−２を介したユーザ端末１とＷｅｂサーバ６との間の通信を制御する。

具体的には、中継装置３は、Ｗｅｂサーバ６からパケットを受信した場合、代理応答情報のユーザ端末側情報（Ｔ３３）に基づいて、受信したパケットの宛先ＩＰアドレス、宛先ポート番号、シーケンス番号、及びＡＣＫ番号を書き換えて、ユーザ端末１に当該パケットを転送する。また、中継装置３は、ユーザ端末１からパケットを受信した場合、代理応答情報のＷｅｂサーバ側情報（Ｔ３４）に基づいて受信したパケットの送信元ＩＰアドレス、送信元ポート番号、シーケンス番号、及びＡＣＫ番号を書き換えて、サービス経路４−２を介してＷｅｂサーバ６に当該パケットを転送する。

ユーザ端末１によってＴＣＰコネクションが切断された後、中継装置３は、コネクション管理テーブル（Ｔ１）からコネクション情報を削除し、また、代理応答テーブル３２３から代理応答情報を削除する。

本実施例では、Ｗｅｂサーバ６と中継装置３との間の通信、中継装置３とユーザ端末１との間の通信において同期をとり、中継装置３は、ユーザ端末１からＡＣＫパケットを受信して後にＷｅｂサーバ６にＡＣＫパケットを送信する。ただし、本発明はこれに限定されず、中継装置３は、同期をとらず、Ｗｅｂサーバ６からコンテンツを受信し次第、Ｗｅｂサーバ６にＡＣＫパケットを送信してもよい。これによって、Ｗｅｂサーバ６へのＡＣＫパケットが早く到着するため、コンテンツの転送時間が短くなるという効果がある。この場合、中継装置３は、Ｗｅｂサーバ６から受信したパケットをユーザ端末１に送信するまでの間、当該パケットをパケット格納部３３に格納してもよい。

また、本実施例では、中継装置３は、ＴＣＰコネクションの切断時におけるシーケンスでも同様に同期をとるが、本発明はこれに限定されない。中継装置３は、同期をとらず、Ｗｅｂサーバ６からＦＩＮパケットを受信し次第、Ｗｅｂサーバ６にＡＣＫパケット及びＦＩＮパケットを送信し、ユーザ端末１からＦＩＮパケットを受信し次第、ユーザ端末１にＡＣＫパケットを送信してもよい。これによって、Ｗｅｂサーバ６に対してはＡＣＫパケット及びＦＩＮパケットが早く到着し、また、ユーザ端末１に対してＡＣＫパケットが早く到着するため、ＴＣＰコネクションの確立時間が短くなり、ＴＣＰコネクションを維持するための資源を早く解放できるという効果がある。

図２は、本発明の実施例における中継装置３のハードウェア構成及びソフトウェア構成を説明するブロック図である。

中継装置３は、プロセッサ３１、テーブル格納部３２、パケット格納部３３、インタフェース部３４、及び命令格納部３５を有する。

プロセッサ３１は、命令格納部３５に格納されているプログラムを読み出し、当該プログラムを実行する。これによって、中継装置３が備える機能を実現することができる。

テーブル格納部３２は、処理に用いる各種情報を格納する。テーブル格納部３２は、例えば、ＤＲＡＭ等のメモリを用いて実現できる。本実施例のテーブル格納部３２は、コネクション管理テーブル（Ｔ１）、ルールテーブル（Ｔ２）、及び代理応答テーブル（Ｔ３）の三つのテーブルを格納する。

コネクション管理テーブル（Ｔ１）は、ユーザ端末１とＷｅｂサーバ６との間の接続状態に関する情報を格納する。コネクション管理テーブル（Ｔ１）の詳細は図３を用いて後述する。ルールテーブル（Ｔ２）は、サービス経路４−１からサービス経路４−２に切り替えるための情報を格納する。ルールテーブル（Ｔ２）の詳細は図４を用いて後述する。代理応答テーブル（Ｔ３）は、サービス経路４−２を介して通信が行われる場合における、パケットの転送に必要な情報を格納する。代理応答テーブル（Ｔ３）の詳細は図５を用いて後述する。

本実施例では、ルールテーブル（Ｔ２）は、テーブル格納部３２に予め格納されているものとするが、本発明はこれに限定されない。例えば、外部のデータベースがルールテーブル（Ｔ２）を保持し、中継装置３が外部のデータベースから取得してもよい。

パケット格納部３３は、ＨＴＴＰリクエストが複数のパケットに分割される場合に、当該分割されたＨＴＴＰリクエストを含むＨＴＴＰリクエストパケットのコピーを格納する。パケット格納部３３は、例えば、ＤＲＡＭ等のメモリを用いて実現できる。

インタフェース部３４は、外部の装置又はネットワークと接続するインタフェースを複数有する。本実施例のインタフェース部３４は、ユーザ側インタフェース３４１、サービス１側インタフェース３４２、及びサービス２側インタフェース３４３を有する。

ユーザ側インタフェース３４１は、ユーザ端末１が接続されるルータ２−１と接続するためのインタフェースである。サービス１側インタフェース３４２は、サービス経路４−１を介してＷｅｂサーバ６と接続するためのインタフェースである。本実施例では、サービス１側インタフェース３４２にはＩＰアドレス「１０．０．２．１」が設定される。また、サービス２側インタフェース３４３は、サービス経路４−２を介してＷｅｂサーバ６と接続するためのインタフェースである。本実施例では、サービス２側インタフェース３４３にはＩＰアドレス「１０．０．２．２」が設定される。

命令格納部３５は、プロセッサ３１によって実行されるプログラムを格納する。命令格納部３５は、ＤＲＡＭ等のメモリを用いて実現できる。本実施例の命令格納部３５は、ＴＣＰ管理部３５１、ルール判定部３５４、ＨＴＴＰリクエスト送信部３５５、及びデータ中継部３５６を実現するプログラムを格納する。なお、命令格納部３５には、パケットの送受信を制御する制御部も格納されるが公知のものであるため省略している。

ＴＣＰ管理部３５１は、ＴＣＰコネクションの監視、及びＴＣＰコネクションを介したＨＴＴＰ上のアプリケーション及びデータの種類等、ＴＣＰ上のＨＴＴＰを用いた通信を管理する。ＴＣＰ管理部３５１は、複数のプログラムモジュールから構成される。具体的には、ＴＣＰ管理部３５１は、監視部３５２及び応答部３５３を含む。

監視部３５２は、ユーザ側インタフェース３４１から受信したパケットに対する処理を実行する。監視部３５２が実行する処理の詳細は、図８、図９を用いて後述する。応答部３５３は、サービス１側インタフェース３４２から受信したパケットに対する処理を実行する。応答部３５３が実行する処理の詳細は、図１３を用いて後述する。

ルール判定部３５４は、サービス経路４−１からサービス経路４−２に切り替えるか否かを判定する。ルール判定部３５４が実行する処理の詳細は、図１０を用いて後述する。ＨＴＴＰリクエスト送信部３５５は、ルールに一致するＨＴＴＰリクエストを受信した場合、サービス経路４−２を介した通信を行うために、新たなＴＣＰコネクションを確立する。ＨＴＴＰリクエスト送信部３５５が実行する処理の詳細は、図１１を用いて後述する。データ中継部３５６は、サービス経路４−２を介した通信時に、ユーザ端末１とＷｅｂサーバ６との間で送受信されるパケットのＩＰアドレス等を書き換えて、当該パケットを転送する。データ中継部３５６が実行する処理の詳細は、図１２を用いて後述する。

図２に示す例では、テーブル格納部３２及び命令格納部３５を別々の構成として記載したが本発明はこれに限定されない。例えば、一つのメモリの領域を二つに分割し、一つの領域をテーブル格納部３２、他方の領域を命令格納部３５として実現することもできる。また、テーブル格納部３２、パケット格納部３３、及び命令格納部３５は、メモリ以外に、ＨＤＤ又はＳＳＤ等の他の記憶装置を用いても実現できる。

図３は、本発明の実施例のコネクション管理テーブル（Ｔ１）の構成例を示す説明図である。

コネクション管理テーブル（Ｔ１）は、ユーザ端末１とＷｅｂサーバ６との間に確立されるＴＣＰコネクションの状態を示すコネクション情報を格納する。コネクション情報は、ユーザ端末１からＷｅｂサーバ６に対して送信されるＳＹＮパケットを受信した場合に生成される。コネクション情報は、識別子（Ｔ１１）、サーバＩＰ（Ｔ１２）、サーバＰｏｒｔ（Ｔ１３）、ユーザ端末ＩＰ（Ｔ１４）、ユーザ端末Ｐｏｒｔ（Ｔ１５）、ＭＳＳ（Ｔ１６）、コネクション状態（Ｔ１７）、及びパケットポインタ（Ｔ１８）を含む。

識別子（Ｔ１１）は、コネクション管理テーブル（Ｔ１）に格納されるコネクション情報を識別するための識別番号である。サーバＩＰ（Ｔ１２）は、Ｗｅｂサーバ６に割り当てられるＩＰアドレスである。サーバＰｏｒｔ（Ｔ１３）は、Ｗｅｂサーバ６のポート番号である。ユーザ端末ＩＰ（Ｔ１４）は、ユーザ端末１に割り当てられるＩＰアドレスである。ユーザ端末Ｐｏｒｔ（Ｔ１５）は、ユーザ端末１のポート番号である。

サーバＩＰ（Ｔ１２）、サーバＰｏｒｔ（Ｔ１３）、ユーザ端末ＩＰ（Ｔ１４）、及びユーザ端末Ｐｏｒｔ（Ｔ１５）は、ＨＴＴＰを用いて通信を行うアプリケーションによって使用される情報である。

ＭＳＳ（Ｔ１６）は、ＴＣＰコネクションのＭＳＳ（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）である。中継装置３は、Ｗｅｂサーバ６からユーザ端末１へ送信されるＳＹＮ＋ＡＣＫパケットを受信した場合に、当該パケットに含まれるＭＳＳ情報を取得し、取得されたＭＳＳ情報をＭＳＳ（Ｔ１６）に格納する。

コネクション状態（Ｔ１７）は、中継装置３とＷｅｂサーバ６との間に確立されるＴＣＰコネクションの状態を示す。本実施例では、コネクション状態（Ｔ１７）には、「ＳＹＮ１」、「ＳＹＮ２」、「確立」、「ＨＴＴＰリクエスト一部受信」、及び「代理応答中」の五つの情報のいずれかが格納される。

「ＳＹＮ１」はＴＣＰコネクション確立時の初期状態を表し、「ＳＹＮ２」はＳＹＮ＋ＡＣＫパケットを受信したことを表す。「確立」はＴＣＰコネクションが確立されたことを表す。「ＨＴＴＰリクエスト一部受信」はＨＴＴＰリクエストが複数のパケットに分割されていることを表す。「代理応答中」はサービス経路４−２を介してパケットが転送されていることを表す。

パケットポインタ（Ｔ１８）は、パケット格納部３３に格納されるＨＴＴＰリクエストパケットの複製データの格納場所を示すポインタである。パケットポインタ（Ｔ１８）は、コネクション状態（Ｔ１７）が「ＨＴＴＰリクエスト一部受信」である場合にポインタが格納される。

図４は、本発明の実施例のルールテーブル（Ｔ２）の構成例を示す説明図である。

ルールテーブル（Ｔ２）は、使用するサービス経路４を判定するためのルールを格納する。ルールは、識別子（Ｔ２１）、サーバＩＰ（Ｔ２２）、サーバＰｏｒｔ（Ｔ２３）、ユーザ端末ＩＰ（Ｔ２４）、ユーザ端末Ｐｏｒｔ（Ｔ２５）、及びＨＴＴＰリクエスト条件（Ｔ２６）を含む。

識別子（Ｔ２１）は、ルールテーブル（Ｔ２）に登録されるルールを識別するための識別番号である。サーバＩＰ（Ｔ２２）は、Ｗｅｂサーバ６に割り当てられるＩＰアドレスであり、サーバＩＰ（Ｔ１２）と同一のものである。サーバＰｏｒｔ（Ｔ２３）は、Ｗｅｂサーバ６のポート番号であり、サーバＰｏｒｔ（Ｔ１３）と同一のものである。ユーザ端末ＩＰ（Ｔ２４）は、ユーザ端末１に割り当てられるＩＰアドレスであり、ユーザ端末ＩＰ（Ｔ１４）と同一のものである。ユーザＰｏｒｔ（Ｔ２５）は、ユーザ端末１のポート番号であり、ユーザ端末Ｐｏｒｔ（Ｔ１５）と同一のものである。

ＨＴＴＰリクエスト条件（Ｔ２６）は、レイヤ７に相当するＨＴＴＰに関する条件を格納する。ＨＴＴＰリクエスト条件（Ｔ２６）には、例えば、ＵＲＬに対する条件、Ｃｏｏｋｉｅの内容又はその他のフィールドに対する条件を設定してもよい。ＵＲＬに対する条件は、ホスト名、並びにディレクトリ名及びファイル名を条件として設定してもよいし、さらに、ファイルの拡張子に対する条件を設定することによってコンテンツの種類を特定することも可能である。

ＨＴＴＰリクエスト条件（Ｔ２６）に格納される条件の記述構文は、ＰＣＲＥ（Ｐｅｒｌ Ｃｏｍｐａｔｉｂｌｅ Ｒｅｇｕｌａｒ Ｅｘｐｒｅｓｓｉｏｎｓ）でもよいし、ほかの記述構文でもよい。図４の「＊」はワイルドカードを表し、任意の文字又は文字列に一致する記号である。

なお、ＨＴＴＰ以外の通信プロトコルに適用する場合、ＯＳＩ参照モデルにおけるアプリケーション層の情報を条件としては設定すればよい。

図５は、本発明の実施例の代理応答テーブル（Ｔ３）の構成例を示す説明図である。

代理情報テーブル（Ｔ３）は、サービス経路４−２を介した通信時に、Ｗｅｂサーバ６又はユーザ端末１から受信したパケットを転送するために必要な代理応答情報を格納する。代理応答情報は、識別子（Ｔ３１）、コネクションＩＤ（Ｔ３２）、ユーザ端末側情報（Ｔ３３）、及びＷｅｂサーバ側情報（Ｔ３４）を含む。

識別子（Ｔ３１）は、代理応答テーブル（Ｔ３）に登録される代理応答情報を識別するための識別番号である。コネクションＩＤ（Ｔ３２）は、コネクション情報の識別番号であり、識別子（Ｔ１１）に対応する。コネクションＩＤ（Ｔ３２）は、コネクション情報に対応する代理応答情報を検索するための検索キーとして用いられる。

ユーザ端末側情報（Ｔ３３）は、Ｗｅｂサーバ６から受信したパケットをユーザ端末１に転送する場合に用いられる情報である。ユーザ端末側情報（Ｔ３３）は、ユーザ端末ＩＰ（Ｔ３３１）、ユーザ端末Ｐｏｒｔ（Ｔ３３２）、シーケンス番号（Ｔ３３３）、及びＡＣＫ番号（Ｔ３３４）を含む。

ユーザ端末ＩＰ（Ｔ３３１）は、ユーザ端末１に割り当てられるＩＰアドレスであり、ユーザ端末ＩＰ（Ｔ１４）と同一のものである。ユーザ端末Ｐｏｒｔ（Ｔ３３２）は、ユーザ端末１のポート番号であり、ユーザ端末Ｐｏｒｔ（Ｔ１５）と同一のものである。シーケンス番号（Ｔ３３３）及びＡＣＫ番号（Ｔ３３４）は、中継装置３からユーザ端末１へのパケットの送信時に使用される番号である。

Ｗｅｂサーバ側情報（Ｔ３４）は、ユーザ端末１から受信したパケットをＷｅｂサーバ６に転送する場合に用いられる情報である。Ｗｅｂサーバ側情報（Ｔ３４）は、代理ＩＰ（Ｔ３４１）、代理Ｐｏｒｔ（Ｔ３４２）、シーケンス番号（Ｔ３４３）、及びＡＣＫ番号（Ｔ３４４）を含む。

代理ＩＰ（Ｔ３４１）は、中継装置３のＩＰアドレスである。代理Ｐｏｒｔ（Ｔ３４２）は、中継装置３のポート番号である。シーケンス番号（Ｔ３４３）及びＡＣＫ番号（Ｔ３４４）は、中継装置３からＷｅｂサーバ６へのパケットの送信時に使用される番号である。

図６は、本発明の実施例におけるＡＣＫ受信通知又はＦＩＮ受信通知の通知内容の一例を示す説明図である。

通知内容７は、Ｔｙｐｅ７１、コネクションＩＤ７２、及びパケット７３を含む。Ｔｙｐｅ７１は、ＡＣＫ又はＦＩＮのどちらの受信通知であるかを示す。コネクションＩＤ７２は、コネクションの識別子である。パケット７３は、ＡＣＫパケット又はＦＩＮパケットを格納する。

図７Ａ、図７Ｂ、及び図７Ｃは、本発明の実施例におけるＨＴＴＰメッセージの一例を示す説明図である。

図７Ａは、ＧＥＴメソッドを用いたＨＴＴＰリクエスト（Ｍ１）の一例を示し、図７Ｂは、ＰＯＳＴメソッドを用いたＨＴＴＰリクエスト（Ｍ２）の一例を示し、図７Ｃは、ＨＴＴＰレスポンス（Ｍ３）の一例を示す。

ＨＴＴＰメッセージは、ユーザ端末１が要求するコンテンツへのＵＲＬ（Ｍ１１）、（Ｍ２１）を含むＨＴＴＰメソッド、複数のヘッダフィールド、ＨＴＴＰヘッダの終端を表す空行（Ｍ１２）、（Ｍ２３）、（Ｍ３２）、及び空行に続くＨＴＴＰメッセージボディから構成される。

ヘッダフィールドの一つであるＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ（Ｍ２２）、（Ｍ３１）はＨＴＴＰメッセージボディの長さを表すフィールドである。

次に、中継装置３が実行する処理についてフローチャートを用いて説明する。

図８は、本発明の実施例の監視部３５２が実行する監視処理Ｓ１００の詳細を説明するフローチャートである。

ＴＣＰ管理部３５１は、ユーザ側インタフェース３４１を介してパケットを受信した場合、監視部３５２を呼び出し、処理の実行を指示する。

監視部３５２は、受信したパケットがＳＹＮパケットであるか否かを判定する（Ｓ１０１）。

受信したパケットがＳＹＮパケットでないと判定された場合、監視部３５２は、コネクション管理テーブル（Ｔ１）に当該パケットに関連するコネクション情報が存在するか否かを判定する（Ｓ１０２）。具体的には、以下のような処理が実行される。監視部３５２は、受信したパケットから送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、及び宛先ポート番号を取得する。監視部３５２は、サーバＩＰ（Ｔ１２）、サーバＰｏｒｔ（Ｔ１３）、ユーザ端末ＩＰ（Ｔ１４）、及びユーザ端末Ｐｏｒｔ（Ｔ１５）が、取得された送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、及び宛先ポート番号と一致するエントリを検索する。

コネクション管理テーブル（Ｔ１）に受信したパケットに関連するコネクション情報が存在しないと判定された場合、監視部３５２は、Ｓ１１０に進む。コネクション管理テーブル（Ｔ１）に受信したパケットに関連するコネクション情報が存在すると判定された場合、監視部３５２は、当該コネクション情報を参照し、コネクション状態（Ｔ１７）が「代理応答中」であるか否かを判定する（Ｓ１０３）。

コネクション状態（Ｔ１７）が「代理応答中」であると判定された場合、監視部３５２は、ユーザ側代理応答処理Ｓ２００を実行し（Ｓ１０４）、処理を終了する。ユーザ側代理応答処理Ｓ２００の詳細は、図９を用いて後述する。

コネクション状態（Ｔ１７）が「代理応答中」でないと判定された場合、監視部３５２は、受信したパケットがＡＣＫパケット、かつ、コネクション状態（Ｔ１７）が「ＳＹＮ２」であるか否かを判定する（Ｓ１０５）。Ｓ１０５の条件を満たす場合、受信したパケットは、ＨＴＴＰのＳＹＮパケット及びＳＹＮ＋ＡＣＫパケットの受信後に受信するＡＣＫパケットに対応し、Ｓ１０５の条件を満たさない場合、受信したパケットは、ＨＴＴＰリクエストパケットに対応する。

Ｓ１０５の判定条件を満たさないと判定された場合、監視部３５２は、ルール判定処理Ｓ３００を実行し（Ｓ１０７）、処理を終了する。ルール判定処理Ｓ３００の詳細は図１０を用いて後述する。

Ｓ１０５の判定条件を満たすと判定された場合、監視部３５２は、コネクション状態（Ｔ１７）を「確立」に更新し（Ｓ１０６）、その後、Ｓ１１０に進む。

Ｓ１０１において、受信したパケットがＳＹＮパケットである判定された場合、監視部３５２は、当該ＳＹＮパケットがＨＴＴＰ上で送信されるパケットであるか否かを判定する（Ｓ１０８）。具体的には、監視部３５２は、受信したパケットに含まれる宛先ポート番号を取得し、当該宛先ポート番号がＨＴＴＰに用いられるポート番号であるか否かを判定する。ＨＴＴＰに用いられるポート番号としては、８０、８０８０、８０００等が考えられる。

受信したＳＹＮパケットがＨＴＴＰ上で送信されるパケットでないと判定された場合、監視部３５２は、Ｓ１１０に進む。受信したＳＹＮパケットがＨＴＴＰ上で送信されるパケットであると判定された場合、監視部３５２は、当該ＳＹＮパケットに含まれる情報を用いて、コネクション管理テーブル（Ｔ１）にコネクション情報を登録する（Ｓ１０９）。具体的には、以下のような処理が実行される。

監視部３５２は、コネクション管理テーブル（Ｔ１）に行を追加し、当該行の識別子（Ｔ１１）に所定の識別番号を設定する。ここでは、識別子（Ｔ１１）には、上の行の識別子（Ｔ１１）に「１」加算した識別番号が設定される。監視部３５２は、受信したＳＹＮパケットから送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、及び宛先ポート番号を取得する。

監視部３５２は、サーバＩＰ（Ｔ１２）に宛先ＩＰアドレス、サーバＰｏｒｔ（Ｔ１３）に宛先ポート番号、ユーザ端末ＩＰ（Ｔ１４）に送信元ＩＰアドレス、さらに、ユーザ端末Ｐｏｒｔ（Ｔ１５）に送信元ポート番号を設定する。また、監視部３５２は、コネクション状態（Ｔ１７）に「ＳＹＮ１」を設定する。以上がＳ１０９の処理の説明である。

Ｓ１０２の判定結果がＮＯ、Ｓ１０６の処理が実行された後、Ｓ１０８の判定結果がＮＯ、又はＳ１０９の処理が実行された後、監視部３５２は、サービス１側インタフェース３４２を介して受信したパケットをＷｅｂサーバ６に送信し（Ｓ１１０）、処理を終了する。

図９は、本発明の実施例の監視部３５２が実行するユーザ側代理応答処理Ｓ２００を説明するフローチャートである。

監視部３５２は、受信したパケットがＡＣＫパケットであるか否かを判定する（Ｓ２０１）。

受信したパケットがＡＣＫパケットであると判定された場合、監視部３５２は、データ中継部３５６にＡＣＫ受信通知を出力し（Ｓ２０２）、処理を終了する。

受信したパケットがＡＣＫパケットでないと判定された場合、監視部３５２は、受信したパケットがＦＩＮパケットであるか否かを判定する（Ｓ２０３）。

受信したパケットがＦＩＮパケットでないと判定された場合、監視部３５２は処理を終了する。受信したパケットがＦＩＮパケットであると判定された場合、監視部３５２は、データ中継部３５６にＦＩＮ受信通知を出力し（Ｓ２０４）、処理を終了する。

なお、ＡＣＫ受信通知及びＦＩＮ受信通知の出力方法としては、監視部３５２が、予め所定のレジスタにＡＣＫ受信通知又はＦＩＮ受信通知を書き込む方法が考えられる。この場合、データ中継部３５６は、当該レジスタをポーリングすることによって、ＡＣＫ受信通知及びＦＩＮ受信通知を受けつけることができる。また、監視部３５２が、データ中継部３５６に割り込みを通知することによって実現することもできる。

図１０は、本発明の実施例のルール判定部３５４が実行するルール判定処理Ｓ３００を説明するフローチャートである。

ルール判定部３５４は、監視部３５２から処理の実行が指示されると、ルール判定処理Ｓ３００を開始する。

ルール判定部３５４は、ＨＴＴＰリクエスト全体を受信したか否かを判定する（Ｓ３０１）。例えば、ＧＥＴメソッドを用いたＨＴＴＰリクエストＭ１の場合、ルール判定部３５４は、空行（Ｍ１２）が含まれるパケットを受信するとＨＴＴＰリクエスト全体を受信したと判定する。ＰＯＳＴメソッドを用いたＨＴＴＰリクエスト（Ｍ２）の場合、ルール判定部３５４は、空行（Ｍ２２）からＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ（Ｍ２２）に示すバイト分のパケットを受信するとＨＴＴＰリクエスト全体を受信したと判定する。

ＨＴＴＰリクエスト全体を受信したと判定された場合、ルール判定部３５４は、コネクション管理テーブル（Ｔ１）を参照し、ＨＴＴＰリクエストパケットに対応するコネクション情報のコネクション状態（Ｔ１７）が「ＨＴＴＰリクエスト一部受信」であるか否かを判定する（Ｓ３０２）。

コネクション状態（Ｔ１７）が「ＨＴＴＰリクエスト一部受信」でないと判定された場合、ルール判定部３５４は、Ｓ３０４に進む。コネクション状態（Ｔ１７）が「ＨＴＴＰリクエスト一部受信」であると判定された場合、ルール判定部３５４は、パケット格納部３３からパケットを読み出す（Ｓ３０３）。具体的には、ルール判定部３５４は、コネクション情報のパケットポインタ（Ｔ１８）に基づいて、パケット格納部３３からパケットを読み出す。

ルール判定部３５４は、ＨＴＴＰリクエストパケットに基づいてルールテーブル（Ｔ２）を参照し、ＨＴＴＰリクエストに該当するルールが存在するか否かを判定する（Ｓ３０４）。例えば、以下のような処理が実行される。

ルール判定部３５４は、ＨＴＴＰリクエストパケットから送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、及び宛先ポート番号を取得する。ルール判定部３５４は、取得された送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、及び宛先ポート番号と、ユーザ端末ＩＰ（Ｔ２４）、ユーザ端末Ｐｏｒｔ（Ｔ２５）、サーバＩＰ（Ｔ２２）、及びサーバＰｏｒｔ（Ｔ２３）とを比較することによって、ルールを検索する。さらに、ルール判定部３５４は、検索されたルールのＨＴＴＰリクエスト条件（Ｔ２６）を参照し、ＨＴＴＰリクエストが当該条件を満たすか否かを判定する。以上がＳ３０４の処理の一例である。

ＨＴＴＰリクエストに対応するルールが存在すると判定された場合、ルール判定部３５４は、コネクション情報のコネクション状態（Ｔ１７）を「代理応答中」に更新し（Ｓ３０５）、ＨＴＴＰリクエスト送信部３５５にＨＴＴＰリクエスト送信処理Ｓ４００の実行を指示する（Ｓ３０６）。ＨＴＴＰリクエスト送信処理Ｓ４００の詳細は、図１１を用いて後述する。

ＨＴＴＰリクエストに対応するルールが存在しないと判定された場合、ルール判定部３５４は、コネクション管理テーブル（Ｔ１）からコネクション情報を削除し（Ｓ３０７）、その後、Ｓ３１１に進む。

Ｓ３０１において、ＨＴＴＰリクエスト全体を受信していないと判定された場合、ルール判定部３５４は、パケット格納部３３に受信したＨＴＴＰリクエストパケットをコピーする（Ｓ３０８）。ルール判定部３５４は、コネクション情報のパケットポインタ（Ｔ１８）に、パケット格納部３３に格納されたＨＴＴＰリクエストパケットの格納場所を示すポインタを登録する（Ｓ３０９）。また、ルール判定部３５４は、コネクション情報のコネクション状態（Ｔ１７）を「ＨＴＴＰリクエスト一部受信」に更新し、その後（Ｓ３１０）、Ｓ３１１に進む。

Ｓ３０７の処理の実行後又はＳ３１０の処理の実行後、ルール判定部３５４は、サービス１側インタフェース３４２を介して受信したＨＴＴＰリクエストパケットをＷｅｂサーバ６に送信し（Ｓ３１１）、処理を終了する。

図１１は、本発明の実施例のＨＴＴＰリクエスト送信部３５５が実行するＨＴＴＰリクエスト送信処理Ｓ４００を説明するフローチャートである。

ＨＴＴＰリクエスト送信部３５５は、ルール判定部３５４から処理の実行が指示されると、ＨＴＴＰリクエスト送信処理Ｓ４００を開始する。

ＨＴＴＰリクエスト送信部３５５は、代理応答テーブル（Ｔ３）に、受信したＨＴＴＰリクエストパケットに対応する代理応答情報を登録する（Ｓ４０１）。具体的には、以下のような処理が実行される。

ＨＴＴＰリクエスト送信部３５５は、代理応答テーブル（Ｔ３）に行を追加する。ＨＴＴＰリクエスト送信部３５５は、Ｓ１０２において検索されたコネクション情報の識別子（Ｔ１１）を取得し、また、ＨＴＴＰリクエストパケットからユーザ端末１のＩＰアドレス及びポート番号、並びにシーケンス番号及びＡＣＫ番号を取得する。

ＨＴＴＰリクエスト送信部３５５は、追加された行の識別子（Ｔ３１）に所定の識別番号を設定し、コネクションＩＤ（Ｔ３２）にコネクション情報の識別子（Ｔ１１）から取得された識別番号を設定する。また、ＨＴＴＰリクエスト送信部３５５は、追加された行のユーザ端末側情報（Ｔ３３）のユーザ端末ＩＰ（Ｔ３３１）及びユーザ端末Ｐｏｒｔ（Ｔ３３２）に、ユーザ端末１のＩＰアドレス及びポート番号を設定する。

ＨＴＴＰリクエスト送信部３５５は、追加された行のユーザ端末側情報（Ｔ３３）のシーケンス番号（Ｔ３３３）に取得されたシーケンス番号を設定する。さらに、ＨＴＴＰリクエスト送信部３５５は、追加された行のユーザ端末側情報（Ｔ３３）のＡＣＫ番号（Ｔ３３４）に取得されたＡＣＫ番号を設定する。以上がＳ４０１の処理の説明である。

ＨＴＴＰリクエスト送信部３５５は、ＨＴＴＰリクエストパケットのヘッダ情報に基づいてＷｅｂサーバ６宛のＲＳＴパケットを生成し、サービス１側インタフェース３４２を介してＷｅｂサーバ６に当該ＲＳＴパケットを送信する（Ｓ４０２）。これは、サービス経路４−１上のＴＣＰコネクションを切断するためである。

ＨＴＴＰリクエスト送信部３５５は、サービス２側インタフェース３４３を用いてサービス経路４−２上に新たなＴＣＰコネクションを確立し、確立されたＴＣＰコネクションの情報に基づいて代理応答情報を更新する（Ｓ４０３）。具体的には、以下のような処理が実行される。

ＨＴＴＰリクエスト送信部３５５は、サービス２側インタフェース３４３を用いて、Ｗｅｂサーバ６との間で３ウェイハンドシェイク通信を行う。これによって、中継装置３とＷｅｂサーバ６とを接続するサービス経路４−２上に、新たなＴＣＰコネクションが確立される。このとき、中継装置３とＷｅｂサーバ６との間の通信では、新たなＴＣＰコネクションの確立時に用いられるＡＣＫ番号及びシーケンス番号が引き続き用いられる。

ＨＴＴＰリクエスト送信部３５５は、Ｓ４０１において追加された行のＷｅｂサーバ側情報（Ｔ３４）の代理ＩＰ（Ｔ３４１）及び代理Ｐｏｒｔ（Ｔ３４２）に中継装置３のＩＰアドレス及びポート番号を設定する。また、ＨＴＴＰリクエスト送信部３５５は、追加された行のＷｅｂサーバ側情報（Ｔ３４）のシーケンス番号（Ｔ３４３）及びＡＣＫ番号（Ｔ３４４）のそれぞれに、中継装置３がＷｅｂサーバ６にパケットを送信する場合に使用するシーケンス番号及びＡＣＫ番号を設定する。以上がＳ４０３の処理の説明である。

ＨＴＴＰリクエスト送信部３５５は、代理応答情報のＷｅｂサーバ側情報（Ｔ３４）に基づいてＨＴＴＰリクエストパケットのヘッダを書き換え、サービス２側インタフェース３４３を介してＷｅｂサーバ６に書き換えられたＨＴＴＰリクエストパケットを送信する（Ｓ４０４）。具体的には、以下のような処理が実行される。

ＨＴＴＰリクエスト送信部３５５は、ＨＴＴＰリクエストの送信元ＩＰアドレス、及び送信元ポート番号を、代理応答情報のＷｅｂサーバ側情報（Ｔ１３）の代理ＩＰ（Ｔ３４１）、及び代理Ｐｏｒｔ（Ｔ３４２）に書き換える。

また、ＨＴＴＰリクエスト送信部３５５は、代理応答情報のＷｅｂサーバ側情報（Ｔ３４）のシーケンス番号（Ｔ３４３）及びＡＣＫ番号（Ｔ３４４）に基づいて、Ｗｅｂサーバ６へのパケット送信に用いるシーケンス番号及びＡＣＫ番号を決定する。ＨＴＴＰリクエスト送信部３５５は、ＨＴＴＰリクエストのシーケンス番号及びＡＣＫ番号を、決定されたシーケンス番号及びＡＣＫ番号に書き換える。以上がＳ４０４の処理の説明である。

なお、シーケンス番号及びＡＣＫ番号の決定方法は公知のものであるため詳細な説明を省略する。

なお、ＨＴＴＰリクエスト送信部３５５は、書き換えられたＨＴＴＰリクエストパケットの送信後、当該ＨＴＴＰリクエストパケットに対するＡＣＫパケットを受信するまで待ち状態となる。

ＨＴＴＰリクエスト送信部３５５は、Ｗｅｂサーバ６から中継装置３宛てのＡＣＫパケットを受信すると、代理応答情報のユーザ端末側情報（Ｔ３３）に基づいてＡＣＫパケットのヘッダを書き換え、ユーザ側インタフェース３４１を介してユーザ端末１に書き換えられたＡＣＫパケットを送信する（Ｓ４０５）。具体的には、以下のような処理が実行される。

ＨＴＴＰリクエスト送信部３５５は、代理応答テーブル（Ｔ３）を参照し、代理ＩＰ（Ｔ３４１）及び代理Ｐｏｒｔ（Ｔ３４２）がＡＣＫパケットの宛先ＩＰアドレス及び宛先ポート番号と一致する代理応答情報を検索する。

ＨＴＴＰリクエスト送信部３５５は、ＡＣＫパケットのシーケンス番号及びＡＣＫ番号に検索された代理応答情報のＷｅｂサーバ側情報（Ｔ３４）のシーケンス番号（Ｔ３４３）及びＡＣＫ番号（Ｔ３４４）を設定し、ＡＣＫパケットの宛先ＩＰアドレス、及び宛先ポート番号を、検索された代理応答情報のユーザ端末側情報（Ｔ３３）のユーザ端末ＩＰ（Ｔ３３１）、及びユーザ端末Ｐｏｒｔ（Ｔ３３２）に書き換える。

また、ＨＴＴＰリクエスト送信部３５５は、検索された代理応答情報のユーザ端末側情報（Ｔ３３）のシーケンス番号（Ｔ３３３）及びＡＣＫ番号（Ｔ３３４）に基づいて、ユーザ端末１へのパケットの送信に用いるシーケンス番号及びＡＣＫ番号を決定する。ＨＴＴＰリクエスト送信部３５５は、ＡＣＫパケットのシーケンス番号及びＡＣＫ番号を、決定されたシーケンス番号及びＡＣＫ番号に書き換える。以上がＳ４０５の処理の説明である。

ＨＴＴＰリクエスト送信部３５５は、書き換えられたＡＣＫパケットの送信後、データ中継部３５６に処理の実行を指示する（Ｓ４０６）。

なお、ＨＴＴＰリクエスト送信部３５５は、ユーザ端末１から受信したパケットのシーケンス番号及びＡＣＫ番号に基づいて、ユーザ端末１にパケットを送信する場合に用いるシーケンス番号及びＡＣＫ番号を予め算出し、算出されたシーケンス番号及びＡＣＫ番号をシーケンス番号（Ｔ３３３）及びＡＣＫ番号（Ｔ３３４）に格納してもよい。この場合、ＨＴＴＰリクエスト送信部３５５は、ＡＣＫパケットのシーケンス番号及びＡＣＫ番号を、シーケンス番号（Ｔ３３３）及びＡＣＫ番号（Ｔ３３４）に書き換える。Ｗｅｂサーバ側情報（Ｔ３４）のシーケンス番号（Ｔ３４３）及びＡＣＫ番号（Ｔ３４４）も同様の制御が可能である。

図１２は、本発明の実施例のデータ中継部３５６が実行するデータ中継処理Ｓ５００を説明するフローチャートである。

データ中継部３５６は、ＨＴＴＰリクエスト送信部３５５から処理の実行が指示されると、データ中継処理Ｓ５００を開始する。

データ中継部３５６は、処理を開始した後、Ｗｅｂサーバ６から中継装置３宛のパケットを受信するまで待機する（Ｓ５０１）。データ中継部３５６は、Ｗｅｂサーバ６からパケットを受信すると、当該パケットがＦＩＮパケットであるか否かを判定する（Ｓ５０２）。

受信したパケットがＦＩＮパケットでない、すなわち、コンテンツを含むパケットであると判定された場合、データ中継部３５６は、当該パケットに対応する代理応答情報に基づいてパケットのヘッダを書き換えて、ユーザ側インタフェース３４１を介してユーザ端末１に書き換えられたパケットを送信する（Ｓ５０３）。その後、データ中継部３５６は、ＡＣＫ受信通知を受けつけるまで待機する。具体的には、以下のような処理が実行される。

データ中継部３５６は、代理応答テーブル（Ｔ３）を参照し、代理ＩＰ（Ｔ３４１）及び代理Ｐｏｒｔ（Ｔ３４２）が受信したパケットの宛先ＩＰアドレス及び宛先ポート番号と一致する代理応答情報を検索する。データ中継部３５６は、パケットのシーケンス番号及びＡＣＫ番号に検索された代理応答情報のＷｅｂサーバ側情報（Ｔ３４）のシーケンス番号（Ｔ３４３）及びＡＣＫ番号（Ｔ３４４）を設定し、ＡＣＫパケットの宛先ＩＰアドレス、及び宛先ポート番号を、検索された代理応答情報のユーザ端末側情報（Ｔ３３）のユーザ端末ＩＰ（Ｔ３３１）、及びユーザ端末Ｐｏｒｔ（Ｔ３３２）に書き換える。

また、データ中継部３５６は、検索された代理応答情報のユーザ端末側情報（Ｔ３３）のシーケンス番号（Ｔ３３３）及びＡＣＫ番号（Ｔ３３４）に基づいて、ユーザ端末１へのパケットの送信に用いるシーケンス番号及びＡＣＫ番号を決定する。データ中継部３５６は、ＡＣＫパケットのシーケンス番号及びＡＣＫ番号を、決定されたシーケンス番号及びＡＣＫ番号に書き換える。以上がＳ５０３の処理の説明である。

データ中継部３５６は、監視部３５２からＡＣＫ受信通知を受けつけると、ＡＣＫ受信通知に含まれるＡＣＫパケットに対応する代理応答情報に基づいてＡＣＫパケットのヘッダを書き換えて、サービス２側インタフェース３４３を介してＷｅｂサーバ６に書き換えられたＡＣＫパケットを送信する（Ｓ５０４）。その後、データ中継部３５６は、Ｓ５０１に戻る。具体的には、以下のような処理が実行される。

データ中継部３５６は、代理応答テーブル（Ｔ３）を参照し、コネクションＩＤ（Ｔ３２）がＡＣＫ受信通知に含まれるコネクションＩＤ７２と一致する代理応答情報を検索する。

データ中継部３５６は、ＡＣＫパケットのシーケンス番号及びＡＣＫ番号に検索された代理応答情報のユーザ端末側情報（Ｔ３３）のシーケンス番号（Ｔ３３３）及びＡＣＫ番号（Ｔ３３４）を設定し、ＡＣＫパケットの送信元ＩＰアドレス及び送信元ポート番号を、検索された代理応答情報のＷｅｂサーバ側情報（Ｔ３４）の代理ＩＰ（Ｔ３４１）及び代理Ｐｏｒｔ（Ｔ３４２）に書き換える。

また、データ中継部３５６は、検索された代理応答情報のＷｅｂサーバ側情報（Ｔ３４）のシーケンス番号（Ｔ３４３）及びＡＣＫ番号（Ｔ３４４）に基づいて、Ｗｅｂサーバ６へのパケット送信に用いるシーケンス番号及びＡＣＫ番号を決定する。データ中継部３５６は、ＡＣＫパケットのシーケンス番号及びＡＣＫ番号を、決定されたシーケンス番号及びＡＣＫ番号に書き換える。以上がＳ５０４の処理の説明である。

Ｓ５０２において受信したパケットがＦＩＮパケットであると判定された場合、データ中継部３５６は、当該ＦＩＮパケットに対応する代理応答情報に基づいてＦＩＮパケットのヘッダを書き換えて、ユーザ側インタフェース３４１を介してユーザ端末１に書き換えられたＦＩＮパケットを送信する（Ｓ５０５）。その後、データ中継部３５６は、監視部３５２からＡＣＫ受信通知を受けつけるまで待機する。

具体的には、データ中継部３５６は、Ｓ５０３と同様の処理を実行することによって、代理応答テーブル（Ｔ３）からＦＩＮパケットに対応する代理応答情報を検索する。データ中継部３５６は、ＦＩＮパケットのシーケンス番号及びＡＣＫ番号に検索された代理応答情報のＷｅｂサーバ側情報（Ｔ３４）のシーケンス番号（Ｔ３４３）及びＡＣＫ番号（Ｔ３４４）を設定し、ユーザ端末側情報（Ｔ３３）に基づいて、ＦＩＮパケットの宛先ＩＰアドレス、宛先ポート番号、シーケンス番号、及びＡＣＫ番号を書き換える。

データ中継部３５６は、監視部３５２からＡＣＫ受信通知を受けつけると、ＡＣＫ受信通知に含まれるＡＣＫパケットに対応する代理応答情報に基づいてＡＣＫパケットのヘッダを書き換えて、サービス２側インタフェース３４３を介してＷｅｂサーバ６に書き換えられたＡＣＫパケットを送信する（Ｓ５０６）。その後、データ中継部３５６は、監視部３５２からＦＩＮ受信通知を受けつけるまで待機する。

具体的には、データ中継部３５６は、Ｓ５０４と同様の処理を実行することによって、代理応答テーブル（Ｔ３）からＡＣＫパケットに対応する代理応答情報を検索する。データ中継部３５６は、ＡＣＫパケットのシーケンス番号及びＡＣＫ番号に検索された代理応答情報のユーザ端末側情報（Ｔ３３）のシーケンス番号（Ｔ３３３）及びＡＣＫ番号（Ｔ３３４）を設定し、Ｗｅｂサーバ側情報（Ｔ３４）に基づいて、ＡＣＫパケットの宛先ＩＰアドレス、宛先ポート番号、シーケンス番号、及びＡＣＫ番号を書き換える。

データ中継部３５６は、監視部３５２からＦＩＮ受信通知を受け付けると、ＦＩＮ受信通知に含まれるＦＩＮパケットに対応する代理応答情報に基づいてＦＩＮパケットのヘッダを書き換えて、サービス２側インタフェース３４３を介してＷｅｂサーバ６に送信する（Ｓ５０７）。その後、データ中継部３５６は、Ｗｅｂサーバ６から中継装置３宛のＡＣＫパケットを受信するまで待機する。

具体的には、データ中継部３５６は、Ｓ５０４と同様の処理を実行することによって、代理応答テーブル（Ｔ３）からＦＩＮパケットに対応する代理応答情報を検索する。データ中継部３５６は、ＦＩＮパケットのシーケンス番号及びＡＣＫ番号に検索された代理応答情報のユーザ端末側情報（Ｔ３３）のシーケンス番号（Ｔ３３３）及びＡＣＫ番号（Ｔ３３４）を設定し、Ｗｅｂサーバ側情報（Ｔ３４）に基づいて、ＡＣＫパケットの宛先ＩＰアドレス、宛先ポート番号、シーケンス番号、及びＡＣＫ番号を書き換える。

データ中継部３５６は、Ｗｅｂサーバ６から中継装置３宛のＡＣＫパケットを受信すると、ＡＣＫパケットに対応する代理応答情報のユーザ端末側情報（Ｔ３３）に基づいてＡＣＫパケットのヘッダを書き換えて、ユーザ側インタフェース３４１を介してユーザ端末１に書き換えられたＡＣＫパケットを送信する（Ｓ５０８）。

具体的には、データ中継部３５６は、Ｓ５０３と同様の処理を実行することによって、代理応答テーブル（Ｔ３）からＡＣＫパケットに対応する代理応答情報を検索する。データ中継部３５６は、ＡＣＫパケットのシーケンス番号及びＡＣＫ番号に検索された代理応答情報のＷｅｂサーバ側情報（Ｔ３４）のシーケンス番号（Ｔ３４３）及びＡＣＫ番号（Ｔ３４４）を設定し、ユーザ端末側情報（Ｔ３３）に基づいて、ＡＣＫパケットの宛先ＩＰアドレス、宛先ポート番号、シーケンス番号、及びＡＣＫ番号を書き換える。

データ中継部３５６は、コネクション管理テーブル（Ｔ１）及び代理応答テーブル（Ｔ３）から、切断されたＴＣＰコネクションに対応するコネクション情報及び代理応答情報を削除し（Ｓ５０９）、処理を終了する。

図１３は、本発明の実施例の応答部３５３が実行する応答処理Ｓ６００を説明するフローチャートである。

ＴＣＰ管理部３５１は、サービス１側インタフェース３４２を介してパケットを受信した場合、応答部３５３を呼び出し、処理の実行を指示する。

応答部３５３は、受信したパケットがＨＴＴＰのＳＹＮ＋ＡＣＫパケットであるか否かを判定する（Ｓ６０１）。すなわち、受信したパケットが、ＳＹＮパケットの受信後に受信するＳＹＮ＋ＡＣＫパケットであるか否かが判定される。

受信したパケットがＨＴＴＰのＳＹＮ＋ＡＣＫパケットでないと判定された場合、応答部３５３はＳ６０６に進む。受信したパケットがＨＴＴＰのＳＹＮ＋ＡＣＫパケットであると判定された場合、応答部３５３は、コネクション管理テーブル（Ｔ１）に、受信したＳＹＮ＋ＡＣＫパケットに関連するコネクション情報が存在するか否かを判定する（Ｓ６０２）。Ｓ６０２の判定方法は、Ｓ１０２と同一の判定方法を用いればよい。

なお、コネクション情報が存在しない場合、不正な通信又は障害の発生等に該当するが、中継装置３は、特にパケットに対する処理をすることなくユーザ端末１に送信する。この場合、ユーザ端末１が不正な通信又は障害の発生等を判定することとなる。

コネクション管理テーブル（Ｔ１）に、受信したＳＹＮ＋ＡＣＫパケットに関連するコネクション情報が存在しないと判定された場合、応答部３５３は、Ｓ６０６に進む。受信したＳＹＮ＋ＡＣＫパケットに関連するコネクション情報が存在すると判定された場合、応答部３５３は、当該コネクション情報のコネクション状態（Ｔ１７）が「ＳＹＮ１」であるか否かを判定する（Ｓ６０３）。

コネクション情報のコネクション状態（Ｔ１７）が「ＳＹＮ１」でないと判定された場合、応答部３５３は、Ｓ６０６に進む。コネクション情報のコネクション状態（Ｔ１７）が「ＳＹＮ１」であると判定された場合、応答部３５３は、コネクション状態（Ｔ１７）を「ＳＹＮ２」に更新する（Ｓ６０４）。

応答部３５３は、受信したＳＹＮ＋ＡＣＫパケットからＭＳＳの情報を取得し、取得されたＭＳＳの情報をコネクション情報のＭＳＳ（Ｔ１６）に格納する（Ｓ６０５）。

応答部３５３は、ユーザ側インタフェース３４１を介して受信したパケットをユーザ端末１に送信し（Ｓ６０６）、処理を終了する。

次に、通信システムにおける通信の流れについてシーケンス図を用いて説明する。なお、シーケンス図において、ユーザ端末１と中継装置３との間を接続するルータ２−１は、ユーザ端末１と中継装置３との間のパケット転送のみを行うため省略する。

（動作例１）
図１４Ａ及び図１４Ｂは、本発明の実施例の通信システムにおけるサービス経路４が切り替えられない場合の通信の流れを示すシーケンス図である。

動作例１では、ＩＰアドレスが「１０．０．０．１」であるユーザ端末１−１がＩＰアドレスが「１０．０．１．１」であるＷｅｂサーバ６−１が保持するコンテンツ（ＨＴＴＰ：／／ｓｅｒｖｅｒ２．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ）を要求する。動作例１では、ＨＴＴＰリクエストがルールテーブル（Ｔ２）のいずれのルールにも該当しないため、サービス経路４−１を用いて通信が行われる。

なお、動作例１ではＨＴＴＰリクエストが一つのパケットに格納されているものとする。ＨＴＴＰリクエストが複数のパケットに分割されて送信される場合の動作については、動作例３（図１６参照）において説明する。

ユーザ端末１−１は、Ｗｅｂサーバ６−１宛てのＳＹＮパケットを送信する（ＳＱ１０１）。中継装置３は、ＳＹＮパケットを受信すると監視処理Ｓ１００を開始する。

監視処理Ｓ１００では、監視部３５２は、受信したＳＹＮパケットがＨＴＴＰ上のパケットであるか否かを判定する（Ｓ１０８）。ここでは、ＨＴＴＰ上のパケットであると判定されるため、監視部３５２は、コネクション管理テーブル（Ｔ１）にコネクション情報を登録する（Ｓ１０９）。また、監視部３５２は、サービス１側インタフェース３４２を介してＷｅｂサーバ６−１に受信したＳＹＮを送信する（Ｓ１１０、ＳＱ１０２）。

中継装置３は、Ｗｅｂサーバ６−１からユーザ端末１−１宛てのＳＹＮ＋ＡＣＫパケットを受信すると（ＳＱ１０３）、応答処理Ｓ６００を開始する。

応答処理Ｓ６００では、応答部３５３は、コネクション状態（Ｔ１７）が「ＳＹＮ１」であるか否かを判定する（Ｓ６０３）。ここでは、コネクション状態（Ｔ１７）が「ＳＹＮ１」であるため、応答部３５３は、コネクション状態（Ｔ１７）を「ＳＹＮ２」に更新し（Ｓ６０４）、受信したＳＹＮ＋ＡＣＫパケットから取得されたＭＳＳ情報をＭＳＳ（Ｔ１６）に登録する（Ｓ６０５）。応答部３５３は、ユーザ側インタフェース３４１を介してユーザ端末１−１に受信したＳＹＮ＋ＡＣＫパケットを送信する（Ｓ６０６、ＳＱ１０４）。

中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛てのＡＣＫパケットを受信すると（ＳＱ１０５）、監視処理Ｓ１００を開始する。

監視処理Ｓ１００では、監視部３５２は、コネクション管理テーブル（Ｔ１）に存在するコネクション情報のコネクション状態（Ｔ１７）が「代理応答中」であるか否かを判定する（Ｓ１０３）。コネクション状態（Ｔ１７）は「代理応答中」ではないため、監視部３５２は、受信したパケットがＡＣＫパケット、かつ、コネクション状態（Ｔ１７）が「ＳＹＮ２」であるか否かを判定する（Ｓ１０５）。ここでは、Ｓ１０５の条件を満たすため、監視部３５２は、コネクション状態（Ｔ１７）を「確立」に更新する（Ｆ１０８）。監視部３５２は、サービス１側インタフェースを介してＷｅｂサーバ６−１に受信したＡＣＫパケットを送信する（Ｓ６０６、ＳＱ１０６）。

中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛てのＨＴＴＰリクエストパケットを受信すると（ＳＱ１０７）、監視処理Ｓ１００を開始する。

監視処理Ｓ１００では、監視部３５２は、Ｓ１０５の条件を満たすか否かを判定する。ここでは、Ｓ１０５の条件を満たさないため、監視部３５２は、ルール判定部３５４に処理の実行を指示する（Ｓ１０４）。

ルール判定処理Ｓ３００では、ルール判定部３５４は、一つのパケットにＨＴＴＰリクエスト全体が含まれるため、コネクション状態（Ｔ１７）が「ＨＴＴＰリクエスト一部受信」であるか否かを判定する（Ｓ３０２）。コネクション状態（Ｔ１７）は「ＨＴＴＰリクエスト一部受信」ではないため、ルール判定部３５４は、ＨＴＴＰリクエストに該当するルールが存在するか否かを判定する（Ｓ３０４）。ここでは、該当するルールが存在しないものと判定される。そのため、ルール判定部３５４は、コネクション管理テーブル（Ｔ１）からコネクション情報を削除し（Ｓ３０７）、サービス１側インタフェース３４２を介してＷｅｂサーバ６−１に受信したＨＴＴＰリクエストパケットを送信する（Ｓ３１１、ＳＱ１０８）。

中継装置３は、Ｗｅｂサーバ６−１からユーザ端末１−１宛てのＡＣＫパケットを受信すると（ＳＱ１０９）、応答処理Ｓ６００開始する。

応答処理Ｓ６００では、応答部３５３は、受信したパケットがＳＹＮ＋ＡＣＫパケットであるか否かを判定する（Ｓ６０１）。受信したパケットはＳＹＮ＋ＡＣＫパケットではないため、応答部３５３は、ユーザ側インタフェース３４１を介してユーザ端末１−１に受信したＡＣＫパケットを送信する（Ｓ６０６、ＳＱ１１０）。

中継装置３は、Ｗｅｂサーバ６−１からユーザ端末１−１宛てのコンテンツを格納するパケットを受信すると（ＳＱ１１１）、応答処理Ｓ６００を開始する。応答処理Ｓ６００では、ＳＱ１１０と同様に、ユーザ側インタフェース３４１を介してユーザ端末１−１に受信したパケットが送信される（Ｓ６０６、ＳＱ１１２）。

中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛てのＡＣＫパケットを受信すると（ＳＱ１１３）、監視処理Ｓ１００を開始する。

監視処理Ｓ１００では、監視部３５２は、コネクション管理テーブル（Ｔ１）にコネクション情報が存在するか否かを判定する（Ｓ１０２）。ＳＱ１０７の後に実行されるルール判定処理Ｓ３００においてコネクション情報が削除されているため（Ｓ３０７）、監視部３５２は、サービス１側インタフェース３４２を介してＷｅｂサーバ６−１に受信したＡＣＫパケットを送信する（Ｓ１１０、ＳＱ１１４）。

中継装置３は、全てのコンテンツが送信されるまでＳＱ１０３〜ＳＱ１１４までの処理を繰り返し実行することとなる。

中継装置３は、Ｗｅｂサーバ６−１からユーザ端末１−１宛てのＦＩＮパケットを受信した後（ＳＱ１１５）、又は、ユーザ端末１−１宛のＡＣＫパケットを受信した後（ＳＱ１２１）、応答処理Ｓ６００を開始する。当該応答処理Ｓ６００は、ＳＱ１０９の後に実行される応答処理Ｓ６００のフローと同様のフローとなる。すなわち、受信したＦＩＮパケット又はＡＣＫパケットがユーザ側インタフェース３４１を介してユーザ端末１−１に送信される（ＳＱ１１６、ＳＱ１２２）。

また、中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛てのＡＣＫパケットを受信した後（ＳＱ１１７）、又はＦＩＮパケットを受信した後（ＳＱ１１９）、監視処理Ｓ１００を開始する。当該監視処理Ｓ１００は、ＳＱ１１３の後に実行される監視処理Ｓ１００と同様のフローとなる。すなわち、受信したＡＣＫパケット又はＦＩＮパケットがサービス１側インタフェース３４２を介してＷｅｂサーバ６−１に送信される（ＳＱ１１８、ＳＱ１２０）。

（動作例２）
図１５Ａ及び図１５Ｂは、本発明の実施例の通信システムにおけるサービス経路４が切り替えられる場合の通信の流れを示すシーケンス図である。

動作例２では、ＩＰアドレスが「１０．０．０．３」であるユーザ端末１−１がＩＰアドレスが「１０．０．１．３」であるＷｅｂサーバ６−１が保持するコンテンツ（ＨＴＴＰ：／／ｓｅｒｖｅｒ３．ｃｏｍ／ＩＭＡＧＥ．ＪＰＧ）を要求する。動作例２では、ＨＴＴＰリクエストがルールテーブル（Ｔ２）のいずれかのルールに該当するため、サービス経路４−２を用いて通信が行われる。

なお、動作例２ではＨＴＴＰリクエストが一つのパケットに格納されているものとする。ＨＴＴＰリクエストが複数のパケットに分割されて送信される場合の動作については、動作例４（図１７参照）において説明する。

ＳＱ２０１からＳＱ２０６までのＴＣＰコネクションの確立処理は、ＳＱ１０１からＳＱ１０６までの処理と同一であるため説明を省略する。

中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛てのＨＴＴＰリクエストパケットを受信すると（ＳＱ２０７）、監視処理Ｓ１００を開始する。

監視処理Ｓ１００では、監視部３５２は、Ｓ１０５の条件を満たさないため、監視部３５２は、ルール判定部３５４に処理の実行を指示する（Ｓ１０４）。

ルール判定処理Ｓ３００では、ルール判定部３５４は、ＨＴＴＰリクエストに該当するルールが存在すると判定するため、コネクション状態（Ｔ１３）を「代理応答中」に更新し（Ｓ３０５）、ＨＴＴＰリクエスト送信部３５５に処理の実行を指示する（Ｓ３０６）。

ＨＴＴＰリクエスト送信処理Ｓ４００では、ＨＴＴＰリクエスト送信部３５５は、代理応答テーブル（Ｔ３）に代理応答情報を登録する（Ｓ４０１）。ＨＴＴＰリクエスト送信部３５５は、サービス経路４−１経由でＷｅｂサーバ６−１にＲＳＴパケットを送信する（Ｓ４０２、ＳＱ２０８）。ＨＴＴＰリクエスト送信部３５５は、サービス経路４−２上に新たなＴＣＰコネクションを確立し、新たなＴＣＰコネクションの情報に基づいて代理応答情報を更新する（Ｓ４０３、ＳＱ２０９）。ＨＴＴＰリクエスト送信部３５５は、ユーザ端末１−１から受信したＨＴＴＰリクエストパケットのヘッダを書き換えて、サービス２側インタフェースを介してＷｅｂサーバ６−１に送信する（Ｓ４０４、ＳＱ２１０）。

ＨＴＴＰリクエスト送信部３５５は、Ｗｅｂサーバ６−１から中継装置３宛てのＡＣＫパケットを受信すると（ＳＱ２１１）、代理応答情報に基づいてＡＣＫパケットのヘッダを書き換えて、ユーザ側インタフェース３４１を介してユーザ端末１−１に書き換えられたＡＣＫパケットを送信する（Ｓ４０５、ＳＱ２１２）。その後、ＨＴＴＰリクエスト送信部３５５は、データ中継部３５６に処理の実行を指示する（Ｓ４０６）。

ユーザ端末１−１に送信されるＡＣＫパケットのＡＣＫ番号及びシーケンス番号は、ユーザ端末１−１とＷｅｂサーバ６−１との間のＴＣＰコネクションの確立時に用いられたＡＣＫ番号及びシーケンス番号が引き続き用いられる。したがって、ユーザ端末１−１は、最初のＴＣＰコネクションを介した通信であるように認識される。すなわち、ユーザ端末１−１には通信経路の切り替え等が認識されない。

データ中継処理Ｓ５００では、データ中継部３５６が、Ｗｅｂサーバ６−１から中継装置３宛てのコンテンツを含むパケットを受信すると（ＳＱ２１３）、代理応答情報のユーザ端末側情報（Ｔ３３）に基づいてコンテンツを格納するパケットのヘッダを書き換え、ユーザ側インタフェース３４１を介してユーザ端末１−１に書き換えられたパケットを送信する（Ｓ５０３、ＳＱ２１４）。

ユーザ端末１−１に送信されるコンテンツを含むパケットのＡＣＫ番号及びシーケンス番号も、ＳＱ２１２の場合と同様に、ユーザ端末１−１とＷｅｂサーバ６−１との間のＴＣＰコネクションの確立時に用いられたＡＣＫ番号及びシーケンス番号が引き続き用いられる。

また、中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛てのＡＣＫパケットを受信すると（ＳＱ２１５）、監視処理Ｓ１００を開始する。

監視処理Ｓ１００では、コネクション状態（Ｔ１３）が「代理応答中」であるため、監視部３５２は、ユーザ側代理応答処理Ｓ２００を開始する。ユーザ側代理応答処理Ｓ２００では、監視部３５２は、受信したパケットがＡＣＫパケットであるため、データ中継部３５６にＡＣＫ受信通知を出力する（Ｓ２０２）。

このとき、データ中継処理Ｓ５００では、データ中継部３５６が、代理応答情報のＷｅｂサーバ側情報（Ｔ３４）に基づいてＡＣＫパケットのヘッダを書き換え、サービス２側インタフェース３４３を介してＷｅｂサーバ６−１に書き換えられたＡＣＫパケットを送信する（Ｓ５０４、ＳＱ２１６）。

Ｗｅｂサーバ６−１に送信されるＡＣＫパケットのＡＣＫ番号及びシーケンス番号は、中継装置３とＷｅｂサーバ６−１との間の新たなＴＣＰコネクションの確立時に用いられたＡＣＫ番号及びシーケンス番号が引き続き用いられる。

全てのコンテンツが送信されるまで、ＳＱ２１３からＳＱ２１６までの処理が実行されることとなる。

中継装置３がＷｅｂサーバ６−１から中継装置３宛てのＦＩＮパケットを受信すると（ＳＱ２１７）、データ中継部３５６は、代理応答情報のユーザ端末側情報（Ｔ３３）に基づいてＦＩＮパケットのヘッダを書き換え、ユーザ側インタフェース３４１からユーザ端末１−１に書き換えられたＦＩＮパケットを送信する（Ｓ５０５、ＳＱ２１８）。

ユーザ端末１−１に送信されるコンテンツを含むパケットのＡＣＫ番号及びシーケンス番号も、ＳＱ２１２の場合と同様に、ユーザ端末１−１とＷｅｂサーバ６−１との間のＴＣＰコネクションの確立時に用いられたＡＣＫ番号及びシーケンス番号が引き続き用いられる。

中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛てのＡＣＫパケットを受信すると（ＳＱ２１９）、監視処理Ｓ１００を開始する。

当該監視処理Ｓ１００は、ＳＱ２１５の後に実行される監視処理Ｓ１００と同様のフローとなる。すなわち、データ中継部３５６にＡＣＫ受信通知が出力される（Ｓ２０２）。

このとき、データ中継処理Ｓ５００では、データ中継部３５６が、代理応答情報のＷｅｂサーバ側情報（Ｔ３４）に基づいてＡＣＫパケットのヘッダを書き換え、サービス２側インタフェース３４３を介してＷｅｂサーバ６−１に書き換えられたＡＣＫパケットを送信する（Ｓ５０６、ＳＱ２２０）。

Ｗｅｂサーバ６−１に送信されるＡＣＫパケットのＡＣＫ番号及びシーケンス番号は、中継装置３とＷｅｂサーバ６−１との間の新たなＴＣＰコネクションの確立時に用いられたＡＣＫ番号及びシーケンス番号が引き続き用いられる。

中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛てのＦＩＮパケットを受信すると（ＳＱ２２１）、監視処理Ｓ１００を開始する。

監視処理Ｓ１００では、監視部３５２は、コネクション状態（Ｔ１３）が「代理応答中」デあるため、ユーザ側代理応答処理Ｓ２００を開始する。ユーザ側代理応答処理Ｓ２００では、監視部３５２は、受信したパケットがＦＩＮパケットであるか否かを判定する（Ｓ２０３）。ここでは、受信したパケットはＦＩＮパケットであるため、監視部３５２は、データ中継部３５６にＦＩＮ受信通知を出力する（Ｓ２０４）。

このとき、データ中継処理Ｓ５００では、データ中継部３５６が、代理応答情報のＷｅｂサーバ側情報（Ｔ３４）に基づいてＦＩＮパケットのヘッダを書き換え、サービス２側インタフェース３４３を介してＷｅｂサーバ６−１に書き換えられたＦＩＮパケットを送信する（Ｓ５０７、ＳＱ２２２）。

Ｗｅｂサーバ６−１に送信されるＦＩＮパケットのＡＣＫ番号及びシーケンス番号は、中継装置３とＷｅｂサーバ６−１との間の新たなＴＣＰコネクションの確立時に用いられたＡＣＫ番号及びシーケンス番号が引き続き用いられる。

中継装置３がＷｅｂサーバ６−１から中継装置３宛てのＡＣＫパケットを受信すると（ＳＱ２２３）、データ中継部３５６は、代理応答情報のユーザ端末側情報（Ｔ３３）に基づいてＡＣＫパケットのヘッダを書き換え、ユーザ側インタフェース３４１を介してユーザ端末１−１に書き換えられたＡＣＫパケットを送信する（Ｓ５０８、ＳＱ２２４）。その後、データ中継部３５６は、コネクション管理テーブル（Ｔ１）からコネクション情報を削除し、代理応答テーブル（Ｔ３）から代理応答情報を削除する（Ｓ５０９）。

ユーザ端末１−１に送信されるコンテンツを含むパケットのＡＣＫ番号及びシーケンス番号も、ＳＱ２１２の場合と同様に、ユーザ端末１−１とＷｅｂサーバ６−１との間のＴＣＰコネクションの確立時に用いられたＡＣＫ番号及びシーケンス番号が引き続き用いられる。

動作例２では、ユーザ端末１−１は、Ｗｅｂサーバ６−１との間で確立されたＴＣＰコネクションの情報（ＡＣＫ番号及びシーケンス番号）を用いてＷｅｂサーバ６−１宛にパケットを送信すればよく、サービス経路４の切り替えが意識する必要はない。また、サービス経路４の切り替え時には、ユーザ端末１−１と中継装置３との間のＴＣＰコネクションは維持されるため、ユーザ端末１−１からは、サービス経路４の切り替え時におけるＴＣＰコネクションの切断は認識されない。すなわち、中継装置３は、ユーザ端末１−１には特に変更を行うことなく、サービス経路４を切り替えることができる。

（動作例３）
図１６は、本発明の実施例の通信システムにおけるサービス経路４が切り替えられない場合の通信の流れを示すシーケンス図である。

動作例３は、動作例１とほぼ同一の動作であるが、ＨＴＴＰリクエストが複数のパケットに分割されて送信される点が異なる。以下、動作例１との差異を中心に、動作例３について説明する。

ＴＣＰコネクションを確立するまでの処理は動作例１と同一であるため省略する。

中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛てのＨＴＴＰリクエスト１／２を受信すると（ＳＱ３０１）、監視処理Ｓ１００を開始する。監視処理Ｓ１００では、監視部３５２は、Ｓ１０５の条件を満たさないためルール判定部３５４に処理の実行を指示する。

ルール判定処理Ｓ３００では、ルール判定部は、ＨＴＴＰリクエスト全体を受信したか否かを判定する（Ｓ３０１）。ここでは、ＨＴＴＰリクエスト全体を受信していないため、ルール判定部３５４は、パケット格納部３３に受信したＨＴＴＰリクエストパケットをコピーし（Ｓ３０８）、コネクション情報のパケットポインタ（Ｔ１８）に当該パケットが格納される一を示すポインタを設定する（Ｓ３０９）。さらに、ルール判定部３５４は、コネクション状態（Ｔ１７）を「ＨＴＴＰリクエスト一部受信」に更新する（Ｓ３１０）。その後、ルール判定部３５４は、サービス１側インタフェース３４２を介してＷｅｂサーバ６−１に受信したＨＴＴＰリクエストパケットを送信する（Ｓ３１１、ＳＱ３０２）。

中継装置３は、Ｗｅｂサーバ６−１からユーザ端末１−１宛てのＡＣＫパケットを受信すると（ＳＱ３０３）、応答処理Ｓ６００を開始する。

当該応答処理Ｓ６００は、ＳＱ１０９の後に実行される応答処理Ｓ６００と同様のフローとなる。すなわち、応答部３５３は、ユーザ側インタフェース３４１を介してユーザ端末１−１に受信したＡＣＫパケットを送信する（Ｓ６０６、ＳＱ３０４）。

中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛てのＨＴＴＰリクエスト２／２を受信すると（ＳＱ３０５）、監視処理Ｓ１００を開始する。

監視処理Ｓ１００では、監視部３５２は、Ｓ１０５の条件を満たさないためルール判定部３５４に処理の実行を指示する。

ルール判定処理Ｓ３００では、ルール判定部３５４は、ＨＴＴＰリクエスト全体を受信したと判定されるため、コネクション状態（Ｔ１７）が「ＨＴＴＰリクエスト一部受信」であるか否かを判定する（Ｓ３０２）。ここでは、コネクション状態（Ｔ１７）が「ＨＴＴＰリクエスト一部受信」であるため、ルール判定部３５４は、パケットポインタ（Ｔ１８）に基づいてパケット格納部３３からＨＴＴＰリクエストパケットを読み出す（Ｓ３０３）。ルール判定部３５４は、ＨＴＴＰリクエストがルールテーブル（Ｔ２）のいずれかのルールに該当するか否かを判定する（Ｓ３０４）。ここでは、該当するルールが存在しないため、ルール判定部３５４は、コネクション管理テーブル（Ｔ１）からコネクション情報を削除し（Ｓ３０７）、サービス１側インタフェース３４２を介してＷｅｂサーバ６−１に受信したＨＴＴＰリクエストパケット２／２を送信する（Ｓ３１１、ＳＱ３０６）。

中継装置３は、Ｗｅｂサーバ６−１からユーザ端末１−１宛てのＡＣＫパケットを受信すると（ＳＱ３０７）、応答処理Ｓ６００を開始する。

当該応答処理Ｓ６００は、ＳＱ１０９の後に実行される応答処理Ｓ６００と同様のフローとなる。すなわち、応答部３５３は、ユーザ側インタフェース３４１を介してユーザ端末１−１に受信したＡＣＫパケットを送信する（Ｓ６０６、ＳＱ３０８）。

図１６では、ＨＴＴＰリクエストが二つのパケットに分割された例を示したが本発明はこれに限定されない。ＨＴＴＰリクエストは三つ以上に分割されていてもよい。この場合、ＨＴＴＰリクエスト全体を受信するまではＳＱ３０１からＳＱ３０４までの処理が実行され、ＨＴＴＰリクエスト全体を受信するとＳＱ３０５からＳＱ３０８までの処理が実行される。

（動作例４）
図１７は、本発明の実施例の通信システムにおけるサービス経路４が切り替えられる場合の通信の流れを示すシーケンス図である。

動作例４は、動作例２とほぼ同一の動作であるが、ＨＴＴＰリクエストが複数のパケットに分割されて送信される点が異なる。以下、動作例２との差異を中心に、動作例４について説明する。

ＳＱ４０１からＳＱ４０４の処理は、ＳＱ３０１からＳＱ３０４までの処理と同一の処理であるため説明を省略する。

中継装置３は、ユーザ端末１−１からＷｅｂサーバ６−１宛のＨＴＴＰリクエストパケット２／２を受信すると（ＳＱ４０５）、監視処理Ｓ１００を開始する。当該監視処理Ｓ１００は、ＳＱ３０５の後に実行される監視処理Ｓ１００と同様のフローとなる。すなわち、監視部３５２は、ルール判定部３５４に処理の実行を指示する。

ルール判定処理Ｓ３００では、ルール判定部３５４は、ＨＴＴＰリクエストに該当するルールが存在するため、コネクション状態（Ｔ１７）を「代理応答中」に更新し（Ｓ３０５）、ＨＴＴＰリクエスト送信部３５５に処理の実行を指示する（Ｓ３０６）。

ＨＴＴＰリクエスト送信処理Ｓ４００では、ＨＴＴＰリクエスト送信部３５５は、代理応答テーブル（Ｔ３）に代理応答情報を登録し（Ｓ４０１）、ＲＳＴパケットを送信する（Ｓ４０２、ＳＱ４０６）。ＨＴＴＰリクエスト送信部３５５は、新たなＴＣＰコネクションの確立し、代理応答情報の更新する（Ｓ４０３、ＳＱ４０７）。ＨＴＴＰリクエスト送信部３５５は、代理応答情報のＷｅｂサーバ側情報（Ｔ３４）に基づいてＨＴＴＰリクエストパケット１／２及びＨＴＴＰリクエストパケット２／２のそれぞれのヘッダを書き換え、サービス２側インタフェース３４３を介してＷｅｂサーバ６−１に書き換えられたＨＴＴＰリクエストパケット１／２及びＨＴＴＰリクエストパケット２／２を送信する（Ｓ４０４、ＳＱ４０８、ＳＱ４０９）。

中継装置３がＷｅｂサーバ６−１から中継装置３宛てのＡＣＫパケットを受信すると（ＳＱ４１０、ＳＱ４１１）、ＨＴＴＰリクエスト送信部３５５は、代理応答情報のユーザ端末側情報（Ｔ３３）に基づいてＡＣＫパケットのヘッダを書き換え、ユーザ側インタフェース３４１を介してユーザ端末１−１に書き換えられたＡＣＫパケットを送信する（Ｓ４０５、ＳＱ４１２）。

図１７では、ＨＴＴＰリクエストが二つのパケットに分割された例を示したが本発明はこれに限定されない。ＨＴＴＰリクエストは三つ以上に分割されていてもよい。この場合、ＨＴＴＰリクエスト全体を受信するまではＳＱ３０１からＳＱ３０４までの処理が実行され、ＨＴＴＰリクエスト全体を受信するとＳＱ４０５からＳＱ４０８までの処理が実行される。

以上で説明したように、本発明によれば、ユーザ端末１及びＷｅｂサーバ６等の既存のネットワーク構成を大幅に変更することなく、かつ、ユーザ端末１及びＷｅｂサーバ６に特別な操作をさせることなく、中継装置３は、ＨＴＴＰ上のアプリケーション及びデータの種類等のＨＴＴＰリクエストの解析結果に基づいて、サービス経路４を切り替えることができる。また、中継装置３は、ユーザ端末１からは経路の切り替えを意識させることなく、サービス経路４を切り替えることができる。

これによって、オフロード用の通信経路に振り分けることが可能となり、他のユーザトラフィックへ影響させないトラフィックオフロードが可能となる。また、アプリケーション及びデータの種類によって特徴の異なるサービス経路を切り替え、使用するサービス網ごとに異なる料金を徴収する新たな課金が可能となる。

本実施例では、サービス経路４が二つある場合を例に説明したが、サービス経路４は三つ以上あってもよい。この場合、ルールテーブル（Ｔ２）のルールに新たにサービス経路のカラムを対応付ければよい。これによって、中継装置３は、ＨＴＴＰリクエスト条件（Ｔ２６）に該当するＨＴＴＰリクエストパケットを受信した場合、ルールに対応付けられるサービス経路４を特定し、当該サービス経路４との間で新たなＴＣＰコネクションを確立する。

また、本実施例では、ＨＴＴＰを用いた通信を例に説明したが、ＳＩＰなど、ＴＣＰが上位階層のプロトコルとなる通信プロトコルを利用するアプリケーションであれば同様の取り扱いをすることができる。

なお、本実施例では、ソフトウェアによる制御を用いた例について説明したが、その一部をハードウェアによって実現することも可能である。

以上、本発明を添付の図面を参照して詳細に説明したが、本発明はこのような具体的構成に限定されるものではなく、添付した請求の範囲の趣旨内における様々な変更及び同等の構成を含むものである。

１ ユーザ端末
２ ルータ
３ 中継装置
４ サービス経路
５ インターネット
６ Ｗｅｂサーバ
３１ プロセッサ
３２ テーブル格納部
３３ パケット格納部
３４ インタフェース部
３５ 命令格納部
３２１ コネクション管理テーブル
３２３ 代理応答テーブル
３４１ ユーザ側インタフェース
３４２ サービス１側インタフェース
３４３ サービス２側インタフェース
３５１ ＴＣＰ管理部
３５２ 監視部
３５３ 応答部
３５４ ルール判定部
３５５ ＨＴＴＰリクエスト送信部
３５６ データ中継部

Claims (10)

1. ＴＣＰを利用して通信するアプリケーションが稼働する端末と、前記アプリケーションが要求するデータを送信するサーバとの間で送受信するデータを転送する中継装置であって、
   前記中継装置は、プロセッサ、前記プロセッサに接続されるメモリ、及び前記プロセッサに接続され、他の装置と接続するための複数のネットワークインタフェースを備え、
   前記中継装置は、第１のネットワークを介して前記端末と接続し、第２のネットワークに含まれる複数の通信経路を介して前記サーバと接続し、
   前記中継装置は、
   前記第１のネットワーク及び前記第２のネットワークに含まれる一つの前記通信経路を介して前記端末と前記サーバとの間に確立されたＴＣＰコネクションを用いて送受信されるパケットを監視するＴＣＰ管理部と、
   前記ＴＣＰ管理部によって、前記端末上で稼働する前記アプリケーションが前記サーバにデータの送信を要求するリクエストパケットの受信が検知された場合、前記リクエストパケットを解析し、前記解析の結果に基づいて前記リクエストパケットを送信する前記第２のネットワークの通信経路を切り替えるか否かを判定する判定部と、
   前記判定部によって新たな前記第２のネットワークの通信経路に切り替えると判定された場合、新たな通信経路上に前記中継装置及び前記サーバが通信するための新たなＴＣＰコネクションを確立し、前記新たなＴＣＰコネクションを用いて前記リクエストパケットを前記サーバに送信するリクエスト送信部と、
   前記新たなＴＣＰコネクションを用いて、前記アプリケーションが要求するデータを含むデータ格納パケットを前記端末に転送するデータ中継部と、を備えることを特徴とする中継装置。
2. 請求項１に記載の中継装置であって、
   前記ＴＣＰコネクションを用いて通信する場合に用いられる端末側情報、及び、前記新たなＴＣＰコネクションを介して通信する場合に用いられるサーバ側情報が対応付けられた変換情報を保持し、
   前記端末側情報は、前記端末のアドレス、前記端末のポート番号、前記端末が通信に用いるシーケンス番号、及び前記端末が通信に用いるＡＣＫ番号を含み、
   前記サーバ側情報は、前記中継装置のアドレス、前記中継装置のポート番号、前記中継装置が通信に用いるシーケンス番号、及び前記中継装置が通信に用いるＡＣＫ番号を含み、
   前記端末と前記サーバとの間で送受信されるパケットは、送信元アドレス、送信元ポート番号、宛先アドレス、宛先ポート番号、シーケンス番号、及びＡＣＫ番号を含み、
   前記リクエスト送信部は、
   前記変換情報の前記サーバ側情報に基づいて、前記リクエストパケットの前記送信元アドレス、前記送信元ポート番号、前記シーケンス番号、及び前記ＡＣＫ番号を書き換えて、
   書き換えられた前記リクエストパケットを前記サーバに送信し、
   前記データ中継部は、
   前記サーバから前記データ格納パケットを受信した場合、前記変換情報の前記端末側情報に基づいて、前記データ格納パケットの前記宛先アドレス、前記宛先ポート番号、前記シーケンス番号、及び前記ＡＣＫ番号を書き換えて、
   書き換えられた前記データ格納パケットを前記端末に送信することを特徴とする中継装置。
3. 請求項２に記載の中継装置であって、
   前記リクエスト送信部は、
   前記リクエストパケットから取得された前記端末のアドレス、前記端末のポート番号、前記端末が通信に用いるシーケンス番号、及び前記端末が通信に用いるＡＣＫ番号を前記端末側情報として設定し、
   前記新たなＴＣＰコネクションの確立時に決定された前記中継装置のアドレス、前記中継装置のポート番号、前記中継装置が通信に用いるシーケンス番号、及び前記中継装置が通信に用いるＡＣＫ番号を前記サーバ側情報として設定することを特徴とする中継装置。
4. 請求項２に記載の中継装置であって、
   前記アプリケーションが前記サーバとの通信に用いる通信プロトコルに関する条件を含むルールを複数格納するルール情報を保持し、
   前記判定部は、
   前記解析の結果に基づいて前記ルール情報を参照し、前記リクエストパケットに該当する前記ルールが存在するか否かを判定し、
   前記リクエストパケットに該当する前記ルールが存在すると判定された場合、前記リクエストパケットを送信する通信経路を切り替えると判定することを特徴とする中継装置。
5. 請求項２に記載の中継装置であって、
   前記リクエスト送信部は、前記リクエストパケットを送信する通信経路を切り替えると判定された場合、現在使用している通信経路上の前記ＴＣＰコネクションを切断するための初期化パケットを当該通信経路上の前記ＴＣＰコネクションを用いて前記サーバに送信することを特徴とする中継装置。
6. ＴＣＰを利用して通信するアプリケーションが稼働する端末と、前記アプリケーションが要求するデータを送信するサーバとの間で送受信するデータを転送する中継装置におけるデータ転送方法であって、
   前記中継装置は、プロセッサ、前記プロセッサに接続されるメモリ、及び前記プロセッサに接続され、他の装置と接続するための複数のネットワークインタフェースを備え、
   前記中継装置は、第１のネットワークを介して前記端末と接続し、第２のネットワークに含まれる複数の通信経路を介して前記サーバと接続し、
   前記データ転送方法は、
   前記中継装置が、前記第１のネットワーク及び前記第２のネットワークに含まれる一つの前記通信経路を介して前記端末と前記サーバとの間に確立されたＴＣＰコネクションを用いて送受信されるパケットを監視する第１のステップと、
   前記中継装置が、前記端末上で稼働する前記アプリケーションが前記サーバにデータの送信を要求するリクエストパケットの受信が検知された場合、前記リクエストパケットを解析し、前記解析の結果に基づいて前記リクエストパケットを送信する前記第２のネットワークの通信経路を切り替えるか否かを判定する第２のステップと、
   前記中継装置が、新たな前記第２のネットワークの通信経路に切り替えると判定した場合、新たな通信経路上に前記中継装置及び前記サーバが通信するための新たなＴＣＰコネクションを確立し、前記新たなＴＣＰコネクションを用いて前記リクエストパケットを前記サーバに送信する第３のステップと、
   前記中継装置が、前記新たなＴＣＰコネクションを用いて、前記アプリケーションが要求するデータを含むデータ格納パケットを前記端末に転送する第４のステップと、を含むことを特徴とするデータ転送方法。
7. 請求項６に記載のデータ転送方法であって、
   前記ＴＣＰコネクションを用いて通信する場合に用いられる端末側情報、及び、前記新たなＴＣＰコネクションを介して通信する場合に用いられるサーバ側情報が対応付けられた変換情報を保持し、
   前記端末側情報は、前記端末のアドレス、前記端末のポート番号、前記端末が通信に用いるシーケンス番号、及び前記端末が通信に用いるＡＣＫ番号を含み、
   前記サーバ側情報は、前記中継装置のアドレス、前記中継装置のポート番号、前記中継装置が通信に用いるシーケンス番号、及び前記中継装置が通信に用いるＡＣＫ番号を含み、
   前記端末と前記サーバとの間で送受信されるパケットは、送信元アドレス、送信元ポート番号、宛先アドレス、宛先ポート番号、シーケンス番号、及びＡＣＫ番号を含み、
   前記第３のステップは、
   前記変換情報の前記サーバ側情報に基づいて、前記リクエストパケットの前記送信元アドレス、前記送信元ポート番号、前記シーケンス番号、及び前記ＡＣＫ番号を書き換えるステップと、
   書き換えられた前記リクエストパケットを前記サーバに送信するステップと、を含み、
   前記第４のステップは、
   前記サーバから前記データ格納パケットを受信した場合、前記変換情報の前記端末側情報に基づいて、前記データ格納パケットの前記宛先アドレス、前記宛先ポート番号、前記シーケンス番号、及び前記ＡＣＫ番号を書き換えるステップと、
   書き換えられた前記データ格納パケットを前記端末に送信するステップと、を含むことを特徴とするデータ転送方法。
8. 請求項７に記載のデータ転送方法であって、
   前記第３のステップは、
   前記リクエストパケットから取得された前記端末のアドレス、前記端末のポート番号、前記端末が通信に用いるシーケンス番号、及び前記端末が通信に用いるＡＣＫ番号を前記端末側情報として設定するステップと、
   前記新たなＴＣＰコネクションの確立時に決定された前記中継装置のアドレス、前記中継装置のポート番号、前記中継装置が通信に用いるシーケンス番号、及び前記中継装置が通信に用いるＡＣＫ番号を前記サーバ側情報として設定するステップと、を含むことを特徴とするデータ転送方法。
9. 請求項７に記載のデータ転送方法であって、
   前記アプリケーションが前記サーバとの通信に用いる通信プロトコルに関する条件を含むルールを複数格納するルール情報を保持し、
   前記第２のステップは、
   前記解析の結果に基づいて前記ルール情報を参照し、前記リクエストパケットに該当する前記ルールが存在するか否かを判定するステップと、
   前記リクエストパケットに該当する前記ルールが存在すると判定された場合、前記リクエストパケットを送信する通信経路を切り替えると判定するステップと、を含むことを特徴とするデータ転送方法。
10. 請求項７に記載のデータ転送方法であって、
    前記第３のステップは、前記リクエストパケットを送信する通信経路を切り替えると判定された場合、現在使用している通信経路上の前記ＴＣＰコネクションを切断するための初期化パケットを当該通信経路上の前記ＴＣＰコネクションを用いて前記サーバに送信するステップを含むことを特徴とするデータ転送方法。

Images