JP2005184249A - 通信システム、サーバ、端末装置、通信方法、プログラムおよび記憶媒体 - Google Patents

Abstract

【課題】 応答パケットを送信しないようにして、通信コストを削減するとともに進入・攻撃を防ぎ、さらには、接続要求を伴う接続の負荷を複数のアプリケーションサーバにバランスよく分配できる通信システム、通信システム、アプリケーションサーバ、端末装置を提供すること。
【解決手段】 ＵＤＰ／ＩＰパケットのペイロードの所定位置に発信元ポート番号および宛先ポート番号以外のＴＣＰヘッダ情報を記録したパケットであるＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを処理するＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段を含む通信システムを提供する。また、複数のアプリケーションサーバの各負荷に応じてアプリケーションサーバを選択して、端末装置に知らせる接続受付サーバを提供する。接続の確立にあたっては、任意に決めたＴＣＰのＳｅｑ＃を事前に共有して不正接続要求に対する応答トラヒックを節約することができる。
【選択図】 図１

Description

本発明は、通信トラヒックを節約したりサービス負荷を効率よく配分したりするための通信システム、関係する接続受付サーバ／アプリケーションサーバなどのデータセンタ（ユニット）を構成するサーバ、端末装置（クライアント）、通信方法、プログラムおよび記憶媒体に関する。

インターネットプロトコル（ＩＰ）上のスタックＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）は、進入や攻撃の通信パケットに対しても、応答パケットを出して接続してしまうため、（１）受信および発信という２回分の通信コストがかかる、（２）応答パケットにより情報を与えるため進入されやすい、という問題があった。

また、一般にデータセンタを構成するアプリケーションサーバ等は、複数用意することにより多数の端末装置からの接続要求にある程度備えることができるが、この場合にも、一つのアプリケーションサーバに接続要求が集中してしまう場合があった。

Postel, J., Editor, "Transmission Control Protocol," STD 7, RFC 793, September 1981

本発明は、かかる点に鑑みてなされたものであり、応答パケットを送信しないようにして、通信コストを削減するとともに進入・攻撃を防ぎ、さらには、接続要求を伴う接続の負荷を複数のアプリケーションサーバにバランスよく分配できる、通信システム、サーバ、端末装置を提供すること目的とする。また、このための通信方法、コンピュータプログラム、および記録媒体を提供することを目的とする。なお、ここでいう端末装置は、携帯電話や、ＰＤＡ、一般クライアント用ＰＣのみならず、他のアプリケーションに関してはそのアプリケーションのためのサーバや中継ノード等として機能するホストコンピュータ等をも含むものとする。

本発明は、上述の課題に鑑みてなされたものであり、ＵＤＰ／ＩＰパケットのペイロードの所定位置（例えば先頭）に発信元ポート番号および宛先ポート番号以外のＴＣＰヘッダ情報を記録したパケットである、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを処理するＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段を含む通信システムを提供する。

これにより、ＴＣＰの機能を維持したまま、デフォルトでは応答パケットを出さないトラフィック制御が可能となり、進入を防ぐとともに、攻撃に対する通信コストを制限することができる。

なお、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段は、センタサーバのＯＳにリンクされたプロトコルドライバ、ファームウエア、電子回路などとして実装することができる。

本発明の通信システムは、前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを、ＵＤＰ／ＩＰパケットとして受理するか廃棄するかを決定するＵＤＰ／ＩＰレベルアクセス制限手段を前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段がさらに備え、該アクセス制限手段が廃棄すると決定した場合に、該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段がＴＣＰに相当するプロトコル処理を制限することができる。

これにより、応答パケットを出さないだけでなく、攻撃の割合が高い場合などには、計算機負荷も節約することができる。

本発明の通信システムは、前記ＵＤＰ／ＩＰレベルアクセス制限手段がＵＤＰ／ＩＰパケットとして受理すると決定した場合に、ＵＤＰヘッダに記録された発信元ポート番号および宛先ポート番号並びに該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットのＵＤＰペイロードに記録された前記ＴＣＰヘッダ情報をもとに、ＴＣＰに相当するプロトコル処理を行うＴＣＰヘッダ情報格納ＵＤＰプロトコル処理手段（ＵＤＰｔｃｐプロトコルスタック）を前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段がさらに備えることができる。

これにより、ＵＤＰのメリットを生かしながらもＴＣＰの機能を完全かつ柔軟に利用することが可能となる。

本発明の通信システムは、前記ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理手段が、ＴＣＰに相当するプロトコル処理として、受理したＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットのＵＤＰヘッダ内の発信元ポート番号および宛先ポート番号を、受信したＴＣＰヘッダ内の発信元ポート番号および宛先ポート番号として取り扱い、かつ、受理した該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットの前記所定位置の情報であるＴＣＰヘッダ情報を、受信したＴＣＰヘッダ情報のうち発信元ポート番号および宛先ポート番号を除いたＴＣＰヘッダ情報として取り扱うことができる。

本発明の通信システムは、前記ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理手段が、ＴＣＰに相当するプロトコル処理として、送信用ＴＣＰヘッダ情報のうち発信元ポート番号および宛先ポート番号を送信用ＵＤＰ／ＩＰパケットのＵＤＰヘッダ内の発信元ポート番号および宛先ポート番号として記録し、かつ、残りのＴＣＰヘッダ情報を該送信用ＵＤＰ／ＩＰパケットのペイロードの前記所定位置のＴＣＰヘッダ情報として記録することができる。

これらにより、送信においても受信（受理）においてもポート情報用のフィールドを節約することが可能となり、ＴＣＰ／ＩＰの機能を必要とする通常の通信において、あえて本発明のＴＣＰヘッダ情報格納ＵＤＰ／ＩＰを採用することによる通信コスト増を抑えることができる。

