JP2011205244A - 情報処理装置、経路制御装置、データ中継方法、及びプログラム - Google Patents

Abstract

【課題】メッセージの暗号化されたペイロードを中継時に復号化することなく一意性保証を実現させるための技術を提供する。
【解決手段】サーバ３は、端末装置１のユーザ用に生成したセッションを示すセッションＩＤを自身のＩＰアドレスと共に経路制御装置４に通知する。端末装置１は、中継装置２とのコネクション用のデータをセッションＩＤと共に経路制御装置４に通知する。経路制御装置４は、セッションＩＤによりコネクション用のデータとサーバ３のＩＰアドレスを対応付け、対応付けた組み合わせを中継設定情報として中継装置２に設定する。それにより中継装置２は、端末装置１からメッセージ１０１を受信した場合、そのメッセージ１０１から抽出したコネクション用のデータを用いた中継設定情報を参照し、そのメッセージ１０１の転送先を決定する。
【選択図】図２

Description

本発明は、通信ネットワークを介して端末装置のユーザがサーバの提供するサービスを利用するための技術に関する。

現在、インターネットに代表される通信ネットワークは広く社会に普及している。それにより、サーバを用いて、通信ネットワークと接続されたクライアントである端末装置のユーザを対象にした様々なサービスが提供されるようになっている。

サービスを提供するサーバは、端末装置から受信したメッセージによりセッションを生成し、その端末装置のユーザを対象にしたサービスを提供する。このセッションは、サーバが１端末装置にサービスを提供するうえでの単位に相当する。このセッションを生成したサーバは、端末装置への応答（レスポンス）とするメッセージに、生成したセッションを識別するための識別子であるセッションＩＤを挿入して送信する。セッションＩＤが挿入されたメッセージを受信した端末装置は以降、そのセッションＩＤを挿入したメッセージをサーバ宛てに送信する。それによりサーバは、端末装置から受信したメッセージ中のセッションＩＤにより、サービスの提供を継続させることができる。

通信ネットワークを介して提供するサービスは通常、多くの人の利用を想定する。利用する人が多くなるほど、サーバの負荷は増大する。このことから、サービスを提供する側は、複数のサーバを用意し、端末装置のユーザにサービスを提供させるサーバをそのうちの一つに振り分ける負荷分散を行うシステム構成を採用するのが普通である。この負荷分散を含む中継を行う中継装置は通常、ＳＬＢ（Server Load Balancer：負荷分散装置）と呼ばれる。

中継装置は、セッションＩＤとそのセッションＩＤが割り当てられたセッションを保持するサーバとの関係を表す情報を保存する。それにより中継装置は、セッションＩＤが挿入されたメッセージを端末装置から受信した場合、そのセッションＩＤを有する情報を保存しているか否か確認し、その確認結果に応じて、メッセージの振分先を決定する。決定される振分先は、セッションＩＤを有する情報が保存されていれば、その情報から特定されるサーバであり、セッションＩＤを有する情報が保存されていなければ、ラウンドロビン方式等の自律振分アルゴリズムにより選択したサーバである。そのように振分先を決定することにより中継装置は、同じ端末装置から送信される関連するメッセージは同じサーバに振り分ける一意性保証を実現する。この一意性保証を実現する機能は一意性保証機能（或いはセッション維持機能）と呼ばれる。この一意性保証の実現に用いる情報は以降「一意性保証情報」と呼ぶことにする。

近年、プライバシーに係わる情報の漏洩等を防止するために、メッセージの秘匿性が強く求められるようになってきている。その秘匿性の担保は通常、データの暗号化により実現される。データを暗号化して送受信する通信プロトコルとしては、ＳＳＬ（Secure Socket Layer）が広く用いられている。

図１は、通信ネットワークを介して送受信されるメッセージの構成を説明する図である。図１に示すメッセージは、ＨＴＴＰ（HyperText Transfer Protocol）を用いた場合のＨＴＴＰメッセージである。図１（ａ）には暗号化を行っていないメッセージの構成、図１（ｂ）にはＳＳＬによる暗号化を行ったメッセージの構成をそれぞれ示している。

通信ネットワーク上を転送されるメッセージは基本的に「ヘッダ＋ペイロード」という構成になっている。ヘッダには、メッセージ（パケット）を転送するために必要な情報が含まれ、ペイロードには、実際に転送したい情報が含まれる。ＨＴＴＰを用いたＨＴＴＰメッセージでは、図１に示すように、ヘッダとして、ＩＰ（Internet Protocol）ヘッダ、及びＴＣＰ（Transmission Control Protocol）ヘッダが格納される。ＴＣＰ／ＩＰより上のレイヤ（層）のデータ、つまりＨＴＴＰヘッダ、及びＨＴＴＰボディは、ペイロードとしてメッセージに格納される。ＨＴＴＰボディには、実際に転送したいデータが格納される。

ＩＰヘッダには、メッセージの送信元を表す送信元ＩＰアドレス、及びそのメッセージの送信先を表す宛先ＩＰアドレスが格納される。ＴＣＰヘッダには、送信元ＩＰアドレスのサブアドレスを表す送信元ポート番号、及び宛先ＩＰアドレスのサブアドレスを表す宛先ポート番号が格納される。

メッセージ中にセッションＩＤを格納する場所は普通、通信プロトコル毎に定義される。ＨＴＴＰメッセージでは、セッションＩＤを格納する場所はＨＴＴＰヘッダのＣｏｏｋｉｅフィールドである。このことから中継装置は、端末装置からＨＴＴＰメッセージを受信した場合、ＨＴＴＰヘッダのｃｏｏｋｉｅフィールドのデータを確認して、そのＨＴＴＰメッセージを転送すべきサーバを決定する。

図１（ｂ）に示すように、ＳＳＬによる暗号化では、ＨＴＴＰメッセージのペイロードであるＨＴＴＰヘッダ及びＨＴＴＰボディが暗号化される。このため従来は、中継装置が受信したＨＴＴＰメッセージのペイロードを復号して、ＨＴＴＰヘッダのｃｏｏｋｉｅフィールドのデータを確認することにより、一意性保証を実現させていた。

ＳＳＬを用いたメッセージの送受信では、ＳＳＬを用いた通信（セッション）の確立によって識別番号であるＳＳＬセッションＩＤが割り当てられる。このＳＳＬセッションＩＤは、一意性保証の実現に用いるのは望ましくない。その理由は、ＳＳＬセッションはサーバのセッションとは独立に確立されるからである。つまり、サーバのセッションが維持されている間、ＳＳＬセッションも維持されるとは保証できないからである。このため、従来は、ペイロードを復号して一意性保証を実現させていた。

中継装置の負荷は、受信したＨＴＴＰメッセージのペイロードの復号を行わせることにより、増大する。この負荷の増大は、メッセージの転送にかかる時間の増大によるサービスの質の低下、或いは必要とする中継装置の台数の増加、等の不具合を生じさせる。このことから、中継装置における負荷の増大は抑えることが重要である。

特開２００３−２０４３５０号公報 特開２００５−２８６８０２号公報 特表２００３−５０４７１４号公報 特表２００７−５０９５２１号公報

本発明は、メッセージの暗号化されたペイロードを中継時に復号化することなく一意性保証を実現させるための技術を提供することを目的とする。

本発明を適用した１システムでは、情報処理装置が、サーバから受信したセッションデータの有無を確認し、情報処理装置が、セッションデータがある場合、コネクションデータを生成し、情報処理装置が、経路制御装置にセッションデータおよびコネクションデータを送信し、経路制御装置が、受信したセッションデータを基にサーバのサーバアドレスを抽出し、経路制御装置が、コネクションデータおよびサーバアドレスを中継装置に送信し、情報処理装置が、経路制御装置より中継装置の中継設定の完了の通知を受信したとき、サーバに送信する送信データとセッションデータを暗号化して暗号化データを生成し、情報処理装置が、コネクションデータと暗号化データを含むメッセージを中継装置に送信し、中継装置が、受信したメッセージ中のコネクションデータを基にサーバアドレスを抽出し、中継装置が、抽出したサーバアドレスへ、メッセージを送信する.

本発明を適用した場合には、メッセージの暗号化されたペイロードを中継時に復号化することなく一意性保証を実現させることができる。

通信ネットワークを介して送受信されるメッセージの構成を説明する図である。 第１の実施形態による端末装置、及びその端末装置を用いてサービスを利用可能なサービス提供システムの構成を示す図である。 端末装置から送信されるメッセージの構成を説明する図である。 端末装置から経路制御装置に送信するメッセージの構成を説明する図である。 中継装置からサーバに転送されるメッセージの構成を説明する図である。 中継装置から端末装置に転送されるメッセージの構成を説明する図である。 サーバから中継装置に送信されるメッセージの構成を説明する図である。 サーバから経路制御装置に送信されるメッセージの構成を説明する図である。 経路制御装置から中継装置に送信されるメッセージの構成を説明する図である。 セッションＩＤテーブルの１エントリに格納されるデータを説明する図である。 中継設定テーブルの１エントリに格納されるデータを説明する図である。 セッションテーブルの１エントリに格納されるデータを説明する図である。 設定管理テーブルの１エントリに格納されるデータを説明する図である。 端末装置、中継装置、サーバ及び経路制御装置の各専用プログラムによって実現される処理を説明する図である。 リクエスト送信処理のフローチャートである。 応答取得処理のフローチャートである。 サーバ処理のフローチャートである。 サーバ側セッション情報収集処理のフローチャートである。 クライアント側セッション情報収集処理のフローチャートである。 設定受付処理のフローチャートである。 主信号リクエスト処理のフローチャートである。 主信号応答処理のフローチャートである。 本実施形態を適用可能なコンピュータのハードウェア構成の一例を示す図である。 第２の実施形態による端末装置、及びその端末装置を用いてサービスを利用可能なサービス提供システムの構成を示す図である。 第３の実施形態による端末装置、及びその端末装置を用いてサービスを利用可能なサービス提供システムの構成を示す図である。 セッション情報管理テーブルの１エントリに格納されるデータを説明する図である。 フック対象リストの１エントリに格納されるデータを説明する図である。 メッセージバッファテーブルの１エントリに格納されるデータを説明する図である。 コネクションＩＤマッピングテーブルの１エントリに格納されるデータを説明する図である。 ＳＳＬセッションＩＤマッピングテーブルの１エントリに格納されるデータを説明する図である。 コネクション管理テーブルの１エントリに格納されるデータを説明する図である。 第３の実施形態による端末装置１が実行するプログラムによって実現される処理を説明する図である。 第３の実施形態におけるリクエスト送信処理のフローチャートである。 通信路確立要求処理のフローチャートである。 代理要求処理のフローチャートである。 代理応答処理のフローチャートである。 コネクション削除処理のフローチャートである。 セッション情報保存処理のフローチャートである。 セッション情報通知処理のフローチャートである。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
＜第１の実施形態＞
図２は、第１の実施形態による端末装置、及びその端末装置を用いてサービスを利用可能なサービス提供システムの構成を示す図である。このサービス提供システムは、第１の実施形態による中継装置を用いて構築されたものであり、例えば１台以上の中継装置２、２台以上のサーバ３、及び１台の経路制御装置４が不図示の通信ネットワークを介して接続されている。図２には便宜的に、中継装置２及びサーバ３は１台のみ表している。

各サーバ３はそれぞれ、アプリケーション・プログラムであるサーバアプリケーション３１を実行することにより、クライアントである端末装置１のユーザにサービスを提供する。中継装置２は、端末装置１とサーバ３の間でメッセージの中継を行う。端末装置１からメッセージ１０１を受信した場合、そのメッセージ１０１を転送すべきサーバ３を決定し、決定したサーバ３にメッセージ１０１を転送する。

各サーバ３は、中継装置２を介して端末装置１からのメッセージ１０１を受信することにより、セッションを生成する。このときサーバ３は、生成したセッションに、そのセッションを識別するための識別子であるセッションＩＤを割り当てる。このセッションＩＤは、端末装置１に送信するメッセージ３０２中に挿入する。端末装置１は、継続してサービスを利用する場合、セッションＩＤを挿入したメッセージ１０１を送信する。このことからサーバ３は、端末装置１から受信したメッセージ１０１中にセッションＩＤがあるか否か確認し、そのセッションＩＤがない場合にセッションを生成する。以降、便宜的に、セッションＩＤが存在しないメッセージ１０１、つまりセッションを生成する契機となるメッセージは「初期メッセージ」と呼び、符号として１０１ａを付すこととする。セッションＩＤが存在するメッセージ１０１には符号として１０１ｂを付すこととする。１０１は、初期メッセージ１０１ａ、及びメッセージ１０１ｂの何れであっても良いメッセージに付すこととする。送信元を特定する必要がないメッセージには符号は付さないこととする。

