サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置であって、前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段と、前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段と、を備え、前記クライアント側生存確認手段は、前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第1の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第2の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第3の時間が経過した場合に、前記トンネルの状態が悪化したと判定することを特徴とするクライアント装置。前記第1の時間は前記第3の時間より長く、当該第3の時間は前記第2の時間より長いことを特徴とする請求項1に記載のクライアント装置。請求項1又は2に記載のクライアント装置と、前記サーバ装置とを備える通信システムであって、前記サーバ装置は、前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段と、前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段と、を備え、前記サーバ側生存確認手段は、前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第4の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定することを特徴とする通信システム。請求項3に記載の通信システムにおいて、前記サーバ側トンネル通信手段は、前記クライアント側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、前記クライアント側トンネル通信手段は、最後に再送信を行った第1のパケットの送信番号と、前記サーバ側トンネル通信手段から受信した第2のパケットの送信番号とを比較し、当該第2のパケットの送信番号が前記第1のパケットの送信番号1以下である場合に、当該第2のパケットを再送信し、当該第2のパケットの送信番号が前記第1のパケットの送信番号2以上である場合において、キューの中にパケットが既に存在しない場合に、当該第2のパケットをキューに格納し、所定の時間経過後に、当該第2のパケットを再送信する再送信順序制御手段を備えることを特徴とする通信システム。請求項4に記載の通信システムにおいて、前記サーバ側トンネル通信手段は、前記サーバ側生存確認手段により状態が悪化したと判定されたトンネルを使用しないことを特徴とする通信システム。請求項3ないし5のうちいずれか1項に記載の通信システムにおいて、前記クライアント側トンネル通信手段は、前記サーバ側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、前記サーバ側トンネル通信手段は、最後に再送信を行った第1のパケットの送信番号と、前記クライアント側トンネル通信手段から受信した第2のパケットの送信番号とを比較し、当該第2のパケットの送信番号が前記第1のパケットの送信番号1以下である場合に、当該第2のパケットを再送信し、当該第2のパケットの送信番号が前記第1のパケットの送信番号2以上である場合において、キューの中にパケットが既に存在しない場合に、当該第2のパケットをキューに格納し、所定の時間経過後に、当該第2のパケットを再送信する再送信順序制御手段を備えることを特徴とする通信システム。請求項6に記載の通信システムにおいて、前記クライアント側トンネル通信手段は、前記クライアント側生存確認手段により状態が悪化したと判定されたトンネルを使用しないことを特徴とする通信システム。サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置と、前記サーバ装置とを備える通信システムにより実行される生存確認方法であって、前記クライアント装置は、前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第1の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第2の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第3の時間が経過した場合に、前記トンネルの状態が悪化したと判定し、前記サーバ装置は、前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第4の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定することを特徴とする生存確認方法。コンピュータを、サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置として機能させるためのプログラムであって、コンピュータを、前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段、前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段、として機能させ、前記クライアント側生存確認手段は、前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第1の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第2の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第3の時間が経過した場合に、前記トンネルの状態が悪化したと判定することを特徴とするプログラム。トンネリングを用いた通信を行う場合に、途中経路で通過するファイアウォール装置やプロクシサーバ装置の機能により、長時間無通信の場合に、強制的に切断させられてしまう場合や、切断状態にならないまでも信号が疎通しなくなっている、いわゆるトンネルが詰まった状態が生じる場合がある。このような状態を回避するために、クライアント装置がトンネルサーバ装置に生存確認要求を定期的に送信し、クライアント装置がサーバ装置から生存確認要求応答を受信することにより、クライアント装置がトンネル状態の判断や再接続等を行う疎通確認技術が従来からある。上記の技術では、生存確認要求の送信間隔が短いと、本来のデータパケット以外の無駄なパケットが増加し、無通信クライアントを含む多数のクライアントのトラフィックが集中するトンネルサーバ装置やそのネットワークにおいて、処理負荷が増加し、性能低下を招く恐れがある。逆に、送信間隔を長くしてしまうと、詰まり状態を長時間検出できず、通信が長時間途切れたりする問題が生じる。つまり、従来の疎通確認のための技術では、処理負担軽減と異常状態検出時間の短縮という相反する条件を同時に満たすことは困難であった。一方、TCPIP等の技術により実現される信頼性が担保された通信路では、通信路上のパケットドロップ等の外乱によりパケットの再送等が発生し、結果として遅延が生じることで通信が安定しない場合がある。これを解消するため、複数本のトンネル接続を束ねて1本の論理的なトンネル接続を構成し、その中にパケットを分散して送信することで通信の安定化を図る従来技術がある。上記の技術では、より安定した通信を実現するために、複数本のトンネル接続の各々について、例えば上述した疎通確認技術を適用することにより、無通信切断防止及び疎通確認を行うとともに、複数本のトンネル接続経由でパケットを流す際に、通信状態の悪いトンネル接続を避けてパケットを流すことが望ましい。本発明は上記の問題点に鑑みてなされたものであり、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たすとともに、複数本のトンネル接続を束ねて通信を行う通信方式において通信状態の悪いトンネル接続を避ける動作を迅速に行うことを可能とした生存確認の技術を提供することを目的とする。ここで、複数本のトンネル接続を束ねてパケットを通すことで通信を安定化させる従来技術を用いる場合、送信側で順次送信しても途中経路の外乱等の影響で受信側では順序性が担保されない場合があり、その結果、パケットが順序逆転するため、電話やテレビ会議等のリアルタイム性が要求される場合など、アプリケーションの特性によりアプリケーションが正常に動作しない等の影響が出ていた。本発明の一実施形態では、このような順序逆転を防止する技術を提供することも目的としている。上記の課題を解決するために、本発明は、サーバ装置との間に構築されたトンネルを介してデータ通信を行うクライアント装置であって、前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段と、前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段と、を備え、前記クライアント側生存確認手段は、前記クライアント装置が備えるアプリケーション部からのデータパケット送信がない場合に、第1の時間間隔で生存確認要求を前記サーバ装置に送信し、当該生存確認要求を受信した前記サーバ装置から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置に送信し、前記アプリケーション部からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の第2の時間経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第3の時間が経過した場合に、前記トンネルの状態が悪化したと判定することを特徴とするクライアント装置として構成することができる。前記第1の時間は前記第3の時間より長く、当該第3の時間は前記第2の時間より長いように設定することとしてよい。また、本発明は、上記クライアント装置と、前記サーバ装置とを備える通信システムであって、前記サーバ装置は、前記サーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段と、前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段と、を備え、前記サーバ側生存確認手段は、前記サーバ装置からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置から受信した場合に、生存確認要求応答を前記クライアント装置に送信し、前記サーバ装置からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記クライアント装置に送信後、第4の時間経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置から受信しない場合に、前記トンネルの状態が悪化したと判定することを特徴とする通信システムとして構成することもできる。上記通信システムにおいて、前記サーバ側トンネル通信手段は、前記クライアント側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、前記クライアント側トンネル通信手段は、最後に再送信を行った第1のパケットの送信番号と、前記サーバ側トンネル通信手段から受信した第2のパケットの送信番号とを比較し、当該第2のパケットの送信番号が前記第1のパケットの送信番号1以下である場合に、当該第2のパケットを再送信し、当該第2のパケットの送信番号が前記第1のパケットの送信番号2以上である場合において、キューの中にパケットが既に存在しない場合に、当該第2のパケットをキューに格納し、所定の時間経過後に、当該第2のパケットを再送信する再送信順序制御手段を備えるように構成してもよい。また、前記サーバ側トンネル通信手段は、前記サーバ側生存確認手段により状態が悪化したと判定されたトンネルを使用しないように構成してもよい。また、上記通信システムにおいて、前記クライアント側トンネル通信手段は、前記サーバ側トンネル通信手段との間に構築された複数のトンネルに対して順次、送信順を示す送信番号を付したパケットを送信する分配送信手段を備え、前記サーバ側トンネル通信手段は、最後に再送信を行った第1のパケットの送信番号と、前記クライアント側トンネル通信手段から受信した第2のパケットの送信番号とを比較し、当該第2のパケットの送信番号が前記第1のパケットの送信番号1以下である場合に、当該第2のパケットを再送信し、当該第2のパケットの送信番号が前記第1のパケットの送信番号2以上である場合において、キューの中にパケットが既に存在しない場合に、当該第2のパケットをキューに格納し、所定の時間経過後に、当該第2のパケットを再送信する再送信順序制御手段を備えるように構成してもよい。また、前記クライアント側トンネル通信手段は、前記クライアント側生存確認手段により状態が悪化したと判定されたトンネルを使用しないように構成してもよい。本発明によれば、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たすとともに、複数本のトンネル接続を束ねて通信を行う通信方式において通信状態の悪いトンネル接続を避ける動作を迅速に行うことを可能とした生存確認の技術を提供することが可能となる。以下、図面を参照して本発明の実施の形態を説明する。<第1の実施の形態>システム構成図2に、第1の実施の形態におけるシステムの全体構成を示す。図2に示すように、本実施の形態のシステムは、インターネット5と、企業内ネットワーク等のプライベートネットワーク6との境界に設置されるファイアフォール装置4、ファイアウォール装置4配下にあるトンネルクライアント機能を有するクライアント装置1、トンネルサーバ機能を有するサーバ装置2、及び、クライアント装置1と通信を行う通信相手装置3とを含む。本実施の形態では、サーバ装置2と、通信相手装置3は、インターネット5に接続されている。図2に示すように、クライアント装置1は、クライアント側のトンネル接続に係る処理を行うトンネル機能部11と、本発明に係るクライアント側の生存確認処理を行う生存確認機能部12と、IP電話や映像会議等の目的の通信を行うアプリケーション部13を備える。サーバ装置2は、サーバ側のトンネル接続に係る処理を行うトンネル機能部21と、本発明に係るサーバ側の生存確認処理を行う生存確認機能部22を備える。本実施の形態におけるクライアント装置1は、OSオペレーティングシステムと、上記機能部に対応するプログラム等を備えるコンピュータPC、携帯端末等である。また、本実施の形態におけるサーバ装置2は、OS、上記機能部に対応するプログラム等を備えるコンピュータである。図3に、クライアント装置1の生存確認機能部12の機能構成を示す。図3に示すように、生存確認機能部12は、生存確認用パケット送受信制御部121、情報格納部122、タイマー1C、タイマー2C、タイマー3C、タイマー4Cを有する。生存確認用パケット送受信制御部121は、生存確認のためにパケットの送受信を制御する機能部であり、タイマーを参照しながら後述するような処理動作を行う。情報格納部122は、状態良好、応答悪化、生存確認要求応答受領送信済みフラグを格納する。タイマー1Cは再接続発動タイマーであり、クライアント装置1が最終パケットを送信してから、再接続を実施するまでの時間を計測する。本実施の形態では、タイマー1Cが計測する時間として5秒程度の値を想定している。タイマー2Cは状態悪化判定タイマーであり、クライアント装置1が最終パケットを送信してから、その応答が返るまでの基準となる時間を計測する。本実施の形態では、タイマー2Cが計測する時間として3秒程度の値を想定している。タイマー3Cは生存確認要求送信兼応答受領タイマーであり、連続パケット送信時に生存確認要求を載せて送信する最低時間間隔を計測すると同時に、生存確認要求応答受領の送信までの期限を計測する。本実施の形態では、タイマー3Cが計測する時間として0.5秒程度の値を想定している。タイマー4Cは生存確認要求最長送信タイマーであり、長時間パケットの送信が無い場合等に単独の生存確認要求を送信する期限を計測する。本実施の形態では、タイマー4Cが計測する時間として10秒程度の値を想定している。図4に、サーバ装置2の生存確認機能部22の機能構成を示す。図4に示すように、生存確認機能部22は、生存確認用パケット送受信制御部221、情報格納部222、タイマー2S、タイマー5Sを有する。生存確認用パケット送受信制御部221は、生存確認のためにパケットの送受信を制御する機能部であり、タイマーを参照しながら後述するような処理動作を行う。情報格納部222は、状態良好、応答悪化を格納する。タイマー2Sは状態悪化判定タイマーであり、サーバ装置2が生存確認要求応答を送信してから、生存確認要求応答受領をクライアント装置1から受信するまでの期限を計測する。本実施の形態では、タイマー2Sが計測する時間として3秒程度の値を想定している。タイマー5Sは生存確認要求応答タイマーであり、サーバ装置2が生存確認要求単独のものを除くを受信してから生存確認要求応答を送信するまでの期限を計測する。本実施の形態では、タイマー5Sが計測する時間として1秒程度の値を想定している。なお、生存確認要求と生存確認要求応答受領はクライアント装置1からサーバ装置2に伝達される信号であり、生存確認要求応答は逆にサーバ装置2からクライアント装置1に伝達される信号である。本実施の形態に係るクライアント装置1及びサーバ装置2のそれぞれは、CPU、記憶装置等を有するコンピュータに上記の各機能を実現するためのプログラムを実行させることにより実現できる。当該プログラムは可搬メモリ等の記録媒体からコンピュータにインストールすることとしてもよいし、ネットワーク上のサーバからダウンロードすることとしてもよい。また、トンネル接続を実現する方式には種々のものあるが、本発明においてトンネル接続を実現する方式は特定の方式に限定されるわけではなく、本発明は様々なトンネル接続の方式に適用可能である。システムの動作以下では、第1の実施の形態におけるシステムの動作を説明する。以下の動作は、基本的に、クライアント装置1の生存確認機能部12と、サーバ装置2の生存確認機能部22により実行されるものである。図5は、システムの動作イメージを示す図である。図5に示すように、単独の生存確認用のメッセージパケット、もしくは、本来の通信データアプリケーションプログラムにより送受信されるデータであるデータパケットに付された形での生存確認用のメッセージがクライアント装置1とサーバ装置2間で送受信される。図6a~eは、本実施の形態で用いられるメッセージのフォーマット例を示す図である。なお、ここで示すフォーマットは一例に過ぎず、他の種々のフォーマット、サイズ、メッセージ種別を示す値を使用可能である。本実施の形態では、ヘッダは1バイトのサイズとなっている。図6aに示すように、23hが上りトンネルに流れた場合、単独の生存確認要求とみなし、下りトンネルに流れた場合、単独の生存確認要求応答とみなす。図6bに示すように、ヘッダ24hは単独の生存確認要求応答受領とみなす。図6c~eに示すように、データパケットを表すヘッダは30hとなっており、これに生存確認要求または生存確認要求応答を重畳させた場合のヘッダは31hとなる。また、生存確認要求応答受領を重畳させた場合のヘッダは32hとなる。このように、ヘッダの一部ビットを利用することにより、オーバーヘッド無しに生存確認が可能となる。次に、図7~図15のフローチャートを参照して、クライアント装置1、及びサーバ装置2の動作を説明する。図7は、クライアント装置1におけるトンネル接続時の処理、及び生存確認要求応答受信時の処理を示すフローチャートである。図7に示すように、クライアント装置1では、トンネル接続開始直後に、状態を良好に設定しステップ1、生存確認要求応答受領送信済みフラグを未送信にセットするステップ2。続いて、タイマー3C生存確認要求送信兼応答受領タイマー、タイマー4C生存確認要求最長送信タイマーをスタートさせ、タイマー1C再接続発動タイマー、タイマー2C状態悪化判定タイマーを停止させる。以降、クライアント装置1における生存確認機能部12は、パケット到着やタイマー動作タイムアウトのイベントを契機に動作する。図8は、データパケット送信時の処理、及びタイマー4C生存確認要求最長送信タイマーのタイムアウト時の処理を示すフローチャートである。図8に示すように、クライアント装置1がデータパケットを送信する際に、先ずタイマー3C生存確認要求送信兼応答受領タイマーがタイムアウトしているか否かを判定するステップ11。タイマー3Cがタイムアウトしている場合ステップ11のYes、生存確認要求を送付すべきと判断し、生存確認要求をデータパケットに重畳して送信しステップ12、タイマー3Cを停止するステップ13。一方、ステップ11の判定がNo、すなわちタイマー3C生存確認要求送信兼応答受領タイマーがタイムアウトしていなかった場合、必要に応じ、生存確認要求応答受領を送信すべきと判断し、生存確認要求応答受領送信済みフラグを検証しステップ14、未送信の場合ステップ14のNoに限り、生存確認要求応答受領をデータパケットに重畳して送信するステップ15し、生存確認要求応答受領送信済みフラグを送信済みにセットする。ステップ14の判定がYes、すなわち生存確認要求応答受領を送信済みであった場合、何も重畳せず、単独のデータパケットとして送信するステップ17。ステップ13、16、17の後、タイマー4Cを停止し、タイマー1C、2Cをスタートするステップ19。サーバ装置2から生存確認要求応答を受信した場合のクライアント装置1の処理を図7を参照して説明する。図7に示すとおり、サーバ装置2から生存確認要求応答を受信した場合、タイマー2C状態悪化判定タイマーがタイムアウトしているか否かをチェックしステップ4、タイマー2Cがタイムアウトしていない場合ステップ4のNoに限り、状態を良好に設定しステップ1、その後、クライアント装置1における状態をトンネル接続直後と同様に初期化するステップ2、3。タイマー2Cがタイムアウトしている場合ステップ4のYes、状態は状態悪化に設定されており、その設定のまま、クライアント装置1におけるフラグ等をトンネル接続直後と同様に初期化するステップ2、3。タイマー4C生存確認要求最長送信タイマーがタイムアウトした場合の処理を図8を参照して説明する。タイマー4Cがタイムアウトした場合、これはデータパケット送信がしばらく無かったことを意味するため、生存確認要求を単独パケットとして送信するステップ18。その後、タイマー4Cを停止し、タイマー1C再接続発動タイマー、タイマー2C状態悪化判定タイマーをスタートするステップ19。図9はタイマー3C生存確認要求送信兼応答受領タイマーがタイムアウトした場合のクライアント装置1における処理を示すフローチャートである。タイマー3C生存確認要求送信兼応答受領タイマーがタイムアウトした場合、生存確認要求応答受領の送信タイミングであるから、生存確認要求応答受領送信済みフラグをチェックして送信済みか否かをチェックしステップ21、送信済みでなければステップ21のNo、生存確認要求応答受領を単独パケットとして送信しステップ22、生存確認要求応答受領送信済みフラグを送信済みにセットするステップ23。図10はタイマー2C状態悪化判定タイマーがタイムアウトした場合のクライアント装置1における処理を示すフローチャートである。図10に示すように、タイマー2C状態悪化判定タイマーがタイムアウトした場合、状態が悪化したと判断され、状態を応答悪化に設定するステップ31。図11はタイマー1C再接続発動タイマーがタイムアウトした場合のクライアント装置1における処理を示すフローチャートである。図11に示すように、タイマー1C再接続発動タイマーがタイムアウトした場合、新規に1本トンネル接続を行いステップ51、トンネル接続時処理を行ってステップ52、旧トンネル接続を切断しステップ53、新トンネル接続に制御を渡す。図12はトンネル接続時等におけるサーバ装置2の処理を示すフローチャートである。図12に示すように、サーバ装置2では、トンネル接続時に状態を良好に設定しステップ61、以降、以下で説明するようにイベントベースで動作する。図13は、生存確認要求付きデータパケットをクライアント装置1から受信した場合におけるサーバ装置2の処理を示すフローチャートである。図13に示すように、生存確認要求付きデータパケットをクライアント装置1から受信した場合、タイマー5S生存確認要求応答タイマーをスタートするステップ71。図14は、生存確認要求を単独パケットとしてクライアント装置1から受信した場合等におけるサーバ装置2の処理を示すフローチャートである。図14に示すように、生存確認要求を単独で受信した場合、サーバ装置2は、生存確認要求応答を単独でクライアント装置1に送信しステップ81、タイマー2S状態悪化判定タイマーを再スタートし、タイマー5Sを停止するステップ84。また、図14に示すように、クライアント装置1へデータパケットを送信する時には、タイマー5S生存確認要求応答送信タイマーが動作中か否かを判断しステップ82、動作中ステップ82のYesであれば、生存確認要求応答付きのデータパケットをクライアント装置1に送信しステップ83、タイマー2S状態悪化判定タイマーを再スタートし、タイマー5Sを停止するステップ84。タイマー5S生存確認要求応答送信タイマーが動作中でない場合ステップ82のNo、通常のデータパケット送信を行うステップ85。図12に示すように、生存確認要求応答受領をクライアント装置1から受信した場合、タイマー2S状態悪化判定タイマーがタイムアウトしていない場合ステップ62のNoに限り、状態を良好に設定するステップ61。図14に示すように、タイマー5S生存確認要求応答送信タイマーがタイムアウトした場合、単独の生存確認要求応答をクライアント装置1に送信しステップ81、ステップ84を行う。また、図15に示すように、タイマー2S状態悪化判定タイマーがタイムアウトした場合、状態を応答悪化に設定するステップ91。次に、上述した各装置における処理手順に対応する状態の遷移について説明する。図16は、クライアント装置1における生存確認要求処理の状態遷移図である。図16に示すように、良好の状態からタイマー2C状態悪化判定タイマーの経過で応答悪化になるステップ101。タイマー1C再接続発動タイマー経過前でのパケット送信を契機にタイマー2Cがスタートし、タイマー2C経過前のパケット到着により良好の状態になるステップ102。応答悪化の状態からタイマー1C再接続発動タイマーが経過すると、接続不良※1となり、切断※2となるステップ103、104。そして、初期接続、もしくは再接続を経て良好の状態になるステップ105。ただし、本発明の実施の形態では、接続不良と判断された場合タイマー1Cが経過した場合、直ちに切断するため接続不良状態は実効上存在しない。また、本実施の形態の構成上、切断状態を扱う必要がないため、フローチャート上は切断状態を示していない。図17は、サーバ装置2における生存確認要求処理の状態遷移図である。図17に示すように、良好の状態からタイマー2S状態悪化判定タイマーの経過で応答悪化になるステップ201。タイマー2S再スタート後、タイマー2S経過前のパケット到着により良好の状態になるステップ202。また、良好もしくは応答悪化の状態から切断された場合に切断となり、その後、接続がなされるステップ203、204、205。なお、前述したとおり、本実施の形態の構成上、切断状態を扱う必要がないため、フローチャート上は切断状態を示していない。図18は、クライアント装置1とサーバ装置2を1セットのシステムとみなし、系全体の状態遷移を表した状態遷移図である。図18では、概ね、単独または重畳で受信する制御信号を状態として、タイマーのタイムアウトやパケット送信を状態遷移の条件という形で表記している。上記のフローチャートや状態遷移に従った処理動作を行うサーバ装置2とクライアント装置1間における生存確認動作シーケンスの一例を図19に示す。図19に示す例は、データパケットの通信がない場合の動作を示している。図19の場合、クライアント装置1においてデータパケットの送信がされないので、図7のステップ3でスタートしたタイマー4C生存確認要求最長送信タイマーは、データパケットの送信を契機として停止されることはなく、タイムアウトになり、図8のステップ18に示すとおり、単独での生存確認要求が送信される図19のステップ501。生存確認要求を受信したサーバ装置2において、図14のステップ81、84に示すとおり、単独の生存確認要求応答をクライアント装置1に送信し図19のステップ502、タイマー2S状態悪化判定タイマーを再スタートする。生存確認要求応答を受信したクライアント装置1は、図7に示す生存確認要求応答受信時の処理を行い、タイマー3C、4Cをスタートする。図19の例では、データパケットに付される生存確認要求応答を受信することはないので、タイマー3Cはタイムアウトし、図8に示すように、クライアント装置1は単独の生存確認要求応答受領をサーバ装置2に送信する図19のステップ503。生存確認要求応答受領を受信したサーバ装置1では、図12に示すように、タイマー2Sのタイムアウト確認を行うが、本例ではタイマー2Sはタイムアウトしておらず、状態は良好であると判断する。その後、クライアント装置1においてタイマー4C生存確認要求最長送信タイマーがタイムアウトし、生存確認要求を送信しステップ504、サーバ装置2から生存確認要求応答が送信されるステップ505。このようにデータパケットの送受信がない場合、タイマー4Cにより決定される最長間隔で生存確認が繰り返される。生存確認動作シーケンスの他の例を図20に示す。図20に示す例は、データパケットの送受信がある場合の動作を示している。本例において、データパケットがないときには、上述した処理と同様にして、生存確認要求、生存確認要求応答、生存確認要求応答受領の送受信がなされるステップ601~603。クライアント装置1において送信するデータパケットがある場合、図8に示すとおり、タイマー3C生存確認要求送信兼応答受領タイマーをチェックし、ここではタイムアウトしているので、生存確認要求付きデータパケットを送信するステップ604。一方、サーバ装置2からは順次データパケットが送信されるが、図20の例において、ステップ605に示すデータパケットは、タイマー5S生存確認要求応答タイマーが動作中でないため、通常のデータパケットとして送信される図14のステップ85。ステップ604の生存確認要求付きデータパケットを受信したサーバ装置2において、図13のステップ71に示すとおり、タイマー5S生存確認要求応答タイマーがスタートし、図14のステップ83に示すとおり、データパケット送信を契機として生存確認要求応答付きデータパケットが送信され図20のステップ606、タイマー5Sが停止し、タイマー2S状態悪化判定タイマーが再スタートされる。クライアント装置1からも順次データパケットが送信されるが、図20の例において、ステップ607、612に示すデータパケットについては、タイマー3Cが停止されているタイムアウトしていないとともに、生存確認要求応答受領を送信済みなので、生存確認要求なしのデータパケットとして送信される図8のステップ17。ステップ606の生存確認要求応答付きデータパケットを受信したクライアント装置1は、図7に示すとおり、タイマー3C、4Cをスタートさせるとともに、データパケット送信時に、生存確認要求応答受領付きデータパケットを送信する図20のステップ608、図8のステップ15。ステップ609、610で示すデータパケットについては、タイマー5Sが動作中でないので、そのままサーバ装置2からクライアント装置1に送信される。ステップ608の生存確認要求応答受領付きデータパケットを送信した後、クライアント装置1では、データパケット送信時に、生存確認要求付きデータパケットを送信する図20のステップ611、図8のステップ12。ステップ611の生存確認要求付きデータパケットを受信したサーバ装置2において、タイマー5S生存確認要求応答タイマーがスタートするが、ここではタイマー5Sがタイムアウトし、単独の生存確認要求応答が送信されるステップ613。それを受けたクライアント装置1からはタイマー3Cのタイムアウトを契機として単独の生存確認要求応答受領が送信されるステップ614。このようにデータパケットの送受信がある場合、タイマー2S状態悪化判定タイマーとクライアント装置1からの上りパケット送信間隔で決まる短い時間間隔での生存確認が繰り返される。これにより状態監視が頻繁になるため、より短期間に状態悪化を検出できる。本実施の形態において、クライアント装置1とサーバ装置2間のトンネルの本数は特に限定されないが、これまでの説明はトンネルが1本である場合を想定している。後述する第2の実施の形態にように、複数本のトンネルを使用する場合は、本実施の形態で説明する生存確認処理をトンネル毎に行う。また、本実施の形態に係る構成は、以下のように表すこともできる。サーバ装置2との間に構築されたトンネルを介してデータ通信を行うクライアント装置1は、前記サーバ装置2との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うクライアント側トンネル通信手段11と、前記トンネルを介して生存確認のためのパケット送受信を行うクライアント側生存確認手段12と、を備え、前記クライアント側生存確認手段12は、前記クライアント装置1が備えるアプリケーション部13からのデータパケット送信がない場合に、第1の時間タイマー4C間隔で生存確認要求を前記サーバ装置2に送信し、当該生存確認要求を受信した前記サーバ装置2から生存確認要求応答を受信した場合に、生存確認要求応答受領を前記サーバ装置2に送信し、前記アプリケーション部13からのデータパケット送信がある場合において、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置2から受信した後の第2の時間タイマー3C経過内に、生存確認要求応答受領付きデータパケットを前記サーバ装置2に送信し、生存確認要求応答又は生存確認要求応答付きデータパケットを前記サーバ装置から受信した後の当該第2の時間経過後に、生存確認要求付きデータパケットを前記サーバ装置2に送信し、前記生存確認要求応答又は前記生存確認要求応答付きデータパケットを前記サーバ装置から受信しないで第3の時間タイマー2Cが経過した場合に、前記トンネルの状態が悪化したと判定する。また、前記サーバ装置2は、前記サーバ装置2との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うサーバ側トンネル通信手段21と、前記トンネルを介して生存確認のためのパケット送受信を行うサーバ側生存確認手段22と、を備え、前記サーバ側生存確認手段22は、前記サーバ装置2からのデータパケット送信がない場合において、生存確認要求を前記クライアント装置1から受信した場合に、生存確認要求応答を前記クライアント装置1に送信し、前記サーバ装置2からのデータパケット送信がある場合において、生存確認要求付きデータパケットを前記クライアント装置1から受信した場合に、生存確認要求応答付きデータパケットを前記クライアント装置1に送信し、前記生存確認要求応答又は前記生存確認要求応答付きデータパケットを前記クライアント装置1に送信後、第4の時間タイマー2S経過内に生存確認要求応答受領又は生存確認要求応答受領付きデータパケットを前記クライアント装置1から受信しない場合に、前記トンネルの状態が悪化したと判定する。<第2の実施の形態>次に、本発明の第2の実施の形態について説明する。本実施の形態でのシステム構成は図2~4で説明した第1の実施の形態と同様である。ただし、本実施の形態では、クライアント装置1のトンネル機能部11、及びサーバ装置2のトンネル機能部21のそれぞれが、複数本のトンネル接続を束ねてパケット送受信を行う機能を備えている。また、生存確認機能部12、22は、複数本のトンネル接続を用いる構成に対応した機能を含む。図21は、パケット送信側とパケット受信側におけるトンネル機能部11、21の構成を示す図である。図21は、本実施の形態の機能を分かりやすく示すために、片方向の通信構成を示すものであるが、実際には、クライアント装置1とサーバ装置2の各々において、図21に示すパケット送信側の機能とパケット受信側の機能を備える。つまり、図21は、クライアント装置1からサーバ装置2への上り方向の通信構成、または、サーバ装置2からクライアント装置1への下り方向の通信構成を示している。図21に示すように、パケット送信側のトンネル機能部は、分配部101、カウンター102、トンネル接続リスト格納部103を含む。パケット受信側のトンネル機能部は、集約受信部201、最終送信番号格納部202、タイマー203を含む。もちろん、各トンネル機能部は、複数本のトンネル接続を行う機能も含む。パケット送信側では、トンネル接続リスト格納部103に接続中のトンネルのリストであるトンネル接続リストが格納される。図21の例では、トンネル接続0~Nが示されている。分配部101は、トンネル接続リスト及びカウンターを利用して、送信対象のパケットに対して順次番号を付与し、複数のトンネルに対して順次パケットを送信する。送信に用いるトンネルを複数リストとして順に用いて送信する構成となっている。また、各トンネルの状態が悪化した場合、リストから取り除き、良好に復帰した場合、再度リストに加える。パケット受信側では、最後に再送信したパケットの番号が、最終送信番号格納部202に格納される。集約受信部201はパケットを格納するキューバッファメモリを備え、以下の処理を行う。なお、以下のような制御を行う集約受信部201は、再送信順序制御手段の一例である。集約受信部201は、最終送信パケット番号と受信したパケットのパケット番号とを比較し、受信したパケットのパケット番号が最終送信パケット番号1以下であれば直ちに送信し、2以上であれば、集約受信部201におけるキューの中を確認し、既に待ち合わせのパケットがあればキューの中のパケットに引き続き受信したパケットを再送信する。キューにパケットが無ければ、受信したパケットをキューに格納してタイマー203を始動する。タイマー203がタイムアウトするまで次のパケットがこなかった場合は、キューに格納されたパケットを送信する。以下では、上記の処理をより詳細にフローチャートを参照して説明する。図22は、パケット送信側トンネル機能部における初期化処理を示すフローチャートである。図22に示すように、カウンター値を0にしステップ111、トンネル接続リストを空にしステップ112、トンネル接続をN本オープンするステップ113。図23は、パケット送信側トンネル機能部における分配部101が行う分配送信処理を示すフローチャートである。図23に示すように、パケットにカウンター値を付加しステップ121、トンネル接続リストの先頭にあるトンネルにパケットを送信するステップ122。そして、カウンター値に1を加算しステップ123、トンネル接続リストの先頭の要素をリストの末尾に移動するステップ124。図24は、パケット送信側トンネル機能部における、トンネル状態良好化時、もしくはトンネル接続時の処理を示すフローチャートである。ここで、トンネル状態良好化時とは、生存確認部12、22において、トンネル接続が応答悪化の状態から、良好の状態になったことが検知された時のことである。ここでは、トンネル接続の末尾に、接続した又は良好になったトンネルを追加するステップ131。図25は、パケット送信側トンネル機能部における、トンネル状態応答悪化時、もしくはトンネル切断時の処理を示すフローチャートである。ここで、トンネル状態応答悪化時とは、生存確認部12、22において、トンネル接続が良好の状態から、応答悪化の状態になったことが検知された時のことである。ここでは、トンネル接続リストから該当するトンネルを削除するステップ141。図26は、パケット受信側トンネル機能部における初期化処理を示すフローチャートである。初期化時において、最終送信番号を-1にするステップ151。図27は、パケット受信側トンネル機能部における集約受信部201が実行する集約受信処理を示すフローチャートである。パケットを受信すると、受信したパケットのパケット番号が最終送信番号1以下かどうかをチェックするステップ161。最終送信番号1以下である場合ステップ161のYes、受信したパケットを再送信し、最終送信番号を当該パケットの番号とするステップ162。ステップ161において、受信したパケットのパケット番号が最終送信番号1以下でない場合2以上の場合、キューの中に既に待ち合わせ中のパケットが存在するか否かを確認するステップ163。待ち合わせ中のパケットが存在する場合ステップ163のYes、キューの中のパケットを全て送信し、タイマーを停止し、最終送信番号を更新するステップ164。その後、受信したパケットを再送信し、最終送信番号を当該パケットの番号とするステップ162。ステップ163において待ち合わせ中のパケットが存在しない場合、パケットをキューに投入しステップ165、タイマーをスタートするステップ166。図28は、パケット受信側トンネル機能部におけるタイマータイムアウト処理を示すフローチャートである。図28に示すとおり、タイマーがタイムアウトになると、キューの中のパケットを、パケットを受信した順番で全て送信し、タイマーを停止し、最終送信番号を更新するステップ171。本実施の形態では、送信に用いるトンネル接続について、接続状態であると同時に、トンネル状態が良好であることも条件としている。つまり、状態が悪化したと判定されたトンネル接続を使用しないこととしている。これにより、パケット再送等により一時的に応答の悪化したトンネル接続を回避して良好な応答を保つことができる。上記のように動作するトンネル機能部を備えるサーバ装置2送信側からクライアント装置1受信側への通信処理例を図29、図30を参照して説明する。図29は、サーバ装置2からクライアント装置1への伝送路におけるジッターが小さい場合の処理例を示す。図29に示すように、パケット0~15がサーバ装置2から各トンネル接続経由で順番に送信される。本例では、パケット4がパケット5よりも少し遅れてクライアント装置1に到達する。この場合、受信側の処理を示す図27に示すように、クライアント装置1では、パケット3の次に受信するパケット5をキューに格納し、タイマータイムアウト前にパケット4を受信することにより、パケット4をアプリケーションプログラムアプリケーション部13に送信し、次に、キューの中のパケット5をアプリケーションプログラムに送信する。パケット8、9についても同様である。このように、ジッターが小さい場合、順序が入れ替わって到着したパケットも順序通り並べ替えて送信することができる。図30は、サーバ装置2からクライアント装置1への伝送路におけるジッターが大きい場合の処理例を示す。本例では、パケット6が大きく遅れてクライアント装置1に到達する。この場合、クライアント装置1において、パケット5の次に受信したパケット7はキューに格納されるが、続くパケットを受信する前にタイマーがタイムアウトになり、キューの中のパケット7が送信される。従って、パケット7については少し遅延する。パケット6はパケット9の次に受信され、パケット11がその次に受信される。この場合、パケット9の次に受信したパケット6についての図27のステップ161の判定はYesになるので、パケット6はすぐにアプリケーションプログラムに送信される。次に受信するパケット11については、キューに格納されるステップ161のNo、ステップ163、165。タイマータイムアウト前にパケット10を受信することにより、パケット10をアプリケーションプログラムに送信し、次に、キューの中のパケット11をアプリケーションプログラムに送信する。ジッターが大きい場合、大きい遅延を受けたパケットについての順序入れ替わりは防止できないものの他のパケットまでが大きく遅延することなく処理される。ここで、従来技術による複数トンネリング通信での受信処理の一例ジッター小の場合を図31に示す。図31に示すように、ジッターが小であっても、従来技術では順序逆転が発生してしまうが、本実施の形態に係る技術では順序逆転を防止できる。これにより、リアルタイムコミュニケーション系などパケットの順序性が問題になるアプリケーションでも、順序逆転を防止することにより、品質低下を抑制できる。<実施の形態の効果>第1、第2の実施の形態で説明した技術によれば、データパケットが送受信されているときに、データパケットに重畳して生存確認用の信号を送受信する構成をとるので、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たした生存確認を行うことができるとともに、サーバ装置側でも通信状態の安定性判定をすることでより短い時間で状態判定が行うことができ、クライアント装置1からサーバ装置2への上り方向の状態判定と同様にサーバ装置2からクライアント装置1への下り方向の状態判定も可能となる。そのため、トンネルのコネクションが切断されてしまった等の異常事態をいち早く検出し、他の正常なトンネル接続に振り分けることでトンネル経由の通信への影響時間を短縮することができる。また、一定時間内のパケット順序入れ替り補正により、ほとんどのパケット順序を保ったままで、かつ遅延時間を小さく伝送できるため、VoIPや映像コミュニケーションなどリアルタイム通信でかつパケット順序が通信品質に影響を与える通信プロトコルに対しても安定的に利用可能となる。本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更応用が可能である。