本発明はまた、かかる通信システムにより通信を行うアプリケーションサーバの集合への接続受付を行う接続受付サーバであって、かかる通信システムを備えた端末装置からの接続要求を受信する接続要求受信手段と、前記集合に属する各アプリケーションサーバのトラヒック量を検出するトラヒック量検出手段と、該トラヒック量検出手段により検出したトラヒック量に応じて該接続要求受信手段が受信した接続要求に応答するアプリケーションサーバを選択するアプリケーションサーバ選択手段と、該アプリケーションサーバ選択手段により選択したアプリケーションサーバと通信して端末装置への前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットによる接続許可を取り決める接続許可取決手段と、接続許可取決手段により取り決めた接続許可を前記端末装置に返信する接続許可返信手段と、を有する接続受付サーバを提供する。

これにより、接続要求を伴う接続の負荷を複数のアプリケーションサーバにバランスよく分配することができる。

本発明における接続受付サーバとアプリケーションサーバのトポロジは、例えば、かかるアプリケーションサーバと接続受付サーバとを同数備えたアプリケーションサーバクラスタ（レプリケーションその他の自動情報交換等により同期するように関連づけられたアプリケーションサーバ集合）であって、一の接続受付サーバと一のアプリケーションサーバとが静的に対応し、かつ、接続受付サーバのアドレスと対応するアプリケーションサーバのアドレスとが、端末装置から見て同一又は類似である、アプリケーションサーバクラスタとして構成することができる。

これにより、接続受付サーバのアドレスとアプリケーションサーバのアドレスとを別々に覚える必要がなくなり、アプリケーションサーバのアドレス更新等の際の通知が簡易となり、また、端末装置側主導の、ネットワーク／計算機リソース的な観点からみた、負荷分散・運用効率化が可能となる。

これは、例えば、アプリケーションサーバの計算容量（対応能力）に余裕があるときは、その地域のアプリケーションサーバへのアクセスをその地域の接続受付サーバが収容することにより、サービス用のネットワーク経路を短縮したり、接続受付サーバとアプリケーションサーバとを一体化したり、サーバ間のネゴシエーション経路／機会を節約したりすることができる。

本発明は上記通信システムを備えた端末装置であって、接続受付サーバに接続要求を送信する接続要求送信手段と、接続受付サーバから接続要求に対する返信を受信する返信受信手段と、該返信受信手段が受信した返信に含まれる、アプリケーションサーバのアドレス、ポート又はこれらの組み合わせに対し、前記通信システムにより前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットによる通信を行う端末装置を提供する。

これにより、攻撃／進入に使えないないしは攻撃／進入の効果が少なく、トラヒック制御が透過的にないしは自動的に行われる端末装置を市場に提供することができる。

本発明はまた、ＵＤＰ／ＩＰパケットのペイロードの所定位置に発信元ポート番号および宛先ポート番号以外のＴＣＰヘッダ情報を記録したパケットであるＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを処理するＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理ステップを含む通信方法を提供する。

本発明による通信方法においては、前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットをＵＤＰ／ＩＰパケットとして受理するか廃棄するかを決定するＵＤＰ／ＩＰレベルアクセス制限ステップを、前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理ステップが有し、該アクセス制限ステップにおいて廃棄すると決定した場合に、該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理ステップがＴＣＰに相当するプロトコル処理を行わない制限するようにすることができる。

本発明による通信方法のおいては、前記ＵＤＰ／ＩＰレベルアクセス制限ステップにおいてＵＤＰ／ＩＰパケットとして受理すると決定した場合に、ＵＤＰヘッダに記録された発信元ポート番号および宛先ポート番号並びに該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットのＵＤＰペイロードに記録された前記ＴＣＰヘッダ情報をもとに、ＴＣＰに相当するプロトコル処理を行うＴＣＰヘッダ情報格納ＵＤＰプロトコル処理ステップを前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理ステップがさらに有することができる。

本発明による通信方法ではまた、前記ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理ステップが、ＴＣＰに相当するプロトコル処理として、受理したＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットのＵＤＰヘッダ内の発信元ポート番号および宛先ポート番号を、受信したＴＣＰヘッダ内の発信元ポート番号および宛先ポート番号として取り扱い、かつ、受理した該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットの前記所定位置の情報であるＴＣＰヘッダ情報を、受信したＴＣＰヘッダ情報のうち発信元ポート番号および宛先ポート番号を除いたＴＣＰヘッダ情報として取り扱うことができる。

本発明による通信方法ではまた、前記ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理ステップが、ＴＣＰに相当するプロトコル処理として、送信用ＴＣＰヘッダ情報のうち発信元ポート番号および宛先ポート番号を送信用ＵＤＰ／ＩＰパケットのＵＤＰヘッダ内の発信元ポート番号および宛先ポート番号として記録し、かつ、残りのＴＣＰヘッダ情報を該送信用ＵＤＰ／ＩＰパケットのペイロードの前記所定位置のＴＣＰヘッダ情報として記録することができる。

本発明はまた、かかる通信方法を実施できる端末装置がかかる通信方法を実施できるアプリケーションサーバの集合の要素と通信を行うための方法であって、該端末装置が、該アプリケーションサーバの集合の要素に対する接続受付を行う接続受付サーバに接続要求を送信する接続要求送信ステップと、該接続受付サーバが、接続要求を受信する接続要求受信ステップと、接続受付サーバが、前記集合に属する各アプリケーションサーバのトラヒック量を検出するトラヒック量検出ステップと、接続受付サーバが、該トラヒック量検出ステップにより検出したトラヒック量に応じて、前記接続要求受信ステップにおいて受信した接続要求に応答するアプリケーションサーバを選択するアプリケーションサーバ選択ステップと、接続受付サーバが、該アプリケーションサーバ選択ステップにより選択したアプリケーションサーバと通信して、端末装置への前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットによる接続許可を取り決める接続許可取決ステップと、接続受付サーバが、接続許可取決ステップにより取り決めた接続許可を前記端末装置に返信する接続許可返信ステップと、前記端末装置が、該返信を受信する返信受信ステップと、前記端末装置が、該返信受信ステップにより受信した返信に含まれる、アプリケーションサーバのアドレス、ポート又はこれらの組み合わせに対し、前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットにより通信をする本通信ステップと、を含む、通信方法を提供する。