端末装置１は、携帯電話機、ＰＤＡ、或いはパーソナルコンピュータ（ＰＣ）等の通信機能を備えたコンピュータ（情報処理装置）である。この端末装置１には、サーバ３が提供するサービスを利用可能とするプログラムであるクライアントアプリケーション１２が格納されている。それにより、端末装置１のユーザは、このクライアントアプリケーション１２を実行させることにより、サーバ３が提供するサービスを利用する。

サーバ３、及び端末装置１は、メッセージの秘匿性を担保するために、ペイロードを暗号化してメッセージを送信する。セッションＩＤ等のセッションの識別子はペイロードに格納されるのが普通である。このため、中継装置２は、受信したメッセージのペイロードを復号しなければ、セッションＩＤを確認することができない。セッションＩＤを確認できない場合、メッセージ１０１ｂを転送すべきサーバ３に転送する一意性保証は実現できない。しかし、復号は、中継装置２の負荷を増大させる。このことから本実施形態では、中継装置２に復号を行わせることなく、一意性保証を実現させている。

経路制御装置４は、ペイロードを復号することなく、一意性保証を可能とさせる情報（以降「中継設定情報」と表記）を中継装置２に提供する。その中継設定情報は、サーバ３、及び端末装置１からそれぞれ提供される情報を用いて生成する。以降、図３〜図１３も参照しつつ、中継設定情報を生成する仕組み、及びその中継設定情報を用いた中継を可能とする仕組みについて具体的に説明する。ここでは、端末装置１は中継装置２及び経路制御装置４とＬＡＮにより接続され、中継装置２、各サーバ３、及び経路制御装置４はＬＡＮに接続されていると想定する。通信ネットワークは、ＬＡＮ以外のもの、例えばＷＡＮ、インターネット等であっても良い。

クライアントアプリケーション１２を実行する端末装置１は、クライアント側アプリケーションセッション情報通知部１１、及び通信部１３を備えている。通信部１３は、ＬＡＮを介してメッセージの送受信を行う機能を備えている。メッセージ１０１のペイロードの暗号化／復号は、この通信部１３が行う。

図３は、端末装置から送信されるメッセージの構成を説明する図である。図３（ａ）は、初期メッセージ１０１ａ、つまりペイロードにセッションＩＤが挿入されていないセッション確立前のメッセージの構成を表している。図３（ｂ）は、ペイロードにセッションＩＤが挿入されているセッション確立後のメッセージ１０１ｂの構成を表している。

図３（ａ）及び（ｂ）に示すように、メッセージ１０１のペイロードはＬ２〜Ｌ４ヘッダを除く部分である。ＨＴＴＰを用いたメッセージ１０１では、そのペイロードの部分はＨＴＴＰヘッダ（図３中「ＨＴＴＰプロトコルヘッダ」と表記）、及びＨＴＴＰボディ（図３中「メッセージコンテンツ」と表記）を含んでいる（図１（ｂ）参照）。ＨＴＴＰヘッダには、Ｈｏｓｔフィールド、及びＲｅｑｕｅｓｔ−ＵＲＩフィールドが存在する。サーバアプリケーション３１は、それらのフィールドに格納するデータが表すＵＲＬによって指定される。セッション確立後のメッセージ１０１ｂには、セッションＩＤがｃｏｏｋｉｅフィールドのデータとして記述される。

Ｌ２（レイヤ２）ヘッダは、イーサネット（ＬＡＮ）に接続可能な機器が有する固有のＩＤ番号であるＭＡＣ（Media Access Control address）アドレス（イーサネットアドレス）によるデータ伝送用のヘッダである。このＬ２ヘッダには、送信元ＭＡＣアドレス（Ｓｏｕｒｃｅ ＭＡＣ）、及び宛先ＭＡＣアドレス（Ｄｅｓｔｉｎａｔｉｏｎ ＭＡＣ）が格納される。Ｌ３ヘッダ及びＬ４ヘッダは、例えば図１に示すＨＴＴＰメッセージにおけるＩＰヘッダ及びＴＣＰヘッダである。それにより、この２つのヘッダは、送信元ＩＰアドレス・ポート番号、及び宛先ＩＰアドレス・ポート番号を表している。

クライアントアプリケーション１２は、セッションＩＤを格納したセッションＩＤテーブル１５を管理する。このセッションＩＤテーブル１５の各エントリ（レコード）には、図１０に示すように、セッションＩＤと宛先ＩＰアドレスを格納するようにしている。セッションＩＤに宛先ＩＰアドレスを対応付けているのは、この宛先ＩＰアドレスはセッションＩＤと共にメッセージ１０１に格納するデータだからである。このメッセージ１０１は中継装置３を中継してサーバ３に転送されることから、宛先ＩＰアドレスは中継装置２のＩＰアドレスである。

クライアントアプリケーション１２は、サーバ３から応答のメッセージ３０２（中継装置２からメッセージ２０２として端末装置１に送信される）を受信すると、そのメッセージ３０２からセッションＩＤを抽出し、セッションＩＤテーブル１５の検索を行う。その検索により、セッションＩＤを格納したエントリを抽出できなかった場合、セッションＩＤテーブル１５に１エントリを追加する。追加したエントリには、メッセージ３０２中のセッションＩＤ、及び送信元ＩＰアドレス（ここでは送信元ポート番号を含む）を格納する。この送信元ＩＰアドレスは、宛先ＩＰアドレスとして格納する。

クライアントアプリケーション１２は、メッセージ１０１を送信する場合、そのメッセージ１０１の宛先ＩＰアドレス（ここではポート番号を含む）をキーにセッションＩＤテーブル１５を検索することにより、その宛先ＩＰアドレスを格納したエントリが存在するか否か確認する。それにより、該当するエントリが存在することを確認した場合、そのエントリのセッションＩＤ、その宛先ＩＰアドレス、及び送信元ＩＰアドレス（ここではポート番号を含む）と共にクライアント側アプリケーションセッション情報通知部１１に通知する。該当するエントリが存在するのは、メッセージ１０１ｂを送信する場合のみである。

クライアント側アプリケーションセッション情報通知部１１は、クライアントアプリケーション１２から通知されたセッションＩＤ、送信元ＩＰアドレス・ポート番号、及び宛先ＩＰアドレス・ポート番号をセッション情報として経路制御装置４に通知する。セッションＩＤと共に送信元ＩＰアドレス・ポート番号、及び宛先ＩＰアドレス・ポート番号を通知するのは、これらのデータは一意性保証を実現すべき端末装置１とサーバ３間のコネクション（対応関係）を識別できるものだからである。このことから以降、送信元ＩＰアドレス・ポート番号と宛先ＩＰアドレス・ポート番号の組み合わせは「コネクションＩＤ」と呼ぶこととする。本実施形態では、送信元ＩＰアドレス・ポート番号として端末装置１のＩＰアドレス・ポート番号、宛先ＩＰアドレス・ポート番号としてＨｏｓｔ及びＲｅｑｕｅｓｔ−ＵＲＩフィールドが表すサーバアプリケーション３１のＵＲＬを採用している。

図４は、端末装置１からセッション情報の通知のために送信するメッセージ１０２の構成を説明する図である。図４に示すように、Ｌ２ヘッダには送信元ＭＡＣアドレスとして端末装置１のＭＡＣアドレス、宛先ＭＡＣアドレスとして経路制御装置４のＭＡＣアドレスがそれぞれ格納されている。Ｌ３・Ｌ４ヘッダには、端末装置１のＩＰアドレス及びポート番号が送信元ＩＰアドレス及びポート番号として、経路制御装置４のＩＰアドレス及びポート番号が宛先ＩＰアドレス及びポート番号としてそれぞれ格納されている。経路制御装置４のＩＰアドレス及びポート番号は、その経路制御装置４がサーバに搭載されている場合、そのサーバのＩＰアドレス及びポート番号となる。ここでは便宜的に、経路制御装置４は専用の装置として、つまり１台のサーバとして実現されていると想定する。セッション情報は、メッセージ１０２のペイロードとして格納される。

メッセージ１０１は、ＴＣＰ以外の通信プロトコルを用いて送信することができる。その通信プロトコルとしては、例えばＵＤＰ（User Datagram Protocol）を挙げることができる。このことから図４では、コネクションＩＤのポート番号を得る通信プロトコルとしてＴＣＰ以外にＵＤＰを挙げている。

クライアントアプリケーション１２は、セッションＩＤを格納したセッションＩＤテーブル１５を管理する。このセッションＩＤテーブル１５の各エントリ（レコード）には、図１０に示すように、セッションＩＤと宛先ＩＰアドレスを格納するようにしている。セッションＩＤに宛先ＩＰアドレスを対応付けているのは、この宛先ＩＰアドレスはセッションＩＤと共にメッセージ１０１に格納するデータだからである。このメッセージ１０１は中継装置３を中継してサーバ３に転送されることから、宛先ＩＰアドレスは中継装置２のＩＰアドレスである。

中継装置２は、端末装置１から受信したメッセージ１０１のＬ２ヘッダの送信元ＭＡＣアドレスを自身のＭＡＣアドレス、宛先ＭＡＣアドレスをサーバ３のＭＡＣアドレスに変更する。また、Ｌ３・Ｌ４ヘッダの宛先ＩＰアドレス・ポート番号をサーバ３のＩＰアドレス・ポート番号に変更する。そのような変更を行うことにより生成したメッセージ２０１を送信する。このとき、Ｌ３・Ｌ４ヘッダに宛先ＩＰアドレス・ポート番号を格納するサーバ３は、受信したメッセージ１０１が初期メッセージ１０１ａであればラウンドロビン方式等の自律振分アルゴリズムにより選択したものである。初期メッセージ１０１ａでなければ、セッションを確立したサーバ３である。セッションを確立したサーバ３の判別方法等についての詳細は後述する。

図５は、中継装置からサーバに転送されるメッセージの構成を説明する図である。図５（ａ）は、初期メッセージ１０１ａの受信時に転送するセッション確立前のメッセージ２０１の構成を表している。図５（ｂ）は、セッション確立後に転送するメッセージ２０１の構成を表している。以降、メッセージ２０１を区別する必要がある場合、セッション確立前のメッセージ２０１の符号としては２０１ａ、セッション確立後のメッセージ２０１の符号としては２０１ｂを用いる。図５（ａ）及び（ｂ）に示すように、メッセージ２０１ａ、２０１ｂの主な相違は、初期メッセージ１０１ａ、１０ｂと同様に、ペイロードにおけるセッションＩＤの有無である。

サーバ３は、中継装置２からメッセージ２０１を受信すると、そのメッセージ２０１のペイロードを復号し、サーバアプリケーション３１に渡す。サーバアプリケーション３１は、ペイロードにセッションＩＤが存在するか否か確認することにより、セッションＩＤが存在しなければセッションを新たに確立し、そのセッションにセッションＩＤを割り当てる。また、継続したサービスを提供するために必要な情報を生成し保存する。

本実施形態では、セッションＩＤ、及び情報の保存にセッションテーブル３５を用いている。このセッションテーブル３５の各エントリ（レコード）には、図１２に示すように、セッションＩＤと、サービスの提供（サーバアプリケーション３１による処理の実行）に必要な情報（以降「セッション関連情報」）が格納される。セッションＩＤが存在しないメッセージ２０１ｂをサーバ３が受信した場合、サーバアプリケーション３１は、対応するセッション関連情報を必要に応じて更新する。

サーバアプリケーション３１は、受信したメッセージ２０１によりリクエストされたデータやセッションＩＤをペイロードに格納したメッセージ３０２を生成し、中継装置２に送信する。図７は、サーバから送信されるメッセージの構成を説明する図である。図７に示すように、Ｌ２ヘッダには送信元ＭＡＣアドレスとしてサーバ３のＭＡＣアドレス、宛先ＭＡＣアドレスとして経路制御装置４のＭＡＣアドレスがそれぞれ格納されている。Ｌ３・Ｌ４ヘッダには、送信元ＩＰアドレス及びポート番号としてサーバ３のＩＰアドレス及びポート番号、宛先ＩＰアドレス及びポート番号として端末装置１のＩＰアドレス及びポート番号がそれぞれ格納されている。