これにより、各アプリケーションサーバに関するトラヒック量に応じた負荷バランシングと、攻撃、進入に対する防御を実現することができる。

前記方法では、前記接続要求送信ステップ、接続要求受信ステップ、接続許可送信ステップ、接続許可受信ステップ、またはこれらの組み合わせにより、端末装置に対する相手認証、完全性認証鍵の交換、暗号鍵の交換またはこれらの組み合わせが行われるようにすることもできる。

これにより、さらにいわゆる「なりすまし」や「データ漏洩」、「データ改竄」を防止することも可能となる。

本発明はまた、コンピュータをかかる通信システムとして動作させるコンピュータプログラムを提供する。

これにより、通常のプロトコルスタック（通信システム）とリンクされたＯＳをもつコンピュータを簡単かつ迅速に本発明によるプロトコルスタック（通信システム）を備えたコンピュータ（サーバや端末）へと改善することができる。

本発明はまた、かかるコンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。

記憶媒体としては、フレキシブルディスク、ＣＤＲＯＭ、ＭＤ、ＤＶＤ、ＥＰＲＯＭなどを採用することができる。

本発明はまた、上述のＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを提供する。

ここで、ＵＤＰのペイロードのみを暗号化することができる。

これにより、データ漏洩を防ぎながらも、ＴＣＰとしてのポート番号を容易に参照することができ、ポート番号を使用した制御が可能となる。

なお、暗号化のための（秘密）鍵は接続要求／接続許可とともに取り決められたものを使用することができる。

また、ＴＣＰのペイロードのみを暗号化することができる。

これにより、データ漏洩を防ぎながらも、ＴＣＰのヘッダを容易に参照することができ、ＴＣＰ機能の恩恵を受けることができる。

また、ＵＤＰのペイロードのみについての完全性認証情報を含むことができる。

これにより、データ改竄を防止することが可能となる。

また、ＴＣＰのペイロードのみについての完全性認証情報を含むことができる。

これにより、応答パケットの制御（廃止）と完全性認証対象情報の削減（したがって認証情報のビット幅の削減）とによりトラヒック量を二重に節約し、より経済的な通信を実現することができる。

図１は、本発明の一実施形態におけるＵＤＰｔｃｐプロトコル（ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰプロトコル）のフォーマットを示す図である。

通常のＵＤＰパケットのペイロード部分にＴＣＰパケットのヘッダ情報およびペイロード（ＴＣＰ構造体）が格納されている。ＴＣＰヘッダ情報ＴＣＰ構造体において、ポート番号についてはＵＤＰのポート番号を使用し、チェックサムのフィールドや緊急ポインタのフィールドは、必要に応じて、ＵＤＰのチェックサム１０４で代用したり、オプション１１１内に配置したりするようにできるする。なお、図２に示すように、次回以降のパケットで必要となる緊急ポインタについては、シーケンス番号フィールド１０５や、確認応答番号フィールド１０６の上位ビットにおくように取り決めてもよい。

ＵＤＰのポート番号フィールド１０１、１０２は、本発明によるＴＣＰヘッダ情報格納ＵＤＰ／ＩＰプロトコルのポート番号フィールドであり、サーバのサービスを区別したり、端末装置のプロセスを区別したりするために用いる。

ポート番号以外のＵＤＰヘッダ部分１０３、１０４は、通常のＵＤＰとして処理を受けるために用意される。

ＵＤＰペイロード中の、ＴＣＰヘッダ情報構造体のうちポート番号を除くＴＣＰヘッダ相当部分１０５、１０６、１０７、１０８、１０９、１１０、１１１は、ＴＣＰの機能を担保するためのものであり、ＴＣＰと同様のフィールド使用がされる（例外は、上述の図２における１０５および１０６内の緊急ポインタフィールド）。

ＵＤＰペイロード中の、ＴＣＰ相当構造体のペイロード１１２には、ＴＣＰのデータ（データベースアプリケーションのデータ（ＳＱＬやテーブルなど）が格納される。

図３は、本発明の一実施形態における接続概要図である。

３つのロケーションに配置された３つのアプリケーションサーバ（この例ではデータセンタ）２１Ａ、２１Ｂ、２１Ｃがプライベートネットワークにより相互に接続されており、それぞれのアプリケーションサーバに対応する接続受付サーバ２２Ａ、２２Ｂ、２２Ｃがそれぞれのロケーションの端末装置２３Ａ、２３Ｂ、２３Ｃに応対（２４Ａ、２４Ｂ、２４Ｃ）して、負荷の少ないロケーションのアプリケーションサーバ（２１Ｃ）に端末装置（２３Ａ）を割り振っている（２５Ａ）。

図４は、本実施形態における接続シーケンスの例を示す図である。

ここでは、図３のＰＣ端末装置ａ（２３Ａ）が、そのロケーションの接続受付サーバ２２Ａに接続要求（２４Ａ）を行い、その結果、もっとも負荷の少ないアプリケーションサーバ２１Ｃにまわされる（２５Ａ）プロセスを例にとって説明する。

シーケンス３０は、接続受付サーバとアプリケーションサーバとの間の情報のやりとりであり、更新データおよび負荷情報について定期的にないし必要に応じてなされる。

シーケンス３１は、アプリケーションサーバ（ないしは担当する接続受付サーバ）間の情報交換（レプリケーション、負荷情報など）であり、更新データや負荷情報がアプリケーションサーバ間で共有され、データが同期されて均一なサービスを提供するとともに、負荷の少ないアプリケーションサーバを接続受付サーバが選択することを可能にする。

シーケンス３２は、接続受付サーバ２２Ａに対する接続要求であり、詳細は図７のステップＳ６２に関して後述する。

シーケンス３３は、ＰＣ端末装置２３Ａに対する相手認証であり、詳細は、図６のステップＳ５０９および図７のステップＳ６３２に関して後述する。

シーケンス３４は、接続受付サーバから負荷の少ないアプリケーションサーバへの接続（対応）要求であり、プライベートネットワークを介してなされる。

シーケンス３５は、負荷の少ないアプリケーションサーバから接続受付サーバへの接続（対応）許可であり、やはりプライベートネットワークを介してなされる。ただし、後述するように、負荷が既に容量オーバーしているときは、図示しない接続不許可信号（パケット）が返信される。

シーケンス３６は、ＰＣ端末装置２３Ａに対する接続許可であり、選択されたアプリケーションサーバＣ（２１Ｃ）の指定ＩＰアドレス、指定ポート番号、鍵（暗号・完全性認証用）などが同時に返送される。

シーケンス３７は、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰ（ＵＤＰｔｃｐ）接続を確立するものであり、図７のステップＳ６５および図８のステップＳ７６に関して後述する。

シーケンス３８は、通常のセッションのためのＵＤＰｔｃｐ接続であり、再送制御、フロー制御、パケット順番制御、輻輳制御といったＴＣＰの機能を利用することができる。また、適宜、独自に暗号化や完全性認証機能を付け加えることもできる。

シーケンス３８１、３８２、３８３、３８４は、アプリケーションサーバとのデータの送受信であり、一見ＵＤＰであるが、本発明のＴＣＰヘッダ情報格納ＵＤＰ（ＵＤＰｔｃｐ）プロトコルにより、ＴＣＰと同様の全二重コネクションを介して、信頼性の高いデータ交換を行うことができる。目的のデータ交換を果たした後は、シーケンス３９によりＵＤＰｔｃｐ接続の切断を行う。

図５は、本実施例の全体構成（同様の構成は省略）を示す図である。

アプリケーションサーバ２１Ａ中には従来のプロトコルスタック２１１、２１２、２１３、２１３ａ、２１３ｂ、２１４、２１６等のほかに、本発明のための新しいプロトコルスタック２１５、２１５ａ、２１５ｂ６がある。

ＵＤＰエミュレータ２１５は、ＵＤＰのパケットのペイロードを検査して、ＴＣＰヘッダ情報構造体を含む場合に、本発明によるＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットとして取り扱うべく、ＵＤＰｔｃｐ処理モジュール２１５ａに処理を任せ、そうでない場合には普通のＵＤＰパケットとして処理する。

ＵＤＰｔｃｐ処理モジュール２１５ａは、ＴＣＰｅｍｕｌａｔｏｒ２１５ｂを介して従前の拡張されたＳｏｃｋｅｔ´インターフェース２１６とデータ交換を行う。一方、Ｓｏｃｋｅｔ´インターフェース２１６は、ＤＢアプリケーションサーバプログラム（正確にはプロセス）と従前のＴＣＰのプロトコルヘッダ情報格納ＵＤＰ／ＩＰ（ＵＤＰｔｃｐ）用の（図示しない）独自フォーマットに従いデータ交換を行うことができる。。すなわち、上位アプリケーションは、本発明によるＵＤＰｔｃｐ処理モジュール２１５ａを意識せずに従前のインターフェース２１６に従ったデータ交換を行うことができる。また、このような実施形態においては、本発明によるＵＤＰｔｃｐ通信を採用するかどうかの判断機構（ＵＤＰｅｍｕｌａｔｏｒ２１５内、ＵＤＰｔｃｐ処理モジュール２１５ａ内、又はＴＣＰｅｍｕｌａｔｏｒ２１５ｂ内にいずれに存在してもよい）が必要となるが、この機構についてはＩＰアドレス、ポート番号又は透過的な認証ＩＤで区別するなど、明らかに公知の手法を採用することができる。また、そもそも本発明によるＵＤＰｔｃｐに対応していない通信相手に対しては、通常のＴＣＰ又はＵＤＰの通信をＴＣＰｅｍｕｌａｔｏｒ２１５ｂ又はＵＤＰｅｍｕｌａｔｏｒ２１５において実現できることが明らかである。

図５中の他の装置（２２Ａ、２３Ａ、２３Ｂ）も上記と同様の構成を備えており、本発明によるＴＣＰヘッダ情報格納ＵＤＰ／ＩＰプロトコル（パケット）を処理できるようになっている。

サーバ（２１Ａ、２２Ａ）と端末装置（２３Ａ、２３Ｂ、２３Ｃ）間の通信はルータ４１などを含むインターネット４２を介して行われる一方、サーバ（２１Ａ、２２Ａ、２１Ｂ、２２Ｂ、２１Ｃ、２２Ｃ）間の通信は、セキュリティを特に重視して（仮想）プライベートネットワーク４３によって行われる。

図６は、本実施例における接続受付サーバの処理フローを示す図である。

ステップＳ５０１で、本発明によるＵＴＰｔｃｐ（ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰ）接続受付サーバがスタートする。