中継装置４は、サーバ３からメッセージ３０２を受信すると、Ｌ２ヘッダの送信元ＭＡＣアドレスを自身のＭＡＣアドレス、宛先ＭＡＣアドレスを端末装置１のＭＡＣアドレスに変更する。また、Ｌ３・Ｌ４ヘッダの送信元ＩＰアドレス・ポート番号を自身のＩＰアドレス・ポート番号に変更する。そのような変更を行うことで図６に示すようなメッセージ２０２を生成し端末装置１に送信する。このとき、端末装置１のＭＡＣアドレスは、Ｌ３・Ｌ４ヘッダに格納された宛先ＩＰアドレス・ポート番号から特定する。

サーバ３のサーバ側アプリケーションセッション情報通知部３２は、サーバアプリケーション３１が新たにセッションを生成した場合、そのセッションＩＤ、及びサーバアプリケーション３１のサービスを利用可能なサーバ３のＩＰアドレス及びポート番号（以降「サーバＩＰアドレス」と表記）を経路制御装置４に通知する。その通知は、図８に示すようなメッセージ３０１を生成して送信することで行う。そのメッセージ３０１には、ペイロードとして、セッションＩＤ、及びサーバＩＰアドレスがセッション情報として格納されている。ペイロードに格納されるサーバＩＰアドレスは、Ｌ３・Ｌ４ヘッダに格納される送信元ＩＰアドレス・ポート番号と必ず一致するものではない。つまり、それらは同じであっても良いが、異なっていても良い。

経路制御装置４は、サーバ側アプリケーションセッション情報収集部４１、クライアント側アプリケーションセッション情報収集部４２、中継設定生成部４３、及び設定部４４を備えている。サーバ３から受信したメッセージ３０１はサーバ側アプリケーションセッション情報収集部４１によって処理され、そのメッセージ３０１に格納されたセッション情報が抽出される。同様に、端末装置１から受信したメッセージ１０２はクライアント側アプリケーションセッション情報収集部４２によって処理され、そのメッセージ１０２に格納されたセッション情報が抽出される。各セッション情報収集部４１及び４２が抽出したセッション情報は中継設定生成部４３に出力される。

中継設定生成部４３は、各セッション情報収集部４１及び４２から収集したセッション情報の対応関係をセッションＩＤにより特定する。それにより、同じセッションＩＤが組み合わされたサーバＩＰアドレスとコネクションＩＤを対応付ける。上記中継設定情報は、このようにしてサーバＩＰアドレスとコネクションＩＤを対応付けることにより生成する情報である。生成した中継設定情報は、設定部４４に出力する。

中継設定生成部４３は、設定管理テーブル４５を用いて、中継設定情報の生成を管理する。この設定管理テーブル４５の各エントリ（レコード）には、図１３に示すように、対応付けたサーバＩＰアドレス、及びコネクションＩＤに加えて、セッションＩＤが格納可能となっている。それにより中継設定生成部４３は、メッセージ１０２、或いはメッセージ３０１の受信によりセッション情報がセッション情報収集部４１及び４２の何れかから入力した場合、設定管理テーブル４１を参照し、中継設定情報を生成すべきか否か判定する。それにより、コネクションＩＤの無いエントリに対して、そのコネクションＩＤが端末装置１から通知された場合にのみ、中継設定情報を生成する。中継設定情報を生成した場合には、該当するエントリにコネクションＩＤを格納する。

設定部４４は、中継設定生成部４３から中継設定情報を入力すると、その中継設定情報を中継装置２に通知するためのメッセージ４０１を生成し、中継装置２に送信する。このメッセージ４０１は、例えば図９に示すような構成であり、中継設定情報はペイロードとしてメッセージ４０１に格納されている。

経路制御装置４から送信されたメッセージ４０１は、中継装置２の設定受付部２４によって処理される。その設定受付部２４は、メッセージ４０１から中継設定情報を抽出し、抽出した中継設定情報を中継設定テーブル２５に格納する。

この中継設定テーブル２５の各エントリには、図１１に示すように、中継設定情報、つまりコネクションＩＤとサーバＩＰアドレスが格納されている。このことから設定受付部２４は、抽出した中継設定情報のコネクションＩＤをキーにした検索を行い、この検索結果に応じて中継設定情報の格納を行う。それにより、検索によってエントリを抽出できた場合、そのエントリに中継設定情報を上書きし、エントリを抽出できなかった場合には、１エントリを追加して、追加したエントリに中継設定情報を格納する。そのようにして、同一のコネクションＩＤが格納されたエントリは１つのみとする。

中継装置２は、上記設定受付部２４の他に、中継部２１、負荷分散部２２及び中継設定記録部２３を備えている。これら各部２１〜２３は、それぞれ以下のような動作を行う。
中継部２１は、中継設定テーブル２５を参照して、端末装置１とサーバ３間のメッセージの中継を実現させる。端末装置１からメッセージ１０１を受信した場合、Ｌ３・Ｌ４ヘッダから送信元、及び宛先のＩＰアドレス・ポート番号を抽出し、抽出したＩＰアドレス・ポート番号の組み合わせをキーにして中継設定テーブル２５を検索する。その検索によって、その組み合わせをコネクションＩＤとして格納したエントリを抽出した場合、つまりメッセージ１０１がメッセージ１０１ｂであった場合、Ｌ３・Ｌ４ヘッダの宛先ＩＰアドレス・ポート番号をそのエントリのサーバＩＰアドレスに変更する。メッセージ１０１ｂのＬ２ヘッダの送信元、及び宛先のＭＡＣアドレスはそれぞれ、自身のＭＡＣアドレス、そのサーバＩＰアドレスを持つサーバ３のＭＡＣアドレスに変更する。そのような変更によりメッセージ２０１ｂを生成し、サーバ３に送信する。そのようなエントリを抽出できなかった場合、メッセージ１０１は初期メッセージ１０１ａであるとして、負荷分散部２２に出力する。

負荷分散部２２は、自律振分アルゴリズムにより初期メッセージ１０１ａの転送先とするサーバ３を選択し、選択したサーバ３のＩＰアドレス・ポート番号を、Ｌ３・Ｌ４ヘッダの宛先ＩＰアドレス・ポート番号として格納することにより、メッセージ２０１ａを生成する。Ｌ２ヘッダの送信元ＭＡＣアドレスは自身のＭＡＣアドレス、宛先ＭＡＣアドレスは選択したサーバ３のＭＡＣアドレスに変更する。そのようにして生成したメッセージ２０１ａをサーバ３に送信し、初期メッセージ１０１ａのＬ３・Ｌ４ヘッダの送信元、及び宛先のＩＰアドレス・ポート番号、並びに選択したサーバ３のＩＰアドレス・ポート番号を中継設定記録部２３に通知する。

中継設定記録部２３は、負荷分散部２２から通知された送信元、及び宛先のＩＰアドレス・ポート番号をコネクションＩＤ、サーバ３のＩＰアドレス・ポート番号をサーバＩＰアドレスとして、中継設定テーブル２５に格納する。負荷分散部２２からこれらＩＰアドレス・ポート番号が通知されるのは、上述したように端末装置１から初期メッセージ１０１ａを受信した場合である。このことから、中継設定記録部２３は、中継設定テーブル２５に１エントリを追加し、追加したエントリにこれらのＩＰアドレス・ポート番号を中継設定情報として格納する。

上記中継部２１は、サーバ３からメッセージ３０２を受信した場合、メッセージ１０１ｂの受信時と同様のアドレス書き換え操作を行い、メッセージ２０２を生成する。受信したメッセージ３０２のＬ３・Ｌ４ヘッダの送信元ＩＰアドレス・ポート番号を自身のＩＰアドレス・ポート番号に変更し、Ｌ２ヘッダの送信元、宛先のＭＡＣアドレスはそれぞれ自身のＭＡＣアドレス、端末装置１のＭＡＣアドレスに変更する。そのような変更によりメッセージ２０２を生成し、端末装置１に送信する。

上記端末装置１、中継装置２、サーバ３及び経路制御装置４は何れも、コンピュータに専用のプログラムを実行させることで動作する。端末装置１は、クライアントアプリケーション１２をコンピュータに実行させることにより実現される。サーバ３はサーバアプリケーション３１をコンピュータに実行させることにより実現される。中継装置２はメッセージの中継を可能とさせるプログラム（以降「中継プログラム」）、経路制御装置４は中継装置２に中継設定情報を設定させるプログラム（以降「経路制御プログラム」）をそれぞれ実行させることにより実現される。ここで図２３を参照して、端末装置１、中継装置２、サーバ３或いは経路制御装置４として使用可能なコンピュータについて具体的に説明する。

図２３に示すコンピュータは、ＣＰＵ６１、メモリ６２、入力装置６３、出力装置６４、外部記憶装置６５、媒体駆動装置６６、及びネットワーク接続装置６７を有し、これらがバス６８によって互いに接続された構成となっている。図２３に示す構成は一例であり、これに限定されるものではない。

ＣＰＵ６１は、当該コンピュータ全体の制御を行う。
メモリ６２は、プログラムの実行、データ更新等の際に、外部記憶装置６５（あるいは可搬型の記録媒体７０）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等の半導体メモリである。ＣＰＵ６１は、プログラムをメモリ６２に読み出して実行することにより、全体の制御を行う。

入力装置６３は、例えば、キーボード、マウス等の操作装置を介したデータ入力を可能とするものである。操作装置と接続可能なインターフェース、或いは操作装置とインターフェースを含むものである。操作装置に対するユーザの操作を検出し、その検出結果をＣＰＵ６１に通知する。この操作装置はコンソール等であっても良い。

出力装置６４は、例えば表示装置、或いは表示装置と接続された表示制御装置である。外部記憶装置６５は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。

媒体駆動装置６６は、光ディスク、光磁気ディスク、或いはメモリカード等の可搬型の記録媒体７０にアクセスするものである。ネットワーク接続装置６７は、通信ネットワークを介して外部装置と通信を行うためのものである。

上記専用プログラムは、外部記憶装置６５、若しくは記録媒体７０に記録されているか、或いは通信ネットワークを介してネットワーク接続装置６７により取得される。その専用プログラムが外部記憶装置６５に格納されていると想定する場合、端末装置１、中継装置２、サーバ３及び経路制御装置４の各構成要素は、上記コンピュータの以下のような構成要素の組み合わせによって実現される。その組み合わせは、更に、端末装置１、中継装置２、サーバ３及び経路制御装置４は全て同じ通信ネットワーク（ＬＡＮ）に接続されていると想定した場合のものである。

端末装置１のクライアント側アプリケーションセッション情報通知部１１は、例えばＣＰＵ６１、メモリ６２、外部記憶装置６５、ネットワーク接続装置６７、及びバス６８によって実現される。セッションＩＤテーブル１５は、例えば外部記憶装置６５に保存され、必要に応じてメモリ６２に読み出されて参照、或いは更新される。

中継装置２の中継部２１、負荷分散部２２、及び設定受付部２４は共に、例えばＣＰＵ６１、メモリ６２、外部記憶装置６５、ネットワーク接続装置６７、及びバス６８によって実現される。中継設定記録部２３は、例えばＣＰＵ６１、メモリ６２、外部記憶装置６５及びバス６８によって実現される。中継設定テーブル２５は、例えば外部記憶装置６５に保存され、必要に応じてメモリ６２に読み出されて参照、或いは更新される。

サーバ３のサーバ側アプリケーションセッション情報通知部３２は、例えばＣＰＵ６１、メモリ６２、外部記憶装置６５、ネットワーク接続装置６７、及びバス６８によって実現される。セッションテーブル３５は、例えば外部記憶装置６５に保存され、必要に応じてメモリ６２に読み出されて参照、或いは更新される。

経路制御装置４のサーバ側アプリケーションセッション情報収集部４１、クライアント側アプリケーションセッション情報収集部４２、及び設定部４４は共に、例えばＣＰＵ６１、メモリ６２、外部記憶装置６５、ネットワーク接続装置６７、及びバス６８によって実現される。経路制御装置４と端末装置１を接続する通信ネットワークが、経路制御装置４、中継装置２及びサーバ３を接続する通信ネットワークと異なる場合、これら情報州中部４１及び４２を実現するネットワーク接続装置は異なることになる。具体的には、クライアント側アプリケーションセッション情報収集部４２は、例えばネットワーク接続装置６７の代わりにネットワーク接続装置６８を用いて実現されることとなる。