ついで、ステップＳ５０２で、担当するアプリケーションサーバからデータ更新履歴および現在負荷情報を取得し、ステップＳ５０３で、接続受付サーバ間の情報交換により更新データの同期および負荷情報の共有を行う。かかる処理自体については、サーバクラスタ技術ないしミラーリング／レプリケーション技術に関して当業者に周知であり詳述はしない。

次いで、ステップＳ５０４で、公知の受信パケット解析によりＴＣＰであるかどうかが検出され、ＴＣＰの場合は接続要求が破棄され、ＴＣＰでない場合はステップＳ５０５に進む。本実施形態では、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰ専用に構成しており、ベースはＵＤＰだからである。

ステップＳ５０５では、ＵＤＰであるかどうかが検出されＵＤＰである場合にはステップＳ５０６にすすみ、そうでない場合にはパケットが破棄される。

ステップＳ５０６では、ＵＤＰのペイロードにＴＣＰ構造体ＴＣＰヘッダ情報を含むかどうかが検出され、含む場合にはステップＳ５０７に進み、含まない場合にはパケットが破棄される。本実施形態では、接続受付サーバが受付自体も本発明によるＴＣＰヘッダ情報格納ＵＤＰ／ＩＰ（ＵＤＰｔｃｐ）のみで行うポリシーを採用しているからである。なお、端末装置が様々なプロトコルに対応した別の実施形態では、接続受付サーバに対する接続受付の段階は、通常のＴＣＰやＵＤＰとすることもできる。

ステップＳ５０７では、所定の接続要求であるかどうかが検出され、接続要求でない場合には、パケットが破棄されるが、接続要求である場合にはＴＣＰヘッダ情報格納ＵＤＰ／ＩＰによりＴＣＰ相当の接続を確立してこの接続を用いてステップＳ５０８からＳ５１２までが実行される。

ステップＳ５０８では、（１）として、（２）の相手認証のための秘密鍵通信を公知の方法（ＤＨ公開鍵配送法等）で、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰのペイロード上に確立する。

ステップＳ５０９では、（２）として、（別の固有公開鍵や事前秘密共有等の）公知の方法により相手認証を行う。

ステップＳ５１０では、（３）として、必要な場合に、ＵＤＰとしてのペイロードやＴＣＰとしてのペイロードの暗号化ないし完全性認証用の新鍵（指定鍵）を生成して、（４）（５）の送信に備える。また、オプションとして、乱数発生モジュール等により指定Ｓｅｑ＃を生成して、受付サーバに正規に接続要求を行った端末装置と担当するサーバ間でこの指定Ｓｅｑ＃を共有させることにより、この指定Ｓｅｑ＃で接続要求を試みた正規の端末装置に対してのみサーバが応答するようにサーバ（のＵＤＰｔｃｐプロトコルスタック）を設定することができる。なお、端末装置と接続受付サーバとの通信自体には、このＳｅｑ＃レベルの制御を行わなう必要はあまり顕著でない。通常、接続受付サーバは帯域幅が少ない定額制の契約しており、その通信のトラヒックが接続受付用途に制限されるからである。

ステップＳ５１１では、（４）として、ステップＳ５０３の共有情報をもとに負荷の少ないアプリケーションサーバ（データセンタサーバ）を選択して、接続要求（＋必要な新鍵（指定鍵）、指定Ｓｅｑ＃）を送信する。

ステップＳ５１２では、（５）として、選択したアプリケーションサーバからの接続許可を受信し、そのアプリケーションサーバの指定ＩＰアドレス、指定ポート番号、および必要な指定鍵（新鍵）、指定Ｓｅｑ＃（ただしサーバから希望があった場合には、その希望Ｓｅｑ＃）とともに端末装置に送信する。なお、接続不許可の場合には、その旨を示す信号（パケット）を端末装置に送信することになる。

図７は、本実施例における端末装置の処理フローを示す図である。

ステップＳ６１で、本発明によるＵＤＰｔｃｐ（ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰ）プロトコル端末装置がスタートする。

ステップＳ６２では、接続受付サーバに対し、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰによる接続要求を、ＴＣＰ構造体ＴＣＰヘッダ情報を利用することにより、ＴＣＰに準じてＳＹＮ／ＡＣＫベースで行い、全二重通信を確立する。

ステップＳ６３では、確立したＵＤＰｔｃｐ接続（ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰによる全二重通信）により、図６のステップＳ５０８（１）、５０９（２）、５１２（５）に対応した処理を行う。すなわち、（１）秘密鍵通信を確立し、（２）端末装置として相手認証をしてもらい、（３）選択されたアプリケーションサーバの指定ＩＰアドレス、指定ポート番号、必要な指定鍵、指定（希望）Ｓｅｑ＃を受信する。ついで、ステップＳ６４では、同様にＴＣＰ構造体ＴＣＰヘッダ情報を利用してＵＤＰｔｃｐとしての接続を一旦切断する。

ステップＳ６５では、今度は指定されたＩＰアドレスに対応するアプリケーションサーバに対して、ＵＤＰペイロード中のＴＣＰ構造体ＴＣＰヘッダ情報を用いて、ＵＤＰにより前記ＴＣＰに相当する接続要求（ただし、Ｓｅｑ＃は、Ｓ６３３で受信した指定Ｓｅｑ＃を用いる）を行い、同様に全二重通信（ＵＤＰｔｃｐ）を確立する。

ステップＳ６６では、ステップＳ６５で確立した通信を用いて、目的とするデータベースアプリケーションに係るデータ交換を行う。この場合、ＴＣＰ構造体ＴＣＰヘッダ情報を用いてＴＣＰの機能を柔軟に生かすことができる。また、事前に配布された指定鍵がある場合には、これを用いてパケットの（一部ペイロードの）暗号化や完全性認証を行うことができる。

ステップＳ６７では、目的とするデータ交換の終了時に、上記と同様にＴＣＰ構造体ＴＣＰヘッダ情報を利用して、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰとしての接続の切断を行うことができる。