設定生成部４３は、例えばＣＰＵ６１、メモリ６２、外部記憶装置６５及びバス６８によって実現される。設定管理テーブル４５は、例えば外部記憶装置６５に保存され、必要に応じてメモリ６２に読み出されて参照、或いは更新される。

図１４は、端末装置１、中継装置２、サーバ３及び経路制御装置４の各専用プログラムによって実現される処理を説明する図である。図１４では便宜的に、装置１〜４の専用プログラムによって実現される処理は状況別に分けて示している。次に図１４を参照して、各装置１〜４の専用プログラムによって実現される処理について説明する。

端末装置１の専用プログラムであるクライアントアプリケーション１２は、何らかのリクエストであるメッセージ１０１を送信するためのリクエスト送信処理Ｆ１１を実現させる。そのメッセージ１０１への応答として送信されるメッセージ（メッセージ２０２）への対応のために、応答取得処理Ｆ１２を実現させる。

中継装置２の専用プログラムである中継プログラムは、設定受付処理Ｆ２１、主信号リクエスト処理Ｆ２２及び主信号応答処理Ｆ２３を実現させる。設定受付処理Ｆ２１は、経路制御装置４から送信される中継設定情報を中継設定テーブル２５に登録するために実行される。設定受付部２４は、この設定受付処理Ｆ２１の実行によって実現される。主信号リクエスト処理Ｆ２２は、端末装置１から受信したメッセージ１０１に対応するための処理である。中継部２１の一部、負荷分散部２２及び中継設定記録部２３は、この主信号リクエスト処理Ｆ２２の実行によって実現される。主信号応答処理Ｆ２３は、サーバ３から応答（レスポンス）として送信されるメッセージ３０２に対応するための処理である。中継部２１の残り部分は、この主信号応答処理Ｆ２３の実行によって実現される。

サーバ３の専用プログラムであるサーバアプリケーション３１は、端末装置１から中継装置２を介して転送されるメッセージ２０１に対応するためのサーバ処理Ｆ３１を実現させる。

経路制御装置４の専用プログラムである経路制御プログラムは、サーバ側セッション情報収集処理Ｆ４１及びクライアント側セッション情報収集処理Ｆ４２を実現させる。サーバ側セッション情報収集処理Ｆ４１は、サーバ３から送信されるメッセージ３０１に対応するために実行される。クライアント側セッション情報収集処理Ｆ４２は、端末装置１から送信されるメッセージ１０２への対応、及び中継装置２への中継設定情報の設定のために実行される。サーバ側アプリケーションセッション情報収集部４１は、サーバ側セッション情報収集処理Ｆ４１の実行によって実現される。クライアント側セッション情報収集部４２、中継設定生成部４３及び設定部４４は、クライアント側セッション情報収集処理Ｆ４２の実行によって実現される。

以降は、図１４に示した各処理について、図１５〜図２２に示す各フローチャートを参照して詳細に説明する。
始めに、端末装置１がクライアントアプリケーション１２によって実行するリクエスト送信処理Ｆ１１及び応答取得処理Ｆ１２について詳細に説明する。

図１５は、上記リクエスト送信処理Ｆ１１のフローチャートである。この図１５にフローチャートを示すリクエスト送信処理Ｆ１１は、ユーザがサービス提供システムへのアクセス、つまりサービス提供システムへのメッセージ１０１の送信を指示することを契機に実行される。そのアクセスの指示、つまりＵＲＬの指定は、ＵＲＬの入力、或いはＵＲＬが関連付けられたリンクのクリック等により行われる。図１５を参照して、始めにこのリクエスト送信処理Ｆ１１について詳細に説明する。

先ず、ステップＳ１１１では、クライアントアプリケーション１２は、ユーザが指定したメッセージ１０１を送信するＵＲＬ（宛先ＵＲＬ）をキーに、セッションＩＤテーブル１５（図１０）を検索する。続くステップＳ１１２では、クライアントアプリケーション１２は、その検索結果から、キーとしたＵＲＬ（ＩＰアドレス）と対応付けたセッションＩＤが有るか否か判定する。検索によって、キーとしたＵＲＬを格納するエントリを抽出できた場合、判定はＹＥＳとなってステップＳ１１３に移行する。そのようなエントリを抽出できたなかった場合、判定はＮＯとなってステップＳ１１７に移行する。

ステップＳ１１３では、クライアントアプリケーション１２は、メッセージ（リクエスト）を送信するコネクションを決定する。このコネクションの決定では、宛先ＩＰアドレス・ポート番号としてユーザが指定したＵＲＬを選択し、送信元ＩＰアドレスとして端末装置１に事前設定されたＩＰアドレスを選択し、送信元ポート番号として、空いているポート番号から一つを選択する。次のステップＳ１１４では、クライアントアプリケーション１２は、決定した送信元ＩＰアドレス・ポート番号、宛先ＩＰアドレス・ポート番号、及びセッションＩＤをセッション情報として、クライアント側セッション情報通知処理に引数として渡す。その次に移行するステップＳ１１５では、クライアントアプリケーション１２はこの通知処理を実行する。

この通知処理は、セッション情報を経路制御装置４に通知するための処理である。図４に示すメッセージ１０２の生成、及び経路制御装置４への送信は、この通知処理を実行することで実現される。そのメッセージ１０２を受信した経路制御装置４は、端末装置１に、そのメッセージ１０２を処理した旨を示すメッセージである処理完了応答を返信する。このことからクライアントアプリケーション１２は、ステップＳ１１５でクライアント側セッション情報通知処理を実行した後、ステップＳ１１６に移行して、経路制御装置４から処理完了応答を取得するのを待つ。ステップＳ１１８には、処理完了応答を取得した後に移行する。図２に示すクライアント側アプリケーションセッション情報通知部１１は、これらステップＳ１１５及びＳ１１６の実行によって実現される。これらステップＳ１１５及びＳ１１６は、クライアントアプリケーション１２を構成するサブプログラムにより実現、つまりサブルーチン処理として実行される。

上記ステップＳ１１２の判定がＮＯとなって移行するステップＳ１１７では、クライアントアプリケーション１２は、ステップＳ１１３と同様にして、メッセージを送信するコネクションを決定する。次に移行するステップＳ１１８では、クライアントアプリケーション１２は、中継装置２との間にコネクションを確立し、ペイロードを暗号化したメッセージ１０１を生成して送信する。その後、このリクエスト送信処理を終了する。

図１６は、上記応答取得処理Ｆ１２のフローチャートである。この図１６にフローチャートを示す応答取得処理Ｆ１２は、中継装置２を介してサーバ３からのメッセージ（レスポンス）２０２の受信を契機に実行される。次に図１６を参照して、この押送取得処理Ｆ１２について詳細に説明する。

先ず、ステップＳ１２１では、クライアントアプリケーション１２は、端末装置１が受信したメッセージ２０２を受け取る。続くステップＳ１２２では、クライアントアプリケーション１２は、メッセージ２０２のペイロードを復号化して、セッションＩＤがＨＴＴＰヘッダに記載されているか否か確認する。それにより、ＨＴＴＰヘッダにセッションＩＤが記載されていないことを確認した場合、その旨が判定され、ここで応答取得処理を終了する。一方、ＨＴＴＰヘッダにセッションＩＤが記載されていることを確認した場合には、その旨が判定されてステップＳ１２３に移行する。

ステップＳ１２３では、クライアントアプリケーション１２は、ＨＴＴＰヘッダのセッションＩＤ、及びＬ３・Ｌ４ヘッダの送信元ＩＰアドレス・ポート番号（図１６中「ＵＲＬ」と表記）をそれぞれ抽出し、セッションＩＤテーブル１５に書き込む。その書き込みは、例えばセッションＩＤをキーにセッションＩＤテーブルを検索し、その検索によって抽出したエントリが存在すれば、そのエントリに対して行う。その検索によってエントリを抽出できなければ、１エントリを追加し、追加したエントリに対して行う。そのようにしてセッションＩＤテーブル１５を更新した後、この応答取得処理を終了する。

端末装置１では、上述したような内容のリクエスト送信処理Ｆ１１及び応答取得処理Ｆ１２がクライアントアプリケーション１２によって実行される。それにより、サーバ３が提供するサービスを利用する場合に、セッションＩＤテーブル１５の更新、及びメッセージ１０２の生成・送信によるセッション情報の経路制御装置４への通知が行われる。

次に、サーバ３でのサーバ処理Ｆ３１について詳細に説明する。
図１７は、サーバ３がサーバアプリケーション３１によって実行するサーバ処理のフローチャートである。次に図１７を参照して、このサーバ処理について詳細に説明する。この図１７のフローチャートは、中継装置２から送信された１メッセージ２０１に対応するために実行する処理の流れを示したものである。

先ず、ステップＳ３１１では、サーバアプリケーション３１は、サーバ３が受信したメッセージ２０１を受け取る。続くステップＳ３１２では、サーバアプリケーション３１は、メッセージ２０１のペイロードを復号化する。その後に移行するステップＳ３１３では、サーバアプリケーション３１は、ＨＴＴＰヘッダのｃｏｏｋｉｅフィールドからセッションＩＤの抽出できたか否か確認する。それにより、ＨＴＴＰヘッダからセッションＩＤを抽出できなかった場合、その旨が判定され、ステップＳ３１８に移行する。一方、ＨＴＴＰヘッダからセッションＩＤを抽出できた場合には、その旨が判定されてステップＳ３１４に移行する。

ステップＳ３１４では、サーバアプリケーション３１は、抽出したセッションＩＤをキーにセッションテーブル３５（図１２）を検索し、そのセッションＩＤに対応付けられたセッション関連情報を取得する。続くステップＳ３１５では、サーバアプリケーション３１は、取得したセッション関連情報を用いて、ペイロード中のデータによって指定される処理（図１７中「同アプリケーションセッション処理」と表記）を実行する。その後、サーバアプリケーション３１は、ステップＳ３１６で応答とするメッセージ３０２の生成、次のステップＳ３１７で生成したメッセージ３０２の送信を行う。その送信を行った後、このサーバ処理を終了する。

メッセージ３０２の生成は、受信したメッセージ２０１のＬ２〜Ｌ４ヘッダの送信元、宛先を入れ換え、ＨＴＴＰヘッダのＳｅｔ−ｃｏｏｋｉｅフィールド（図７参照）にセッションＩＤ、ＨＴＴＰボディにリクエストされたデータを格納することで行われる。ＨＴＴＰヘッダ、及びボディを含むペイロードは、暗号化する。それにより、図７に示すようなメッセージ３０２が生成・送信される。

上記ステップＳ３１３でセッションＩＤを抽出できないと判定した場合に移行するステップＳ３１８では、サーバアプリケーション３１は、セッション関連情報、及びセッションＩＤを生成し、これらのデータをセッションテーブル３５に登録する。この登録は、１エントリを追加し、追加したエントリにこれらのデータを格納することで行う。続くステップＳ３１９では、サーバアプリケーション３１は、サブルーチン処理であるサーバ側セッション情報通知処理（サブプログラム）に制御を渡す。

このサブプログラムは、サーバアプリケーション３１から制御が渡されると、サーバ３自身のＩＰアドレスを取得し、セッションＩＤと共に経路制御装置４に通知する。この通知は、図８に示すようなメッセージ３０１の生成、及び生成したメッセージ３０１の経路制御装置４への送信によって実現される。メッセージ３０１を受信した経路制御装置４は、そのメッセージ３０１を処理した旨を示すメッセージである処理完了応答をサーバ３に返信する。このサブプログラムの制御は、その処理完了応答を取得するのを待って、サーバアプリケーション３１に返す。図２に示すサーバ側アプリケーションセッション情報通知部３２は、このようなサブプログラム、つまりサーバ側セッション情報通知処理を実行することで実現される。処理完了応答の取得による制御のサーバアプリケーション３１への移行は、ステップＳ３２０で行われ、制御を受け取ったサーバアプリケーション３１は、次にステップＳ３１５の処理を実行することとなる。

次に、経路制御装置４が経路制御プログラムによって実行するサーバ側セッション情報収集処理Ｆ４１及びクライアント側セッション情報収集処理Ｆ４２について詳細に説明する。

図１８は、サーバ側セッション情報収集処理Ｆ４１のフローチャートである。この図１８のフローチャートは、サーバ３から受信した１メッセージ３０１に対応するための処理の流れを示したものである。始めに図１８を参照して、この収集処理Ｆ４１について詳細に説明する。

先ず、ステップＳ４１１では、経路制御プログラムは、受信したメッセージ３０１（図８）のペイロードからセッション情報、つまりセッションＩＤ、及びＩＰアドレスを収集する。続くステップＳ４１２では、経路制御プログラムは、収集したセッション情報を設定管理テーブル４５に登録する。その登録後は、ステップＳ４１３に移行して、経路制御プログラムは、メッセージ３０１を受信したサーバ３に、セッション情報を登録した旨を示すメッセージである登録完了通知を返信する。その後、このサーバ側セッション情報収集処理Ｆ４１を終了する。

セッション情報の登録は、実際には、セッション情報のセッションＩＤをキーにした設定管理テーブル４５の検索を行い、その検索によって抽出されるエントリが存在するか否か確認して行われる。それにより、エントリが抽出できれば、そのエントリにセッション情報を格納し、エントリを抽出できなければ、１エントリを追加し、追加したエントリにセッション情報を格納する。

図１９は、クライアント側セッション情報収集処理Ｆ４２のフローチャートである。この図１９のフローチャートも同様に、端末装置１から受信した１メッセージ１０２に対応するための処理の流れを示したものである。次に図１９を参照して、この収集処理Ｆ４２について詳細に説明する。

先ず、ステップＳ４２１では、経路制御プログラムは、受信したメッセージ１０２（図４）のペイロードからセッション情報、つまりセッションＩＤ、及びコネクションＩＤを収集する。続くステップＳ４２２では、経路制御プログラムは、そのセッションＩＤをキーにした設定管理テーブル４５の検索により１エントリを抽出し、そのエントリにコネクションＩＤを格納すると共に、そのエントリからサーバ３のＩＰアドレスを取得する。その後、ステップＳ４２３に移行する。

ステップＳ４２３では、経路制御プログラムは、取得したＩＰアドレスとコネクションＩＤを組み合わせて中継設定情報を生成する。次のステップＳ４２４では、経路制御プログラムは、生成した中継設定情報をペイロードに格納したメッセージ４０１（図９）を作成して中継装置２に送信することにより、その中継設定情報を付与する。その後、経路制御プログラムは、中継装置２から中継設定情報の設定完了を通知するメッセージである設定完了通知を受信するのを待ち（ステップＳ４２５）、その設定完了通知の受信後は中継設定情報の設定完了を通知するメッセージである設定完了通知を端末装置１に送信する（ステップＳ４２６）。その設定完了通知の送信後、このクライアント側セッション情報収集処理Ｆ４２を終了する。

このようにして端末装置１への設定完了通知は、中継設定情報が中継装置３に設定された後に送信される。このため、その設定完了通知の受信後に端末装置１から送信されるメッセージ１０１ｂは、中継装置２によって転送すべきサーバ３に転送されることとなる。

上述したように、クライアント側セッション情報収集処理Ｆ４２は、経路制御装置４のクライアント側セッション情報収集部４２、中継設定生成部４３及び設定部４４を実現させる。より具体的には、クライアント側セッション情報収集部４２は、上記ステップＳ４２１及びＳ４２６の処理を実行することで実現される。中継設定生成部４３は、上記ステップＳ４２２及びＳ４２３の処理を実行することで実現される。設定部４４は、上記ステップＳ４２４の処理を実行することで実現される。

最後に、中継装置２が中継プログラムによって実行する設定受付処理Ｆ２１、主信号リクエスト処理Ｆ２２及び主信号応答処理Ｆ２３について詳細に説明する。
図２０は、設定受付処理Ｆ２１のフローチャートである。この図２０のフローチャートは、経路制御装置４から受信した１メッセージ４０１に対応、つまり１中継設定情報を設定するための処理の流れを示したものである。中継装置２が実行する処理では、始めに図２０を参照して、この設定受付処理Ｆ２１について詳細に説明する。上述したように、図２の設定受付部２４は、この設定受付処理Ｆ２１を実行することで実現される。

先ず、ステップＳ２１１では、中継プログラムは、経路制御装置４から受信したメッセージ（図２０中では「中継設定配布メッセージ」と表記）４０１を取得する。続くステップＳ２１２では、中継プログラムは、メッセージ４０１のペイロードに格納されている中継設定情報のコネクションＩＤを取得し、このコネクションＩＤをキーにして中継設定テーブル２５を検索し、その検索結果を判定する。その検索の結果、コネクションＩＤを格納したエントリを抽出できた場合、ヒット（Ｈｉｔ）と判定され、ステップＳ２１３に移行する。一方、そのようなエントリを抽出できなかった場合、ミスヒット（Ｎｏｔ Ｈｉｔ）と判定され、ステップＳ２１４に移行する。

ステップＳ２１３では、中継プログラムは、抽出したエントリに、中継設定情報のＩＰアドレスを上書きする。一方、ステップＳ２１４では、中継プログラムは、１エントリを追加し、追加したエントリに中継設定情報、つまりキーにしたコネクションＩＤとそのコネクションＩＤに組み合わされたサーバ３のＩＰアドレスを格納する。ステップＳ２１３、或いはＳ２１４の処理の実行により中継設定テーブル２５を更新した後はステップＳ２１５に移行して、中継プログラムは、中継設定情報の設定完了を通知するメッセージである設定完了通知を経路制御装置４に返信する。その返信を行った後、設定受付処理を終了する。

図２１は、主信号リクエスト処理Ｆ２２のフローチャートである。この図２１のフローチャートは、端末装置１から受信した１メッセージ１０１に対応するための処理の流れを示したものである。次に図２１を参照して、このリクエスト処理Ｆ２２について詳細に説明する。

先ず、ステップＳ２２１では、中継プログラムは、端末装置１からメッセージ１０１を受信するのを待つ。メッセージ１０１を受信すると、ステップＳ２２２に移行して、中継プログラムは、受信したメッセージ１０１のＬ３・Ｌ４ヘッダからコネクションＩＤ、つまり送信元ＩＰアドレス・ポート番号、及び宛先ＩＰアドレス・ポート番号を抽出する。その抽出後はステップＳ２２３に移行する。

ステップＳ２２３では、中継プログラムは、抽出したコネクションＩＤをキーに中継設定テーブル２５を検索し、その検索結果を判定する。その検索の結果、コネクションＩＤを格納したエントリを抽出できなかった場合、ヒットしなかった（Ｎｏｔ Ｈｉｔ）と判定され、ステップＳ２２６に移行する。一方、そのようなエントリを抽出できた場合、ヒット（Ｈｉｔ）と判定され、ステップＳ２２４に移行する。

ステップＳ２２４では、中継プログラムは、受信したメッセージ１０１のＬ３・Ｌ４ヘッダの宛先ＩＰアドレス・ポート番号として、抽出したエントリの転送先サーバアドレス（ＩＰアドレス・ポート番号）を書き込むことにより、メッセージ２０１を作成する。次のステップＳ２２５では、中継プログラムは、作成したメッセージ２０１をサーバ３に送信する。その後、この主信号リクエスト処理Ｆ２２を終了する。

上記ステップＳ２２４で作成するメッセージ２０１は、図５（ｂ）に示すように、Ｌ２ヘッダの送信元ＭＡＣアドレスは中継装置２のＭＡＣアドレス、宛先ＭＡＣアドレスは転送先とするサーバ３のＭＡＣアドレスに書き換えられたものである。Ｌ３・Ｌ４ヘッダの送信元ＩＰアドレス・ポート番号は元のままである。

上記ステップＳ２２３でＮｏｔ Ｈｉｔと判定した場合に移行するステップＳ２２６では、中継プログラムは負荷分散アルゴリズムに従ってメッセージ１０１（１０１ａ）の転送先とするサーバ３を選択する。続くステップＳ２２７では、中継プログラムは、中継設定テーブル２５に１エントリを追加し、追加したエントリにコネクションＩＤと選択したサーバ３のＩＰアドレスを中継設定情報として記録する。その後、上記ステップＳ２２４に移行する。

上記したように、中継装置２の中継部２１の一部、負荷分散部２２及び中継設定記録部２３は、この主信号リクエスト処理Ｆ２２の実行によって実現される。より具体的には、中継部２１の一部は、ステップＳ２２１−Ｓ２２５の処理の実行によって実現される。負荷分散部２２は、ステップＳ２２６、Ｓ２２４及びＳ２２５の処理の実行によって実現される。中継設定記録部２３は、ステップＳ２２７の処理の実行によって実現される。

図２２は、主信号応答処理Ｆ２３のフローチャートである。この図２２のフローチャートも同様に、サーバ３から受信した１メッセージ３０２（図７）に対応するための処理の流れを示したものである。最後に図２２を参照して、この主信号応答処理Ｆ２３について詳細に説明する。サーバ３から端末装置１にメッセージを転送する中継部２１の機能は、この主信号相当処理Ｆ２３の実行により実現される。

先ず、ステップＳ２３１では、中継プログラムは、サーバ３からメッセージ３０２を受信するのを待つ。メッセージ３０２を受信すると、ステップＳ２３２に移行して、中継プログラムは、受信したメッセージ３０２のＬ２〜Ｌ４ヘッダの書き換えによりメッセージ２０２（図６）を作成する。その次のステップＳ２３３では、中継プログラムは、作成したメッセージ２０２を送信する。その送信を行った後、この主信号応答処理を終了する。

上記メッセージ２０２の作成では、受信したメッセージ３０２のＬ２ヘッダの送信元、及び宛先のＭＡＣアドレスＬとして中継装置２及び端末装置１のＭＡＣアドレスをそれぞれ格納する。Ｌ３・Ｌ４ヘッダの送信元ＩＰアドレス・ポート番号は中継装置２のＩＰアドレス・ポート番号に変更する。そのようにして、メッセージ３０２からメッセージ２０２が作成される。

＜第２の実施形態＞
セッションＩＤは、第３者に知られないようにすることが望ましい。これは、セッションＩＤを知った第３者は、セッションＩＤの所有者である端末装置１のユーザになりすますことができるからである。このようなことから、セッションＩＤを含むセッション情報をメッセージ１０２により経路制御装置４に通知する場合、そのメッセージ１０２の秘匿性の担保も必要と云える。このような理由から第２の実施形態は、メッセージ１０２の秘匿性を担保するようにしたものである。

メッセージ１０２の秘匿性を担保するために、第２の実施形態では、以下の点が第１の実施形態から異なっている。その異なっている点について、図２４を参照して具体的に説明する。その図２４は、第２の実施形態による端末装置、及びその端末装置を用いてサービスを利用可能なサービス提供システムの構成を示す図である。

第２の実施形態による端末装置１のクライアント側アプリケーションセッション情報通知部１１は、図２４に示すように、アプリケーションセッションＩＤ暗号化部１１ａを備えている。このＩＤ暗号化部１１ａは、例えばメッセージ１０２のペイロード、つまりセッション情報を暗号化するものである。それにより、端末装置１は、セッション情報を暗号化したメッセージ１０２を経路制御装置４に送信する。セッション情報の暗号化は、図１５にフローチャートを示すリクエスト送信処理Ｆ１１において、例えばステップＳ１１５で行われる。

端末装置１から送信されたメッセージ１０２は、経路制御装置４のクライアント側セッション情報収集部４２によって処理される。このセッション情報収集部４２は、受信したメッセージ１０２のセッション情報を復号化することにより、セッション情報を取得し、取得したセッション情報を中継設定生成部４３に渡す。それにより、中継設定生成部４３は、第１の実施形態と同様に、中継設定情報を生成して設定部４４に渡す。セッション情報の復号化は、図１９にフローチャートを示すクライアント側セッション情報収集処理Ｆ４２において、例えばステップ４２１で行われる。

第２の実施形態では、このようにして、端末装置１はセッション情報を暗号化したメッセージ１０２を経路制御装置４に送信し、経路制御装置４は、メッセージ１０２のセッション情報を復号化して、中継設定情報の中継装置２への設定を行う。このため、第１の実施形態と比較して、セッション情報の漏洩は大幅に抑えることができる。

サーバ３でも同様に、サーバ側アプリケーションセッション情報通知部３２は、図２４に示すように、アプリケーションセッションＩＤ暗号化部３２ａを備えている。それにより、サーバ３もセッション情報を暗号化したメッセージ３０１を経路制御装置４に送信する。