図８は、本実施例におけるアプリケーションサーバ（データセンタ）の処理フローを示す図である。

ステップＳ７１で、本発明によるＴＣＰヘッダ情報格納ＵＤＰ／ＩＰ（ＵＤＰｔｃｐ）プロトコルのアプリケーションサーバ（データセンタ）がスタートする。

ついで、ステップＳ７２では、上述の情報交換が行われる。すなわち、直近の更新データや現在のサーバ負荷の情報を接続受付サーバに渡すとともに、接続受付サーバ間で情報交換された他アプリケーションサーバの更新データを自アプリケーションサーバに反映する（ＳＱＬを実行するなどする）。

ステップＳ７３では、なんらかの接続受付サーバから接続要求（＋必要な指定鍵）を受信したかどうかが検出され、受信していない場合にはステップＳ７２に戻り、受信している場合にはステップＳ７４に進む。

ステップＳ７４では、自サーバの負荷が接続要求に耐えられるかどうか（または見積応答時間が適当かどうか）が（当然、プログラムにより自動的に）判断され、負荷オーバーの場合にはステップＳ７５に移って、接続不許可信号を返信してステップＳ７２に戻る。負荷オーバーでない場合はステップＳ７６からＳ７８までが実行される。

ステップＳ７６では、まず、（１）サービスするための指定ポート番号（＋必要な希望Ｓｅｑ＃）を、所定のメモリ内容もしくはその他の変数（他のプロセス／セッション等によるポート（＋Ｓｅｑ＃）使用状況など）から決定して、接続受付サーバに接続許可信号＋ＩＰアドレス＋指定ポート番号（＋希望Ｓｅｑ＃）を返す。ついでした後、ステップＳ７７で（２）その指定ポート番号についてはを指定Ｓｅｑ＃（又は希望Ｓｅｑ＃）のみをＬｉｓｔｅｎしてＵＤＰペイロード中のＴＣＰ構造体ＴＣＰヘッダ情報のＳＹＮがＯＮのパケットを待ち、ＡＣＫ／ＳＹＮがＯＮのＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを返して、更にＡＣＫを待ち、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰ（ＵＤＰｔｃｐ）の全二重通信を確立する。

その後、ステップＳ７８７では、（３）として、図７のステップＳ６６に対応した本発明にいよるＴＣＰヘッダ情報格納ＵＤＰ／ＩＰ（ＵＤＰｔｃｐ）プロトコルの通信を行うことができ、またステップＳ７９８では、同様に接続の切断が可能である。

なお、これらのステップの処理は、図５のＵＤＰエミュレータ２１５、ＵＤＰｔｃｐモジュール２１５ａ、ＴＣＰエミュレータ２１５ｂ、Ｓｏｃｋｅｔインターフェース´２１６のコンピュータプログラムにより、当業者には、明らかに実現可能であるすることができる。

本発明は、インターネットを介した通信環境に広く利用可能である。特に、トラヒックに応じた従量制が採用されているアプリケーションサーバ周辺の通信に利用可能である。また、進入、攻撃、なりすまし、データ漏洩、データ改竄の防止が必要となる専用サービスに特に利用可能である。また、もともとＴＣＰベースであったネットワークアプリケーションを簡易にＵＤＰベースに変更したいときにも有用である。

本発明の一実施形態におけるＵＤＰｔｃｐプロトコル（ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰプロトコル）のフォーマット（最初のパケット）を示す図である。 本発明の一実施形態におけるＵＤＰｔｃｐプロトコル（ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰプロトコル）のフォーマット（次回以降のパケット）を示す図である。 本発明の一実施形態における接続概要図である。 本発明の一実施形態における接続シーケンスの例を示す図である。 本発明の一実施形態における一実施例の全体構成を示す図である。 本発明の一実施例における接続受付サーバの処理フローを示す図である。 本発明の一実施例における端末装置の処理フローを示す図である。 本発明の一実施例におけるアプリケーションサーバ（データセンタ）の処理フローを示す図である。

符号の説明

１０１，１０２ ＵＤＰのポート番号フィールド（ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰのポート番号フィールド）
１０３，１０４ その他のＵＤＰヘッダ部分
１０５，１０６，１０７，１０８，１０９，１１０，１１１ ＵＤＰペイロード中の、ＴＣＰ構造体ＴＣＰヘッダ情報のうちポート番号を除くＴＣＰヘッダ相当部分
１１２ ＵＤＰペイロード中の、ＴＣＰ構造体ＴＣＰヘッダ情報のペイロード
２１Ａ，２１Ｂ，２１Ｃ アプリケーションサーバ（データセンタ）
２１１，２１２，２１３，２１３ａ，２１３ｂ，２１４ 従来のプロトコルスタック
２１５，２１５ａ，２１５ｂ 本発明のための新しいプロトコルスタック
２１６ 従前のソケットインターフェース本発明のための新しいプロトコルスタック
２２Ａ，２２Ｂ，２２Ｃ 各アプリケーションサーバ（データセンタ）に対応した接続受付サーバ
２３Ａ，２３Ｂ，２３Ｃ 各アプリケーションサーバ（データセンタ）のロケーションに近いＰＣ端末装置
２４Ａ，２４Ｂ，２４Ｃ 接続受付セッション
２５Ａ，２５Ｂ，２５Ｃ 通常のセッション
３０ 接続受付サーバとアプリケーションサーバ（データセンタ）との間の情報のやりとり
３１ アプリケーションサーバ（ないしは担当接続受付サーバ）間の情報交換（レプリケーション，負荷情報など）
３２ 接続受付サーバに対する接続要求
３３ ＰＣ端末装置に対する相手認証
３４ 接続受付サーバから負荷の少ないアプリケーションサーバ（データセンタ）への接続（対応）要求
３５ 負荷の少ないアプリケーションサーバ（データセンタ）から接続受付サーバへの接続（対応）許可
３６ ＰＣ端末装置に対する接続許可（指定ＩＰアドレス，指定ポート番号，鍵（暗号・完全性認証用）など）
３７ ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰ（ＵＤＰｔｃｐ）接続の確立
３８ 通常のセッションのためのＵＤＰｔｃｐ接続
３８１，３８２，３８３，３８４ アプリケーションサーバ（データセンタ）とのデータの送受信
３９ ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰ（ＵＤＰｔｃｐ）接続の切断
４１ ルータ
４２ インターネット
４３ プライベートネットワーク（専用線）または仮想プライベートネットワーク