なお、第２の実施形態では、経路制御装置４はセッション情報を復号化しているが、必ずしも復号化しなくとも良い。これは、端末装置１、及びサーバ３が同じデータを同じルールで暗号化した場合、暗号化後のデータは同じになるからである。それにより、セッション情報（例えばセッションＩＤのみであっても良い）は、その暗号化されたデータの位置が予め特定できるようにしておけば、その暗号化データをセッションＩＤの代わりとして用いることができるからである。そのようにして復号化を回避させた場合には、復号化に要するコストをより抑えることができる。

＜第３の実施形態＞
上記第１及び第２の実施形態では、端末装置１からのセッション情報の経路制御装置４への通知は、クライアントアプリケーション１２の制御により行っている。第３の実施形態は、セッション情報の通知をクライアントアプリケーション１２とは別のソフトウエア制御により行うようにしたものである。

第３の実施形態では、端末装置１のみが上記第１の実施形態から異なっている。このことから、端末装置１にのみ着目する形で説明を行う。動作等が異なっても第１の実施形態に存在するものにはその第１の実施形態と同じ符号を用いることとする。また、アプリケーションのセッションＩＤは「セッションＩＤ」、ＳＳＬセッションのＩＤは「ＳＳＬセッションＩＤ」と表記することにより、これらのＩＤを区別する。

図２５は、第３の実施形態による端末装置、及びその端末装置を用いてサービスを利用可能なサービス提供システムの構成を示す図である。先ず、図２５を参照して、第３の実施形態による端末装置１の機能構成について具体的に説明する。

図２５に示すように、第３の実施形態による端末装置１は、代理応答・発行部１１１、及びフック部１１２を更に備えている。代理応答・発行部１１１は、クライアントアプリケーション１２と通信部１３の間に配置され、クライアントアプリケーション１２と通信部１３間のメッセージの受け渡しを制御する。フック部１１２は、通信部１３から外部装置宛てに出力されるメッセージのなかの所定のメッセージをフックし、その所定のメッセージの送信を遅延させる。

メッセージ１０１の送信は、中継装置２との間にコネクション（ＴＣＰコネクション）を確立した後に行われる。このコネクションの確立は、その確立を要求するためのＳＹＮパケット（ＳＹＮフラグを立てたパケット）を送信することで行われる。ＳＳＬセッションの確立は、このコネクションの確立後に行われる。本実施形態では、フック部１１２にこのＳＹＮパケットを所定のメッセージとしてフックさせるようにしている。それにより、代理応答・要求部１１１、及びフック部１１２は、クライアントアプリケーション１２が送信を要求するメッセージを実際に送信するタイミングを制御しつつ、セッション情報の取得、及び取得したセッション情報の経路制御装置４への通知を行う。要求されたメッセージを実際に送信するタイミングを制御することから、代理応答・要求部１１１は、クライアントアプリケーション１２への応答を代理して行う。以降、代理応答・要求部１１１、及びフック部１１２に着目しつつ、動作を説明する。

クライアントアプリケーション１２は、メッセージ１０１を送信する前に、そのメッセージ１０１を送信する予定の宛先ＩＰアドレス・ポート番号を指定して、仮想の通信路であるＳＳＬセッション（以降「ＳＳＬ通信路」と表記する）の確立を要求する。代理応答・要求部１１１は、その要求を受け取った場合、仮のコネクションＩＤ（以降「仮コネクションＩＤ」）、及び仮のＳＳＬセッションＩＤ（以降「仮ＳＳＬセッションＩＤ」）を生成し、それら生成したＩＤを応答として返す。

生成した仮コネクションＩＤ及び仮ＳＳＬセッションＩＤは、メッセージ１０１の実際の送信に用いられるとは限らない。このことから代理応答・要求部１１１は、仮コネクションＩＤ、及び仮ＳＳＬセッションＩＤの生成結果をそれぞれコネクションＩＤマッピングテーブル１２４及びＳＳＬセッションＩＤマッピングテーブル１２５に保存する。コネクションＩＤマッピングテーブル１２４は、仮コネクションＩＤと実際のコネクションＩＤ（以降「実コネクションＩＤ」）の対応関係を特定できるように用意したものである。図２９に示すように、１エントリには仮コネクションＩＤ及び実コネクションＩＤが格納される。ＳＳＬセッションＩＤマッピングテーブル１２５も同様に、仮ＳＳＬセッションＩＤと実際のＳＳＬセッションＩＤ（以降「実ＳＳＬセッションＩＤ」）の対応関係を特定できるように用意したものである。図３０に示すように、１エントリに仮ＳＳＬセッションＩＤ及び実ＳＳＬセッションＩＤが格納される。

応答として仮コネクションＩＤ及び仮ＳＳＬセッションＩＤを受け取ったクライアントアプリケーション１２は、ＳＳＬ通信路が確立したと判定し、これらのＩＤを用いてメッセージ１０１の送信を要求する。そのメッセージ１０１は、Ｌ３・Ｌ４ヘッダに仮コネクションＩＤが格納されたものである。代理応答・発行部１１１は、メッセージ１０１の送信要求をクライアントアプリケーション１２から受け取ると、そのメッセージ１０１のＬ３・Ｌ４ヘッダに格納された送信元、及び宛先のＩＰアドレス・ポート番号を仮コネクションＩＤとして抽出する。次に抽出した仮コネクションＩＤをキーにしてコネクションＩＤマッピングテーブル１２５を検索することにより、その仮コネクションＩＤを格納したエントリを抽出し、そのエントリに実コネクションＩＤが格納されているか否か確認する。それにより、実コネクションＩＤが確認できなければ、実際にはＳＳＬ通信路（含むＴＣＰコネクション）が確立されていないとして、メッセージ１０１を保存し、通信部１３にＳＳＬ通信路の確立を要求する。メッセージ１０１の保存は、メッセージバッファテーブル１２３を用いて行う。このテーブル１２３の１エントリには、図２８に示すように、仮コネクションＩＤ、及びメッセージ１０１本体、またはそのメッセージ１０１の保存場所を示すデータであるポインタが格納される。

ＳＳＬ通信路の要求によって通信部１３は、ＳＳＬ通信路の確立を中継装置２に要求するためのメッセージであるＳＹＮパケットを生成し出力する。このことから代理応答・発行部１１１は、フック部１１２に、そのＳＹＮパケットのフックを指示する。一方、実コネクションＩＤが確認できれば、代理応答・発行部１１１は、メッセージ１０１を通信部１３に渡し、そのメッセージ１０１の送信を要求する。

ＳＹＮパケットのフックの指示は、そのパケットのＬ３・Ｌ４ヘッダの宛先ＩＰアドレス・ポート番号を指定することで行われる。フック部１１２は、代理応答・発行部１１１から指定された宛先ＩＰアドレス・ポート番号をフック対象リスト（テーブル）１２２に登録する。それによりフック部１１２は、通信部１３からメッセージを受け取ると、そのメッセージのＬ３・Ｌ４ヘッダの宛先ＩＰアドレス・ポート番号を抽出し、抽出した宛先ＩＰアドレス・ポート番号がフック対象リスト１２２に登録されているか否か確認する。その確認により、宛先ＩＰアドレス・ポート番号がフック対象リスト１２２に登録されているメッセージをフックする。

図２７は、フック対象リストの１エントリに格納されるデータを説明する図である。図２７に示すように、フック対象リスト１２２の１エントリには、代理応答・発行部１１１から指定された宛先ＩＰアドレス・ポート番号が、フック対象とするメッセージ（パケット）を識別するための情報として格納される。

通信部１３からフック部１１２に渡されるメッセージのＬ３・Ｌ４ヘッダに送信元、及び宛先のＩＰアドレス・ポート番号として格納されているコネクションＩＤは、実コネクションＩＤである。このことからフック部１１２は、メッセージをフックすると、フックしたメッセージのコネクションＩＤを抽出し、抽出したコネクションＩＤを実コネクションＩＤとしてクライアント側アプリケーションセッション情報通知部１１に通知する。その通知後、フックを解除し、フックしていたメッセージを送信する。

代理応答・発行部１１１は、メッセージのフックをフック部１１２に指示した後、このメッセージの送信を要求した通信部１３から実コネクションＩＤ及び実ＳＳＬセッションＩＤを取得する。取得した実コネクションＩＤは、仮コネクションＩＤをキーにしてコネクションＩＤマッピングテーブル１２５から抽出したエントリに格納する。取得した実ＳＳＬセッションＩＤは、クライアントアプリケーション１２から指定された仮ＳＳＬセッションＩＤをキーにＳＳＬセッションＩＤマッピングテーブル１２５から抽出されるエントリに格納する。そのようにして、仮コネクションＩＤと実コネクションＩＤ、並びに仮ＳＳＬセッションＩＤと実ＳＳＬセッションＩＤの対応関係を確定させる。

クライアントアプリケーション１２から代理応答・発行部１１１に渡されるメッセージは暗号化されていない。このことに着目し、本実施形態では、仮コネクションＩＤをキーにしてコネクションＩＤマッピングテーブル１２５から抽出したエントリに実コネクションＩＤが格納されていない場合、メッセージにセッションＩＤが存在するか否か確認するようにしている。それにより代理応答・発行部１１１は、セッションＩＤが存在する場合のみ、メッセージのフックを指示する。そのセッションＩＤは宛先ＩＰアドレス・ポート番号と共に、フックを指示する前にクライアント側アプリケーションセッション情報通知部１１に通知する。

このようなことから、クライアント側アプリケーションセッション情報通知部１１には、セッションＩＤ、及び宛先ＩＰアドレス・ポート番号が代理応答・発行部１１１から通知された後、フック部１１２から実コネクションＩＤが通知される。クライアント側アプリケーションセッション情報通知部１１は、実コネクションＩＤの通知を契機に、経路制御装置４にセッション情報を通知する。このセッション情報の通知のために、セッション情報管理テーブル１２１を管理する。

図２６は、セッション情報管理テーブルの１エントリに格納されるデータを説明する図である。図２６に示すように、１エントリには、宛先ＩＰアドレス・ポート番号、送信元ＩＰアドレス・ポート番号、及びセッションＩＤが格納される。宛先ＩＰアドレス・ポート番号、及び送信元ＩＰアドレス・ポート番号は、実コネクションＩＤのものである。

フックしていたメッセージ（ＳＹＮパケット）をフック部１１２が送信させることにより、ＴＣＰコネクション及びＳＳＬ通信路が中継装置２との間で確立される。その確立は、通信路１３の制御によって行われ、通信路１３はＳＳＬ通信路の確立を代理応答・発行部１１１に通知する。その通知時に、実コネクションＩＤ、及び実ＳＳＬセッションＩＤは取得される。

このようにして、代理応答・発行部１１１及びフック部１１２は、経路制御装置４に通知するセッション情報の収集、及び収集したセッション情報を通知するうえで必要なメッセージの送信タイミングの調整を行う。それにより、クライアントアプリケーション１２として、特別な機能を搭載していないものを使用できるようにしている。このことから代理応答・発行部１１１及びフック部１１２は、従来の端末装置に搭載させることにより、本実施形態による端末装置１を実現できるものとなっている。

図３２は、第３の実施形態による端末装置１が実行するプログラムによって実現される処理を説明する図である。次に図３２を参照して、端末装置１が実行するプログラム、及び各プログラムが実現させる処理について説明する。

第３の実施形態による端末装置１では、クライアントアプリケーション１２の他に、クライアント側アプリケーションセッション情報通知部１１を実現させるプログラム（以降「セッション情報通知プログラム」）、及びフック部１１２を実現させるプログラム（以降「フックプログラム」）が実行される。

通信部１３は、ＯＳ（オペレーティング・システム）によって実現される。アプリケーション等のプログラムの実行は、ＯＳの動作が前提となる。このことからＯＳ、つまり通信部１３は、端末装置１が実行するプログラムとして詳細な説明は省略する。セッション情報通知プログラム、代理応答プログラム及びフックプログラムは、例えば共にミドルウェアとして提供されている。

クライアントアプリケーション１２は、リクエスト送信処理Ｆ１２１及び応答取得処理Ｆ１２を実行させる。リクエスト送信処理Ｆ１２１は、リクエストであるメッセージ１０１を送信するための処理である。応答取得処理Ｆ１２は、メッセージ１０１への応答として送信されるメッセージ（メッセージ２０２）に対応するための処理であり、その内容は基本的に第１の実施形態のもの（図１６）と同じである。このため、その詳細な説明は省略する。

代理応答プログラムは、通信路確立要求応答処理Ｆ１１１１、代理要求処理Ｆ１１１２、代理応答処理Ｆ１１１３及びコネクション削除要求処理Ｆ１１１４を実現させる。通信路確立要求応答処理Ｆ１１１１は、クライアントアプリケーション１２が行うＳＳＬ通信路確立要求に対応するための処理である。代理要求処理Ｆ１１１２は、アプリケーション１２がＳＳＬ通信路確立要求の後に行うメッセージ１０１の送信要求に対応するための処理である。代理応答処理Ｆ１１１３は、メッセージ１０１の送信により応答として受信するメッセージ（メッセージ２０２）をクライアントアプリケーション１２に渡すための処理である。確立したＴＣＰコネクションは、送信すべきデータが無くなった側からの切断手続きによって開放される。その開放のために、ＦＩＮパケット（コネクションの切断を要求するＦＩＮフラグが立ったメッセージ）が送信される。コネクション削除要求処理Ｆ１１１４は、そのＦＩＮパケットの受信に対応するための処理である。メッセージ１０１の送信によってサーバ３はメッセージ３０２を送信することから、端末装置１は中継装置２を介してこのＦＩＮパケットを受信するのが普通である。

セッション情報通知プログラムは、セッション情報保存処理Ｆ１１１及びセッション情報通知処理Ｆ１１２を実現させる。セッション情報保存処理Ｆ１１１は、代理応答・発行部１１１から通知されたセッション情報を保存するための処理である。セッション情報通知処理部Ｆ１１２は、セッション情報を経路制御装置４に通知するための処理である。

以降は、図３２に示した各処理について、図３３〜図３９に示す各フローチャートを参照して詳細に説明する。
始めに、クライアントアプリケーション１２によって実現されるリクエスト送信処理Ｆ１２１について、図３３に示すフローチャートを参照して詳細に説明する。この送信処理Ｆ１２１も第１の実施形態と同様に、ユーザがサービス提供システムへのアクセス、つまりサービス提供システムへのメッセージ１０１の送信を指示することを契機に実行される。

先ず、ステップＳ３３０１では、クライアントアプリケーション１２は、ユーザの指示によりメッセージ１０１を作成する。続くステップＳ３３０２では、ユーザが指定したＵＲＬ（宛先ＵＲＬ）をキーに、セッションＩＤテーブル１５（図１０）を検索する。その次に移行するステップＳ３３０３では、クライアントアプリケーション１２は、その検索結果から、キーとしたＵＲＬ（ＩＰアドレス・ポート番号）と対応付けたセッションＩＤが有るか否か判定する。検索によって、キーとしたＵＲＬを格納するエントリを抽出できた場合、判定はＹＥＳとなってステップＳ３３０４に移行し、クライアントアプリケーション１２はセッションＩＤをメッセージ１０１に記載する。その後はステップＳ３３０５に移行する。一方、そのようなエントリを抽出できたなかった場合、判定はＮＯとなってそのステップＳ３３０５に移行する。

ステップＳ３３０５では、クライアントアプリケーション１２は、メッセージ（リクエスト）１０１を送信するためのＳＳＬ通信路の情報が配布されているか否か判定する。上述したように、ＳＳＬ通信路の確立要求によって代理応答・発行部１１１がクライアントアプリケーション１２に返す情報は仮コネクションＩＤ、及び仮ＳＳＬセッションＩＤである。このことから、有効な仮コネクションＩＤ及び仮ＳＳＬセッションＩＤが存在する場合、判定はＹＥＳとなってステップＳ３３０６に移行し、クライアントアプリケーション１２は作成したメッセージ１０１を仮ＳＳＬセッションＩＤと共に代理応答・発行部１１１に送出する。その後、このリクエスト送信処理を終了する。一方、有効な仮コネクションＩＤ及び仮ＳＳＬセッションＩＤが存在しない場合には、判定はＮＯとなってステップＳ３３０７に移行する。

ステップＳ３３０７では、クライアントアプリケーション１２は、代理応答・発行部１１１にＳＳＬ通信路の確立を要求する。次のステップＳ３３０８では、クライアントアプリケーション１２は、その確立要求によって代理応答・発行部１１１が返す応答、つまり仮コネクションＩＤ及び仮ＳＳＬセッションＩＤ等を取得するのを待つ。その応答取得後にステップＳ３３０６に移行する。

ステップＳ３３０６におけるメッセージ１０１の送出、及びステップＳ３３０７でのＳＳＬ通信路の確立要求は、代理応答・発行部１１１に対して行われる。しかし、それらメッセージ１０１の送出、及び確立要求は、クライアントアプリケーション１２にとって、通信部１３に対して行ったものとして扱われる。それにより、クライアントアプリケーション１２には、代理応答・発行部１１１に応じた特別な機能は搭載されていない。

次に、代理応答プログラムによって実現される通信路確立要求応答処理Ｆ１１１１、代理要求処理Ｆ１１１２、代理応答処理Ｆ１１１３及びコネクション削除要求処理Ｆ１１１４について詳細に説明する。

図３４は、通信路確立要求応答処理のフローチャートである。始めに図３４を参照して、この要求応答処理Ｆ１１１１について詳細に説明する。この図３４のフローチャートは、クライアントアプリケーション１２からの１ＳＳＬ通信路確立要求に対応するために実行する処理の流れを示したものである。

先ず、ステップＳ３４０１では、代理応答プログラムは、ＳＳＬ通信路確立要求から宛先ＩＰアドレス・ポート番号を取得する。次のステップＳ３４０２では、代理応答プログラムは、仮コネクションＩＤを生成し、コネクションＩＤマッピングテーブル１２４に１エントリを追加し、そのエントリに生成した仮コネクションＩＤを格納する。その仮コネクションＩＤは、端末装置１のＩＰアドレス、及び空いているポート番号のなかから選択したポート番号を送信元ＩＰアドレス・ポート番号、取得した宛先ＩＰアドレス・ポート番号とするものである。仮コネクションＩＤの格納を行った後はステップＳ３４０３に移行する。

ステップＳ３４０３では、仮ＳＳＬセッションＩＤを生成し、生成した仮ＳＳＬセッションＩＤを格納したエントリをＳＳＬセッションＩＤマッピングテーブル１２５に追加する。続くステップＳ３４０４では、生成した仮コネクションＩＤ、及び仮ＳＳＬセッションＩＤを応答の形でクライアントアプリケーション１２に返す。その後、この通信路確立要求応答処理を終了する。

図３５は、代理要求処理のフローチャートである。次に図３５を参照して、この要求処理Ｆ１１１２について詳細に説明する。この図３５のフローチャートは、クライアントアプリケーション１２からの１メッセージ１０１の送信要求に対応するために実行する処理の流れを示したものである。

先ず、ステップＳ３５０１では、代理応答プログラムは、クライアントアプリケーション１２からメッセージ送信要求の形で受け取ったメッセージ１０１のＬ３・Ｌ４ヘッダから仮コネクションＩＤを取得する。次のステップＳ３５０２では、取得した仮コネクションＩＤをキーにコネクションＩＤマッピングテーブル１２４を検索することにより、実コネクションＩＤが取得できたか否か判定する。その検索によって抽出されたエントリに実コネクションＩＤが格納されていた場合、実コネクションＩＤは取得できたと判定され、ステップＳ３５０３に移行する。抽出されたエントリに実コネクションＩＤが格納されていなかった場合には、実コネクションＩＤは取得できなかったと判定され、ステップＳ３５０５に移行する。

ステップＳ３５０３では、代理応答プログラムは、クライアントアプリケーション１２からの仮ＳＳＬセッションＩＤをキーにしてＳＳＬセッションＩＤマッピングテーブル１２５を検索することにより、実ＳＳＬセッションＩＤを取得する。次のステップｓ３５０４では、代理応答プログラムは、メッセージ送信要求中のメッセージ１０１を取得し、そのメッセージ１０１を送信対象に設定する。その設定後、この代理要求処理Ｆ１１１２を終了する。

上記ステップＳ３５０２で実コネクションＩＤが取得できなかったと判定した場合に移行するステップＳ３５０５では、代理応答プログラムは、メッセージ１０１からセッションＩＤを取得できたか否か判定する。そのメッセージ１０１のＨＴＴＰヘッダにセッションＩＤが格納されていた場合、セッションＩＤは取得できたと判定され、ステップＳ３５０６に移行する。セッションＩＤがメッセージ１０１に格納されていなかった場合、セッションＩＤは取得できなかったと判定され、ステップＳ３５１０に移行する。

ステップＳ３５０６では、代理応答プログラムは、メッセージ１０１から抽出した仮コネクションＩＤ、及びそのメッセージ１０１自体、或いはそのポインタを格納したエントリをメッセージバッファテーブル１２３に追加する。次のステップＳ３５０７では、代理応答プログラムは、仮コネクションＩＤの宛先ＩＰアドレス・ポート番号を取得する。その後に移行するステップＳ３５０８では、代理応答プログラムは、取得した宛先ＩＰアドレス・ポート番号をセッションＩＤと共にクライアント側セッション情報通知部１１に通知し、その応答を取得する。ステップＳ３５０９には応答を取得した後に移行する。

ステップＳ３５０９では、代理応答プログラムは、ステップＳ３５０７で取得した宛先ＩＰアドレス・ポート番号をフック部１１２に通知することによりフック設定を行い、その応答を取得する。続くステップＳ３５１０では、代理応答プログラムは、宛先ＩＰアドレス・ポート番号を通信部１３に渡し、ＳＳＬ通信路確立要求を行う。その次に移行するステップＳ３５１１では、代理応答プログラムは、通信部１３から実コネクションＩＤ及び実ＳＳＬセッションＩＤを含む応答を取得し、それら実コネクションＩＤ及び実ＳＳＬセッションＩＤを保存する。

実コネクションＩＤの保存は、コネクションＩＤマッピングテーブル１２４のなかでクライアントアプリケーション１２から渡された仮コネクションＩＤを格納したエントリにその実コネクションＩＤを書き込むことにより行われる。実ＳＳＬセッションＩＤの保存も同様に、ＳＳＬセッションＩＤマッピングテーブル１２５のなかでクライアントアプリケーション１２から渡された仮ＳＳＬセッションＩＤを格納したエントリにその実ＳＳＬセッションＩＤを書き込むことで行われる。

そのようにして実コネクションＩＤ及び実ＳＳＬセッションＩＤを保存した後はステップＳ３５１２に移行する。そのステップＳ３５１２では、代理応答プログラムは、ステップＳ３５０６で保存したメッセージ１０１を取得する。このメッセージ１０１の取得は、取得した実コネクションＩＤをキーにしたコネクションＩＤマッピングテーブル１２４の検索により仮コネクションＩＤを抽出し、その仮コネクションＩＤをキーにしたメッセージバッファテーブル１２３の検索によりメッセージ１０１自体、或いはポインタを抽出することで行われる。このようにして取得されるメッセージ１０１を送信対象に設定した後、この代理応答処理Ｆ１１１２を終了する。

このようにして本実施形態では、ＳＳＬ通信路が維持されていない状況下であることを条件に、実コネクションＩＤの生成を契機にする形で、セッション情報を経路制御装置４に通知するようにしている。これは、ＳＳＬ通信路が維持されている時間はセッションが維持されている時間より短いと想定しているからである。つまり、確立したＳＳＬ通信路が開放されている場合でも、サーバ３でセッションが維持されている可能性があるためである。

図３６は、代理応答処理のフローチャートである。次に図３６を参照して、この応答処理Ｆ１１１３について詳細に説明する。この応答処理Ｆ１１１３は、代理要求処理Ｆ１１１２の終了後に起動される処理であり、図３６のフローチャートは、代理要求処理Ｆ１１１２が送信対象に設定した１メッセージ１０１の送信に対応するために実行する処理の流れを示したものである。

先ず、ステップＳ３６０１では、代理応答プログラムは、通信部１３にメッセージ送信要求を発行する。次のステップＳ３６０２では、代理応答プログラムは、通信部１３から応答を取得する。ここでの応答は、メッセージ２０２を含むものである。そのような応答を取得した後、ステップＳ３６０３に移行する。