Claims (20)

1. ＵＤＰ／ＩＰパケットのペイロードの所定位置に発信元ポート番号および宛先ポート番号以外のＴＣＰヘッダ情報を格納したパケットである、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを処理するＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段を含む通信システム。
2. 前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを、まずＵＤＰ／ＩＰパケットとして受理するか廃棄するかを決定するＵＤＰ／ＩＰレベルアクセス制限手段を前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段がさらに備え、該アクセス制限手段が廃棄すると決定した場合に、該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段がＴＣＰに相当するプロトコル処理を行わない制限することを特徴とする、請求項１に記載の通信システム。
3. 前記ＵＤＰ／ＩＰレベルアクセス制限手段がＵＤＰ／ＩＰパケットとして受理すると決定した場合に、ＵＤＰヘッダに格納された発信元ポート番号および宛先ポート番号並びに該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットのＵＤＰペイロードに格納された前記ＴＣＰヘッダ情報をもとにＴＣＰに相当するプロトコル処理を行う、ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理手段を前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段がさらに備える、請求項２に記載の通信システム。
4. 前記ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理手段が、ＴＣＰに相当するプロトコル処理として、受理したＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットのＵＤＰヘッダ内の発信元ポート番号および宛先ポート番号を、受信したＴＣＰヘッダ内の発信元ポート番号および宛先ポート番号として取り扱い、かつ、受理した該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットの前記所定位置の情報であるＴＣＰヘッダ情報を、受信したＴＣＰヘッダ情報のうち発信元ポート番号および宛先ポート番号を除いたＴＣＰヘッダ情報として取り扱う、請求項３に記載の通信システム。
5. 前記ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理手段が、ＴＣＰに相当するプロトコル処理として、送信用ＴＣＰヘッダ情報のうち発信元ポート番号および宛先ポート番号を送信用ＵＤＰ／ＩＰパケットのＵＤＰヘッダ内の発信元ポート番号および宛先ポート番号として格納し、かつ、残りのＴＣＰヘッダ情報を該送信用ＵＤＰ／ＩＰパケットのペイロードの前記所定位置のＴＣＰヘッダ情報として格納する、請求項３又は４に記載の通信システム。
6. ＵＤＰ／ＩＰパケットのペイロードの所定位置に発信元ポート番号および宛先ポート番号以外のＴＣＰヘッダ情報を格納したパケットである、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを処理するＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段（ＵＤＰｔｃｐ／ＩＰプロトコルスタック）を含む通信システムにより通信を行う、アプリケーションサーバの集合への接続受付を行う接続受付サーバであって、
   前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段を含む通信システムを備えた端末装置からの接続要求を受信する接続要求受信手段と、
   前記集合に属する各アプリケーションサーバのトラヒック量を検出するトラヒック量検出手段と、
   該トラヒック量検出手段により検出したトラヒック量に応じて該接続要求受信手段が受信した接続要求に応答するアプリケーションサーバを選択するアプリケーションサーバ選択手段と、
   該アプリケーションサーバ選択手段により選択したアプリケーションサーバと通信して、端末装置への前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットによる接続許可を取り決める接続許可取決手段と、
   接続許可取決手段により取り決めた接続許可を前記端末装置に返信する接続許可返信手段と、
   を有する接続受付サーバ。
7. 前記接続受付サーバの通信システムにおいて、前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを、まずＵＤＰ／ＩＰパケットとして受理するか廃棄するかを決定するＵＤＰ／ＩＰレベルアクセス制限手段を前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段がさらに備え、該アクセス制限手段が廃棄すると決定した場合に、該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段がＴＣＰに相当するプロトコル処理を行わない制限することを特徴とする、請求項６に記載の接続受付サーバ。
8. 前記接続受付サーバの通信システムにおいて、前記ＵＤＰ／ＩＰレベルアクセス制限手段がＵＤＰ／ＩＰパケットとして受理すると決定した場合に、ＵＤＰヘッダに格納された発信元ポート番号および宛先ポート番号並びに該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットのＵＤＰペイロードに格納された前記ＴＣＰヘッダ情報をもとにＴＣＰに相当するプロトコル処理を行う、ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理手段を、前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段がさらに備える、請求項７に記載の接続受付サーバ。
9. 前記接続受付サーバの通信システムにおいて、前記ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理手段が、ＴＣＰに相当するプロトコル処理として、受理したＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットのＵＤＰヘッダ内の発信元ポート番号および宛先ポート番号を、受信したＴＣＰヘッダ内の発信元ポート番号および宛先ポート番号として取り扱い、かつ、受理した該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットの前記所定位置の情報であるＴＣＰヘッダ情報を、受信したＴＣＰヘッダ情報のうち発信元ポート番号および宛先ポート番号を除いたＴＣＰヘッダ情報として取り扱う、請求項８に記載の接続受付サーバ。
10. 前記接続受付サーバの通信システムにおいて、前記ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理手段が、ＴＣＰに相当するプロトコル処理として、送信用ＴＣＰヘッダ情報のうち発信元ポート番号および宛先ポート番号を送信用ＵＤＰ／ＩＰパケットのＵＤＰヘッダ内の発信元ポート番号および宛先ポート番号として格納し、かつ、残りのＴＣＰヘッダ情報を該送信用ＵＤＰ／ＩＰパケットのペイロードの前記所定位置のＴＣＰヘッダ情報として格納する、請求項８又は９に記載の接続受付サーバ。
11. ＵＤＰ／ＩＰパケットのペイロードの所定位置に発信元ポート番号および宛先ポート番号以外のＴＣＰヘッダ情報を格納したパケットである、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを処理するＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段を含む通信システムを備えた端末装置であって、
    接続受付サーバに接続要求を送信する接続要求送信手段と、
    接続受付サーバから接続要求に対する返信を受信する返信受信手段と、
    該返信受信手段が受信した返信に含まれる、アプリケーションサーバのアドレス、ポート番号又はこれらの組合せに対し、前記通信システムにより前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットによる通信を行うことを特徴とする、端末装置。