ステップＳ３６０３では、代理応答プログラムは、取得したメッセージ２０２のＬ３・Ｌ４ヘッダに格納された形の実コネクションＩＤをキーにしたコネクションＩＤマッピングテーブル１２４の検索により、仮コネクションＩＤを取得する。続くステップＳ３６０４では、代理応答プログラムは、実ＳＳＬセッションＩＤをキーにしたＳＳＬセッションＩＤマッピングテーブル１２５の検索により、仮ＳＳＬセッションＩＤを取得する。その次のステップＳ３６０５では、代理応答プログラムは、クライアントアプリケーション１２に応答を返す。その後、この代理応答処理Ｆ１１１３を終了する。

図３７は、コネクション削除処理のフローチャートである。最後に図３７を参照して、この削除処理Ｆ１１１４について詳細に説明する。
上述したように、確立したＴＣＰコネクションは、送信すべきデータが無くなった側からのＦＩＮパケット（コネクションの切断を要求するＦＩＮフラグが立ったメッセージ）の送信によって開始される。ＦＩＮパケットを受け取った側は送信すべきデータがなくなった時点でＦＩＮパケットを送信し、そのパケットの送受信が完了した後にコネクションは開放される。端末装置１はデータを要求する側であることから、そのＦＩＮパケットはコネクションの切断契機となる。コネクション削除要求処理Ｆ１１１４は、そのＦＩＮパケットの受信に対応するための処理である。図３７のフローチャートは、１ＦＩＮパケットの受信に対応するために実行する処理の流れを示したものである。

先ず、ステップＳ３７０１では、代理応答プログラムは、ＴＣＰコネクションの削除要求を受信する。この削除要求の受信は、通信部１３からのＦＩＮパケットを取得することに相当する。

削除要求の受信後はステップＳ３７０２に移行し、代理応答プログラムは、ＦＩＮパケットのＬ３・Ｌ４ヘッダに格納されている形の実コネクションＩＤをキーにしたコネクションＩＤマッピングテーブル１２４の検索によりエントリを抽出し、そのエントリをテーブル１２４から削除する。次のステップＳ３７０３では、代理応答プログラムは、実コネクションを削除した旨を通知するための削除完了応答を通信部１３に返す。その後、このコネクション削除処理Ｆ１１１４を終了する。

このようにして確立したＴＣＰコネクションは、端末装置１とサーバ３間のデータの送受信が終了する度に開放される。このことから、ＳＳＬ通信路が維持されているか否かに係わらず、ＴＣＰコネクションの確立はメッセージ１０１の送信時に行われることとなる。

ＴＣＰコネクションの開放は、予め定めた手順に沿って行われる。このことからフック部１１２は、ＦＩＮパケットを代理応答・発行部１１１に出力するタイミングを判断するために、不図示のコネクション管理テーブルを用意している。その管理テーブルには、図３１に示すように、各エントリに実コネクションＩＤ、及びコネクションの状態（を示すデータ）が格納されている。それにより、フック部１１２は、実コネクション毎に状態、及び状態の推移を把握し、ＴＣＰコネクションを開放させるサーバ３からの最後のメッセージを代理応答・発行部１１１に出力するようにしている。

最後に、セッション情報通知プログラムによって実現されるセッション情報保存処理Ｆ１１１及びセッション情報通知処理Ｆ１１２について詳細に説明する。
図３８は、セッション情報保存処理のフローチャートである。この保存処理Ｆ１１１は、代理応答・発行部１１１から通知されたセッション情報を保存するための処理である。その通知は、代理応答プログラムが図３５のステップＳ３５０８の処理を実行することで実現される。このとき通知されるセッション情報は、宛先ＩＰアドレス・ポート番号とセッションＩＤである。図３８には、１セッション情報を保存するために実行する処理の流れを示している。始めに図３８を参照して、この保存処理Ｆ１１１について詳細に説明する。

先ず、ステップＳ３８０１では、セッション情報通知プログラムは、代理応答プログラムから通知されたセッション情報、つまり宛先ＩＰアドレス・ポート番号、及びセッションＩＤを取得する。次のステップＳ３８０２では、セッション情報通知プログラムは、通知されたセッション情報をセッション情報管理テーブル１２１に保存する。その保存は、例えばセッションＩＤをキーにセッション情報管理テーブル１２１を検索し、その検索によってエントリを抽出すれば、そのエントリにセッション情報を格納することで行う。エントリを抽出できなければ、１エントリを追加し、追加したエントリにセッション情報を格納することで行う。そのようにしてセッション情報を保存した後、このセッション情報保存処理Ｆ１１１を終了する。

図３９は、セッション情報通知処理のフローチャートである。この通知処理Ｆ１１２は、セッション情報を経路制御装置４に通知するための処理である。図３９のフローチャートは、１セッション情報を経路制御装置４に通知するために実行する処理の流れを示したものである。最後に図３９を参照して、この通知処理Ｆ１１２について詳細に説明する。

フック部１１２は、代理応答プログラムが図３５のステップＳ３５０９の処理を実行することにより指定したＳＹＮパケットをフックする。ＳＹＮパケットをフックした場合、フック部１１２は、そのＳＹＮパケットを送信する前に、そのＳＹＮパケットのＬ３・Ｌ４ヘッダに格納された形の実コネクションＩＤをクライアント側アプリケーションセッション情報通知部１１に通知する。セッション情報通知処理Ｆ１１２は、その実コネクションＩＤの通知を契機に実行される。

先ず、ステップＳ３９０１では、セッション情報通知プログラムは、フック部１１１から通知された実コネクションＩＤを取得する。続くステップＳ３９０２では、セッション情報通知プログラムは、実コネクションＩＤから宛先ＩＰアドレス・ポート番号を取得する。その次のステップＳ３９０３では、セッション情報通知プログラムは、取得した宛先ＩＰアドレス・ポート番号をキーにセッション情報管理テーブル１２１を検索し、その検索によって抽出したエントリからセッションＩＤを取得する。そのエントリには、実コネクションＩＤから取得した送信元ＩＰアドレス・ポート番号を保存する。その後、ステップＳ３９０４に移行する。

ステップＳ３９０４では、セッション情報通知プログラムは、取得した実コネクションＩＤ、及びセッションＩＤをセッション情報として経路制御装置４に通知する。その通知は、第１の実施形態と同様に、メッセージ１０２（図４）を作成し送信することで行う。そのメッセージ１０２を受信した中継制御装置４は、中継設定情報を中継装置２に設定し、その設定完了を通知するメッセージである設定完了通知を端末装置１に送信する。このことから、その後に移行するステップＳ３９０５では、セッション情報通知プログラムは、設定完了通知を取得する。ステップＳ３９０６には、その設定完了通知を取得した後に移行する。

ステップＳ３９０６では、セッション情報通知プログラムは、経路制御装置４に通知したセッション情報を格納したエントリをセッション情報管理テーブル１２１から消去する。続くステップＳ３９０７では、セッション情報通知プログラムは、フック部１１２に、実コネクションＩＤの通知への応答を返す。その後、このセッション情報通知処理Ｆ１１２を終了する。フック部１１２は、この応答を取得した後、フックしているＳＹＮパケットを送信させる。

なお、第３の実施形態では、クライアントアプリケーション１２の他にプログラム（例えばミドルウェア）を用意し、代理応答・発行部１１１及びフック部１１２を実現させているが、それらを実現させる機能はクライアントアプリケーション１２に搭載させても良い。その場合、仮コネクションＩＤ或いは／及び仮ＳＳＬセッションＩＤを生成することなく、セッション情報を経路制御装置４に通知できるようにしても良い。本実施形態（第１〜第３の実施形態）では、端末装置１からセッション情報を通知するタイミングはメッセージ１０１の送信時としているが、初期メッセージ１０１ａのレスポンスの受信時としても良い。これら以外の変形を行っても良い。

１ 端末装置（クライアント）
２ 中継装置
３ サーバ
４ 経路制御装置
１１ クライアント側アプリケーションセッション情報通知部
１１ａ アプリケーションセッションＩＤ暗号化部
１２ クライアントアプリケーション
１３ 通信部
２１ 中継部
２２ 負荷分散部
２３ 中継設定記録部
２４ 設定受付部
３１ サーバアプリケーション
３２ サーバ側アプリケーションセッション通知部
４１ サーバ側アプリケーションセッション収集部
４２ クライアント側アプリケーションセッション収集部
４３ 中継設定生成部
４４ 設定部

Claims (10)

1. コンピュータに、
   中継装置を介してサーバにメッセージを送信する場合に、該サーバから受信したセッションデータの有無を確認し、
   前記セッションデータがある場合、コネクションデータを生成し、
   経路制御装置に前記セッションデータおよび前記コネクションデータを送信し、
   前記経路制御装置より前記中継装置の中継設定の完了の通知を受信したとき、前記サーバに送信する送信データと前記セッションデータを暗号化して暗号化データを生成し、
   前記コネクションデータと前記暗号化データを含むメッセージを前記中継装置に送信することを実行させるプログラム。
2. 前記経路制御装置に前記セッションデータおよび前記コネクションデータを送信する際に、前記セッションデータを暗号化することを特徴とする請求項１記載のプログラム。
3. コンピュータに、
   中継装置を介してサーバにメッセージを送信するコネクションを確立する場合に、該コネクション用のコネクションデータを生成し、
   前記サーバから受信したセッションデータの有無を確認し、
   前記セッションデータがある場合、経路制御装置に前記セッションデータおよび前記コネクションデータを送信し、
   前記経路制御装置より前記中継装置の中継設定の完了の通知を受信したとき、前記メッセージ中の前記サーバに送信する送信データと前記セッションデータを暗号化して暗号化データを生成し、
   前記コネクションデータと前記暗号化データを含むメッセージを前記中継装置に送信することを実行させるプログラム。
4. コンピュータに、
   情報処理装置からセッションデータおよびコネクションデータを受信し、
   前記セッションデータを基にサーバアドレスを抽出し、
   前記コネクションデータおよび前記サーバアドレスを中継装置に送信することを実行させるプログラム。
5. 前記情報処理装置から受信したセッションデータは暗号化されていることを特徴とする請求項４記載のプログラム。
6. サーバから受信したセッションデータの有無を確認し、前記セッションデータがある場合、コネクションデータを生成し、経路制御装置に前記セッションデータおよび前記コネクションデータを送信する経路通知部と、
   前記経路制御装置より中継装置の中継設定の完了の通知を受信したとき、前記サーバに送信する送信データと前記セッションデータを暗号化して暗号化データを生成し、前記コネクションデータと前記暗号化データを含むメッセージを前記中継装置に送信する送信部とを有することを特徴とする情報処理装置。
7. 前記経路通知部は、前記経路制御装置に送信する前記セッションデータを暗号化することを特徴とする請求項６記載の情報処理装置。
8. 中継装置を介してサーバにメッセージを送信するコネクションを確立する場合に、該コネクション用のコネクションデータを生成し、前記サーバから受信したセッションデータの有無を確認し、前記セッションデータがある場合、経路制御装置に前記セッションデータおよび前記コネクションデータを送信する経路通知部と、
   前記経路制御装置より前記中継装置の中継設定の完了の通知を受信したとき、前記メッセージ中の前記サーバに送信する送信データと前記セッションデータを暗号化して暗号化データを生成し、前記コネクションデータと前記暗号化データを含むメッセージを前記中継装置に送信する送信部とを有することを特徴とする情報処理装置。
9. 情報処理装置からセッションデータおよびコネクションデータを受信し、前記セッションデータを基にサーバアドレスを抽出する中継設定生成部と、
   前記コネクションデータおよび前記サーバアドレスを中継装置に送信する設定部とを有することを特徴とする経路制御装置。
10. 情報処理装置が、サーバから受信したセッションデータの有無を確認し、
    前記情報処理装置が、前記セッションデータがある場合、コネクションデータを生成し、
    前記情報処理装置が、経路制御装置に前記セッションデータおよび前記コネクションデータを送信し、
    前記経路制御装置が、受信した前記セッションデータを基に前記サーバのサーバアドレスを抽出し、
    前記経路制御装置が、前記コネクションデータおよび前記サーバアドレスを中継装置に送信し、
    前記情報処理装置が、前記経路制御装置より前記中継装置の中継設定の完了の通知を受信したとき、前記サーバに送信する送信データと前記セッションデータを暗号化して暗号化データを生成し、
    前記情報処理装置が、前記コネクションデータと前記暗号化データを含むメッセージを前記中継装置に送信し、
    前記中継装置が、受信した前記メッセージ中の前記コネクションデータを基に前記サーバアドレスを抽出し、
    前記中継装置が、抽出した前記サーバアドレスへ、前記メッセージを送信することを特徴とするデータ中継方法。

Images