12. ＵＤＰ／ＩＰパケットのペイロードの所定位置に発信元ポート番号および宛先ポート番号以外のＴＣＰヘッダ情報を格納したパケットであるＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを処理するＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理ステップを含む通信方法。
13. 前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを、まずＵＤＰ／ＩＰパケットとして受理するか廃棄するかを決定するＵＤＰ／ＩＰレベルアクセス制限ステップを、前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理ステップが有し、該アクセス制限ステップにおいて廃棄すると決定した場合に、該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理ステップがＴＣＰに相当するプロトコル処理を行わない制限することを特徴とする、請求項１２に記載の通信方法。
14. 前記ＵＤＰ／ＩＰレベルアクセス制限ステップにおいてＵＤＰ／ＩＰパケットとして受理すると決定した場合に、ＵＤＰヘッダに格納された発信元ポート番号および宛先ポート番号並びに該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットのＵＤＰペイロードに格納された前記ＴＣＰヘッダ情報をもとに、ＴＣＰに相当するプロトコル処理を行うＴＣＰヘッダ情報格納ＵＤＰプロトコル処理ステップを前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理ステップがさらに有する請求項１３に記載の通信方法。
15. 前記ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理ステップが、ＴＣＰに相当するプロトコル処理として、受理したＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットのＵＤＰヘッダ内の発信元ポート番号および宛先ポート番号を、受信したＴＣＰヘッダ内の発信元ポート番号および宛先ポート番号として取り扱い、かつ、受理した該ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットの前記所定位置の情報であるＴＣＰヘッダ情報を、受信したＴＣＰヘッダ情報のうち発信元ポート番号および宛先ポート番号を除いたＴＣＰヘッダ情報として取り扱う、請求項１４に記載の通信方法。
16. 前記ＴＣＰヘッダ情報格納ＵＤＰプロトコル処理ステップが、ＴＣＰに相当するプロトコル処理として、送信用ＴＣＰヘッダ情報のうち発信元ポート番号および宛先ポート番号を送信用ＵＤＰ／ＩＰパケットのＵＤＰヘッダ内の発信元ポート番号および宛先ポート番号として格納し、かつ、残りのＴＣＰヘッダ情報を該送信用ＵＤＰ／ＩＰパケットのペイロードの前記所定位置のＴＣＰヘッダ情報として格納する、請求項１４又は１５に記載の通信方法。
17. ＵＤＰ／ＩＰパケットのペイロードの所定位置に発信元ポート番号および宛先ポート番号以外のＴＣＰヘッダ情報を格納したパケットである、ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットを処理するＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケット処理手段（ＵＤＰｔｃｐ／ＩＰプロトコルスタック）を含む通信システムを備えた端末装置が、該通信システムを備えたアプリケーションサーバの集合の要素と通信するための方法であって、
    該端末装置が、該アプリケーションサーバの集合の要素に対する接続受付を行う接続受付サーバに接続要求を送信する接続要求送信ステップと、
    該接続受付サーバが、接続要求を受信する接続要求受信ステップと、
    接続受付サーバが、前記集合に属する各アプリケーションサーバのトラヒック量を検出するトラヒック量検出ステップと、
    接続受付サーバが、該トラヒック量検出ステップにより検出したトラヒック量に応じて、前記接続要求受信ステップにおいて受信した接続要求に応答するアプリケーションサーバを選択するアプリケーションサーバ選択ステップと、
    接続受付サーバが、該アプリケーションサーバ選択ステップにより選択したアプリケーションサーバと通信して、端末装置への前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットによる接続許可を取り決める接続許可取決ステップと、
    接続受付サーバが、接続許可取決ステップにより取り決めた接続許可を前記端末装置に返信する接続許可返信ステップと、
    前記端末装置が、該返信を受信する返信受信ステップと、
    前記端末装置が、該返信受信ステップにより受信した返信に含まれる、アプリケーションサーバのアドレス、ポート番号又はこれらの組合せに対し、前記ＴＣＰヘッダ情報格納ＵＤＰ／ＩＰパケットにより通信する本通信ステップと、
    を含む、通信方法。
18. 前記接続要求送信ステップ、接続要求受信ステップ、接続許可送信ステップ、接続許可受信ステップ、またはこれらの組み合わせにより、端末装置に対する相手認証、完全性認証鍵の交換、暗号鍵の交換またはこれらの組み合わせが行われる、請求項１７に記載の通信方法。
19. コンピュータを請求項１から５のいずれか一項に記載の通信システムとして動作させるコンピュータプログラム。
20. 請求項１９に記載のコンピュータプログラムを格納したコンピュータ読み取り可能な記録媒体。

Images