"無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上でパッシブに監視して通信品質を測定する通信品質測定装置において、サーバから無線クライアントへ送信され、ネットワーク上のキャプチャポイントに到着した下りのTCPパケットをキャプチャするキャプチャ手段と、前記キャプチャされたパケットのログ情報をコネクションおよび/またはセッションごとに管理するログ情報管理手段と、前記ログ情報に基づいて、前記キャプチャポイントから見た各エンド側の固定的な遅延時間を算出するエンド側固定遅延算出手段と、スループット計測用の所要時間内に通信されたデータ量に基づいて無線クライアント側のスループットを算出する通信品質算出手段とを具備し、前記通信品質算出手段は、無線区間の影響を受けて変化する代替所要時間を下りのTCPパケットの到着時刻差で計測し、当該代替所要時間を前記エンド側の固定遅延時間で補正することで前記所要時間を算出することを特徴とする通信品質測定装置。前記エンド側固定遅延算出手段は、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて、前記各エンド側の固定遅延時間を算出することを特徴とする請求項1に記載の通信品質測定装置。前記ログ情報を参照し、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数が、1回および2回以上のいずれであるかを判定する一括送信回数判定手段をさらに具備し、前記通信品質算出手段は、前記一括送信回数に基づいて、到着時刻を前記代替所要時間の算出に用いる下りパケットを選択することを特徴とする請求項1または2に記載の通信品質測定装置。前記一括送信回数判定手段は、前記通信開始時のウィンドウサイズを検知するウィンドウサイズ検知手段を具備し、前記一括送信回数を、通信のデータ量が前記通信開始時のウィンドウサイズ以下であれば1回と判定し、前記ウィンドウサイズよりも大きければ2回以上と判定することを特徴とする請求項3に記載の通信品質測定装置。前記一括送信回数が2回以上と判定されたときに、前記エンド側固定遅延算出手段は、無線エンド側の固定遅延時間を算出し、前記品質算出手段は、サーバから無線クライアントへウィンドウサイズ単位で一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを前記代替所要時間として算出し、前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、前記総データ量を、前記代替所要時間に無線エンド側固定遅延時間を加算して得られる所要時間で除してスループットを算出することを特徴とする請求項3または4に記載の通信品質測定装置。前記一括送信回数が2回以上と判定されたときに、前記エンド側固定遅延算出手段は、無線エンド側の固定遅延時間を算出し、前記品質算出手段は、サーバから無線クライアントへウィンドウサイズ単位で一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを前記代替所要時間として算出し、前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、前記総データ量を、前記代替所要時間に無線エンド側固定遅延時間の片道分を加算して得られる所要時間で除してスループットを算出することを特徴とする請求項3または4に記載の通信品質測定装置。前記一括送信回数が2回以上と判定されたときに、前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の固定遅延時間を算出し、前記品質算出手段は、サーバから無線クライアントへウィンドウサイズ単位で一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを前記代替所要時間として算出し、前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、前記総データ量を、前記代替所要時間に無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の片道分を加算して得られる所要時間で除してスループットを算出することを特徴とする請求項3または4に記載の通信品質測定装置。前記一括送信回数が1回と判定されたときに、前記エンド側固定遅延算出手段は、サーバエンド側の固定遅延時間を算出し、前記品質算出手段は、サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、前記セッションの確立時から終了時までに通信された総データ量を算出し、前記総データ量を、前記代替所要時間から前記サーバエンド側固定遅延時間を減算して得られる所要時間で除してスループットを算出することを特徴とする請求項3または4に記載の通信品質測定装置。前記一括送信回数が1回と判定されたときに、前記エンド側固定遅延算出手段は、サーバエンド側の固定遅延時間を算出し、前記品質算出手段は、サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、前記セッションの確立時から終了時までに通信された総データ量を算出し、前記総データ量を、前記代替所要時間から前記サーバエンド側固定遅延時間および無線エンド側固定遅延時間の片道分の和を減算して得られる所要時間で除してスループットを算出することを特徴とする請求項3または4に記載の通信品質測定装置。前記一括送信回数が1回と判定されたときに、前記エンド側固定遅延算出手段は、サーバエンド側の固定遅延時間を算出し、前記品質算出手段は、サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、前記セッションの確立時から終了時までに通信された総データ量を算出し、前記総データ量を、前記代替所要時間から前記サーバエンド側固定遅延時間の片道分を減算して得られる所要時間で除してスループットを算出することを特徴とする請求項3または4に記載の通信品質測定装置。スループットの測定対象がHTTPセッションであり、前記セッションの終了時に送信されるパケットとしてFINパケットを監視することを特徴とする請求項8-11のいずれかに記載の通信品質測定装置。スループットの測定対象がHTTPセッションであり、前記セッションの終了時に送信されるパケットとして、次のセッションでサーバから無線クライアントへ最初に送信される下りパケットを監視することを特徴とする請求項8-11のいずれかに記載の通信品質測定装置。前記キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を具備したことを特徴とする請求項1ないし12のいずれかに記載の通信品質測定装置。測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項1に記載の通信品質測定装置。前記一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、当該取得した情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項3ないし12のいずれかに記載の通信品質測定装置。前記一括送信回数判定手段は、無線クライアントの種別を識別し、当該種別から識別されるTCPウィンドウサイズの初期値、最大値および増え方を規定する情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項3ないし12のいずれかに記載の通信品質測定装置。前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、通信開始時のウィンドウサイズ、最大値および増え方に基づいて識別することを特徴とする請求項1ないし4のいずれかに記載の通信品質測定装置。前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、各パケットの到着時刻の差に基づいて識別することを特徴とする請求項1ないし4のいずれかに記載の通信品質測定装置。無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、サーバから無線クライアントへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた下りのTCPパケットのログ情報をコネクションごとに管理し、前記ログ情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定し、前記一括送信回数が2回以上であると、無線エンド側の固定的な遅延時間を算出し、サーバから無線クライアントへ一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを代替所要時間として算出し、前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、前記総データ量を、前記代替所要時間に少なくとも無線エンド側固定遅延時間の片道分を加算して得られる所要時間で除してスループットを算出することを特徴とする通信品質測定方法。無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、サーバから無線クライアントへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた下りのTCPパケットの種別および到着時刻をログ情報としてコネクションごとに管理し、前記ログ情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定し、前記一括送信回数が1回であると、サーバエンド側の固定的な遅延時間を算出し、サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを代替所要時間として算出し、前記セッションの確立時から終了時までに通信された総データ量を算出し、前記総データ量を、前記代替所要時間から少なくともサーバエンド側固定遅延時間の片道分を減算して得られる所要時間で除してスループットを算出することを特徴とする通信品質測定方法。前記スループット計測がHTTPセッション単位で行われ、セッション間のthinktimeがスループットの計測対象期間から除外されることを特徴とする請求項19または20に記載の通信品質測定方法。前記スループット計測がメールセッション単位で行われ、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項19または20に記載の通信品質測定方法。相互に通信するノードペアの一方が無線端末である場合、その無線区間の通信品質としてスループットを測定するのであれば、経路上のキャプチャポイントにおいて、データ通信の開始を要求する要求パケットの到着時刻tstartと、データ通信の完了を通知する完了パケットの到着時刻tendと、その間に送受された総データ量dとを測定し、総データ量dをデータ通信の所要期間TotalTimeで除せば良い。なお、無線区間を含むネットワークでのデータ通信の場合、一般的に無線区間がボトルネックとなることから、無線区間側のスループットを算出することにより、ユーザあるいは端末が享受体感しているスループットを算出することができる。しかしながら、このようなパッシブ測定ではキャプチャポイントを通過するパケット量が膨大であるため、双方向の全てのパケットを漏れなくキャプチャし、かつ全ての要求パケットと応答パケットとを対応付けることは、処理規模が膨大となり、リアルタイムまたは準リアルタイムに計算するのが困難であった。さらに、送信パケットに対する応答として返信されるACKパケットは、TCPの性質上、一つのデータパケットの受信毎に返信されるとは限らない。このため、パケット転送の終了タイミングをACKパケットの到着時刻で代表させてしまうと、所要期間が大きな誤差を含むことになり、スループットを正確に測定できなくなる。本発明の目的は、上記した従来技術の課題を全て解決し、監視対象の通信トラヒックが集約される経路上でパケットをパッシブに測定し、パケットの種別や到着時刻に基づいて無線クライアント側の通信品質を正確に分析できる通信品質測定方法および装置を提供することにある。上記の目的を達成するために、本発明は、無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上でパッシブに監視して通信品質を測定する通信品質測定方法および装置において、以下のような手段を講じた点に特徴がある。サーバから無線クライアントへ送信され、ネットワーク上のキャプチャポイントに到着した下りのTCPパケットをキャプチャするキャプチャ手段と、キャプチャされたパケットのログ情報をコネクションおよび/またはセッションごとに管理するログ情報管理手段と、ログ情報に基づいて各エンド側の固定的な遅延時間を算出するエンド側固定遅延算出手段と、スループット計測用の所定時間内に通信されたデータ量に基づいて無線クライアント側のスループットを算出する通信品質算出手段とを具備し、通信品質算出手段は、無線区間の影響を受けて変化する代替所要時間を下りのTCPパケットの到着時刻差で計測し、当該代替所要時間をエンド側の固定遅延時間で補正することで所定時間を算出するようにした。エンド側固定遅延算出手段は、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて、前記各エンド側の固定遅延時間を算出する。通信開始時のウィンドウサイズを検知し、各セッションにおいてデータがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数が1回および2回以上のいずれであるかを、各セッションで通信される総データ量を通信開始時のウィンドウサイズと比較することで判定し、この判定結果に応じてスループットの測定アルゴリズムを異ならせるようにした。一括送信回数が2回以上と判定されると、無線エンド側の固定遅延時間を算出し、サーバから無線クライアントへウィンドウサイズ単位で一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを前記代替所要時間として算出し、最初のパケット群から最後の直前のパケット群までの総データ量を算出し、総データ量を、代替所要時間に少なくとも無線エンド側固定遅延時間の片道分を加算して得られる所要時間で除してスループットを算出するようにした。一括送信回数が1回と判定されると、サーバエンド側の固定遅延時間を算出し、サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、セッションの確立時から終了時までに通信された総データ量を算出し、総データ量を、代替所要時間から少なくともサーバエンド側固定遅延時間の片道分を減算して得られる所要時間で除してスループットを算出するようにした。このとき、スループットの測定対象が、HTTPセッションのデータ通信終了後にTCPコネクションも終了するセッションであれば、セッションの終了時に送信されるパケットとしてFINパケットを監視し、HTTPセッションのデータ通信終了後も継続して異なるHTTP通信が行われるHTTPセッションであれば、セッションの終了時に送信されるパケットとして、次のセッションでサーバから無線クライアントへ最初に送信される下りパケットを監視するようにした。キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を具備した。測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間からオーバヘッド時間を減じて当該セッションの所要時間とするようにした。一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、あるいは無線クライアントの種別に基づいてTCPウィンドウサイズの初期値、最大値および増え方を識別し、通信開始時のウィンドウサイズを判別するようにした。スループット計測がHTTPセッション単位で行われ、セッション間のthinktimeがスループットの計測対象期間から除外されるようにした。本発明によれば、以下のような効果が達成される。TCPコネクションのスループットを、ネットワーク上に設けたキャプチャポイントにおいて一方向のパケットサーバから無線クライアントへ送信される下りパケットのみをパッシブに監視するだけで計測できるようになる。したがって、一コネクション当たりの監視パケット数を少なくでき、その結果、多数のコネクションを同時に監視できるようになるので、スケーラブルなスループット測定が可能になる。無線側およびサーバ側の各エンド側固定遅延時間が、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて求められるので、エンド側の固定遅延時間を計測する為の機能を別途に用意する必要がない。データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定し、一括送信回数が1回の場合と2回以上の場合とで、スループットの測定アルゴリズムを異ならせるので、通信の総データ量にかかわらず常に正確なスループット計測が可能になる。また、一括送信回数が1回であるか2回以上であるかを、通信開始時のウィンドウサイズをデータサイズと比較するだけで判定できるようになる。キャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を設けたので、通信の総データ量を、より正確に算出できるようになる。メールセッションでは、セッションサイズの小さいメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズの大きいメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じてメールセッションの所要時間とするので、メールセッションについても正確なスループット計測が可能になる。HTTPセッションでは、スループット計測がセッション単位で行われるので、例えばHTTPWEBにおいて、今回のセッションと次回のセッションとの間に無線クライアント側でユーザのThinkTimeが生じても、このThinkTimeが除外された正確なスループット計測が可能になる。TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得することにより、クライアント端末やTCPの違いにかかわらず通信開始時のウィンドウサイズを正確に判別できるようになる。その結果、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を正確に判定できるようになる。以下、図面を参照して本発明の実施形態について詳細に説明する。ここでは初めに、本発明の概要について説明し、次いで、その具体的な実施形態について説明する。なお、以下の説明では基本的に、トランスポート層第4層での接続をコネクションと表現し、これよりも上位層での接続をセッションと表現することで両者を区別しているが、両者をコネクションで代表する場合もある。本発明は、無線区間を含むTCPコネクションのスループットをコネクション単位HTTPおよびメールでは、セッション単位で測定するものとし、ネットワーク上のキャプチャポイントで監視するキャプチャ対象のパケットを、TCPコネクションの確立時に送受される制御パケット、ならびにTCPコネクション確立後は当該コネクションまたはそのセッション内で観測される下り方向のパケットのみに限定することで、一コネクション当たりのキャプチャ対象のパケット数を減じ、多数のコネククションを監視対象とできるようにすることで、パッシブ測定に必須のスケーラビリティを担保しながら、精度の高いスループット測定を可能にしている。ただし、このようにして計測される期間下りパケットの到着時刻差は、スループット計測のための前記所要時間TotalTimeとは異なり、また当該期間内で通信されるデータ量も、スループット計測のための前記総データ量dとは異なる。そこで、本発明ではスループット計測に用いる所要時間TotalTimeおよび総データ量dを、前記期間に応じて補正、見直すことで、所要時間TotalTimeを直接求めることなくスループットを正確に計測できるようにしている。さらに、本発明ではデータがサーバから無線クライアントへウィンドウサイズ単位で一括送信バルク送信される回数を判定し、この一括送信回数が1回であるのか、あるいは2回以上であるのかに応じて測定アルゴリズムを異ならせることで、各セッションにおけるデータ量の多少に関わらずスループットを高精度で測定できるようにしている。A.セッションが2回以上の一括送信を要する場合、あるいは総データ量が初期ウィンドウサイズを越える場合/無線クライアント端末MH側無線区間で観測されるスループットは、図8に示したように、3ウェイハンドシェイクによるTCPコネクションの確立後、一般的には、MHが最初にリクエストを送信した時刻、または、最初のHTTPRESパケットを受信した時刻tsから、最後のリクエストに対してサーバから返信された応答がMHで受信された時刻teまでを所要時間Tairとし、この間にダウンロードされたデータ量M1,M2...の総和を前記所要時間Tairで除すことで求まる。しかしながら、本発明ではキャプチャポイントをMHではなくネットワーク上に設定し、かつ監視対象のパケットを、TCPコネクション確立後の当該コネクション内では下り方向のパケットのみに限定し、キャプチャ対象のパケット数を減ずることでスケーラビリティを確保する。したがって、ここではサーバからMHへダウンロードされるパケットのキャプチャポイントへの到着時刻のみを所要時間の算出基準とすることを考える。ネットワーク上にキャプチャポイントを設けた場合、第1回目の送信パケットの到着時刻t1から最後ここでは、第2回目の送信パケットに対するACKの到着時刻t3までをスループット計測の所要時間TotalTimeとできる。しかしながら、本発明では上りパケットは監視対象外なので、下りパケットの到着時刻のみで計測でき、かつ無線区間の影響を受けて変化する代替所要時間として、第1回目の送信パケットの到着時刻t1から最後ここでは、第2回目の送信パケットの到着時刻t2までの期間Tに着目する。ただし、この代替所要時間Tは、本来の所要時間TotalTimeよりも、最後第2回目の送信パケットの到着時刻t2から、そのACKの到着時刻t3までの期間だけ短くなってしまう。一方、前記代替所要時間Tと本体の所要時間TotalTimeとの差分t3t2は、無線エンド側に固有の固定的な遅延時間と、2ndHTTPRESのデータ量M2に依存する通信時間との和に相当する。そこで、本発明では最初の送信パケットの到着時刻t1から最後の送信パケットの到着時刻t2までの代替所要時間Tを、前記キャプチャされたパケットの通信ログに基づいて算出する一方、この代替所要時間Tと本来の所要時間TotalTimeとの差分不足分を、TCPコネクションの確立時に送受される制御パケットの到着時刻差に基づいて求まる無線エンド側固定遅延時間RTTairなどから算出し、この算出値で前記代替所要時間Tを補正することで前記本来の所要時間TotalTimeを算出することを考える。なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをMHがサーバから通信データを受けきるまでとするならば、最後のACKがMHからチャプチャポイントに到着するまでの時間が不要となる。したがって、前記代替所要時間Tに、片道分の無線エンド側固定遅延時間RTTair2および2ndHTTPRESのデータ量に依存した遅延時間を加算することで前記所要時間TotalTimeを算出するようにしても良い。さらに、所要時間TotalTimeをサーバがMHからACKを受信するまでとするならば、最後のACKがキャプチャポイントからサーバへ到着するまでの時間が更に不足する。したがって、前記代替所要時間Tに、無線エンド側固定遅延時間RTTair、2ndHTTPRESのデータ量に依存した遅延時間、および片道分のサーバエンド側固定遅延時間RTTsrv2を加算することで前記所要時間TotalTimeを算出するようにしても良い。B.セッションが1回の一括送信のみで完了する場合、あるいは総データ量が初期ウィンドウサイズ以下の場合/ネットワーク上にキャプチャポイントを設けた場合、図9に示したように、3ウェイハンドシェイクによるTCPコネクションの確立後、第1回目の送信パケットの到着時刻t1から、これに対してMHが返信する応答パケットの到着時刻t2までを、MH側無線区間のスループット計測の所要時間TotalTimeとできる。しかしながら、本発明では上りパケットは監視対象外なので、下りパケットの到着時刻のみで計測でき、かつ無線区間の影響を受けて変化する代替所要時間Tとして、第1回目の送信パケットの到着時刻t1から、当該セッションの終了を示唆する下りパケットここでは、FINパケットの到着時刻t3までの期間に着目する。ただし、この代替所要時間Tは、前記ACKの到着時刻t2からFINの到着時刻t3までの所要時間だけ、本来の所要時間TotalTimeよりも長くなってしまう。一方、前記FIN到着時刻t3とACK到着時刻t2との差分T3t2は、その間に送受されるパケットサイズが小さいことから、TCPコネクション確立時の3ウェイハンドシェイクにおけるサーバエンド側固定遅延時間RTTsrvにほぼ等しい。そこで、本発明では送信パケットの到着時刻t1からFINパケットの到着時刻t3までの代替所要時間Tを通信ログに基づいて算出する一方、この代替所要時間Tと本来の所要時間TotalTimeとの差分T3t2を、TCPコネクションの確立時に送受される制御パケットの到着時刻に基づいて求まるサーバエンド側固定遅延時間RTTsrvで補正することにより、前記所要時間TotalTimeを算出する。なお、セッション終了を示唆する下りパケットとしてFINを利用できるのは、最後のデータ通信の終了直後例えば0.1秒以内にFINがキャプチャされている場合に限られる。また、HTTPセッションの終了後もTCPコネクションが維持されて次のセッションが確立される場合には、当該次のセッションの開始時に送信される下りパケット例えば、MHからのHTTPREQに対してサーバが送信されるHTTPRESを、前記セッション終了を示唆する下りパケットとして利用できる。ただし、この場合も先のセッションの通信終了直後に次のセッションの下りパケットがキャプチャされている場合に限られる。なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをMHがサーバから通信データを受けきるまでとするならば、上記と同様に、代替所要時間Tから、サーバエンド側固定遅延時間RTTSRVおよび最後のACKがMHからキャプチャポイントに到着するまでの片道分の無線エンド側遅延時間を減じれば良い。さらに、スループット計測の所要時間TotalTimeをサーバがMHからACKを受信するまでとするならば、代替所要時間Tから、最後のACKがキャプチャポイントからサーバへ到着するまでの片道分のサーバエンド側固定遅延時間のみを減じれば良い。次いで、本発明の実施形態について具体的に説明する。図1は、本発明の通信品質測定方法が適用されるネットワークの構成を示したブロック図である。サービス提供範囲の各エリアには無線基地局BSが設置され、当該エリア内のクライアント本実施形態では、無線移動端末MHは前記各無線基地局BSに収容される。各無線基地局BSは無線アクセス網RANに接続され、前記無線アクセス網RANはコア網のゲートウェイに接続される。前記コア網はインターネットエクスチェンジにおいてインターネットと接続される。前記インターネットには、MHからの要求に応答してサービスを提供する各種のサーバが接続されている。本実施形態では、各MHと各サーバとの間のトラヒックを集約できる回線として、無線アクセス網RANとコア網とを接続する回線Lに、通信品質測定装置としてのキャプチャ装置1が接続されている。図2は、前記キャプチャ装置1の第1実施形態の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。パケットキャプチャ部101は、前記回線L上でTCPパケットを選択的にキャプチャする。本実施形態では、キャプチャ対象のパケットが、MHとサーバとの間にTCPコネクションを確立するための3ウェイハンドシェイクで送受される制御パケット、およびTCPコネクションの確立後は、監視対象のセッション内で送受される下りパケットのみに限定される。ログ情報管理部102には、前記キャプチャされたパケットの、少なくとも種別および到着時刻がログ情報としてコネクション毎に記録、管理される。エンド側固定遅延算出部103は、前記ログ情報を参照し、TCPコネクションの確立時に送受される制御パケットの到着時刻差に基づいて、データ量に依存しない固定的な各エンド側無線側およびサーバ側の遅延時間を算出する。一括送信回数判定部104は、監視対象のコネクションセッションについて、前記ログ情報を参照することで、そのデータ通信開始時における初期ウィンドウサイズを検知するWS検知部104aを具備し、サーバからMHへ送信された総データ量をデータ通信開始時におけるサーバ側の初期ウィンドウサイズと比較することで、監視対象のセッションが、その完了までにデータをウィンドウサイズ単位で一括送信する回数が1回または2回以上のいずれであるのかを判定する。通信品質算出部105は、前記一括送信回数が1回のセッション以下、1RTTセッションと表現する場合もあるを対象に通信品質を測定する第1測定部105a、および一括送信回数が2回以上のセッション以下、2RTT以上セッションと表現する場合もあるを対象に通信品質を測定する第2測定部105bを備え、前記一括送信回数判定部104による判定結果に応じて、無線区間の影響を受けて変化する所定時間と当該所定時間内に通信されたデータ量とに基づいて無線区間の通信品質を算出する。前記第1および第2測定部105a,105bはいずれも、下りのTCPパケットの到着時刻差のみで計測でき、かつ無線区間の影響を受けて変化する代替所要時間Tを前記エンド側の固定遅延時間で補正することで、スループットの計測期間となる所定時間を算出し、この所定時間と当該所定時間内に通信されたデータ量とに基づいて無線クライアント側のスループットを算出する。図3は、前記エンド側固定遅延算出部103、一括送信回数判定部104および通信品質算出部105が協働し、前記ログ情報を参照して通信品質を算出する手順を示したフローチャートであり、例えば監視対象のコネクションが完了することに実行される。ステップS1では、今回の測定対象コネクションのログ情報が識別される。ステップS2では、前記一括送信回数判定部104において、当該測定対象が1RTTセッションおよび2RTT以上セッションのいずれであるかが判定される。1RTTセッションと判定されればステップS3へ進み、前記第1測定部105aによりスループットが算出される。これに対して、2RTT以上セッションと判定されればステップS4へ進み、前記第2測定部105bによりスループットが算出される。図4は、2RTT以上セッションのシーケンスフローであり、時刻t1~t3では、3ウェイハンドシェイクによりMHとサーバとの間にTCPコネクションが確立される。すなわち、時刻t1では、MHからサーバへSYNパケットが送信される。時刻t2では、前記SYNパケットを受信したサーバからMHへSYNACKが返信される。時刻t3では、前記SYNACKパケットを受信したMHからサーバへACKパケットが返信される。TCPコネクションが確立されると、時刻t4では、MHからサーバへHTTPREQパケットが送信されてHTTPセッションが開始される。時刻t5では、前記HTTPREQパケットの受信に応答して、サーバからMHへHTTPRESパケットデータパケットが送信される。時刻t6では、前記HTTPRESパケットの受信に応答して、MHからサーバへACKが返信される。このACKには、MH側で受信可能な最大受信ウィンドウサイズが記述されている。時刻t7,t8では、前記ACKパケットに応答してサーバからMHへ次のHTTPRESパケットが送信される。このとき、サーバはMHから通知された最大受信ウィンドウサイズとサーバ自身が管理する送信ウィンドウサイズとに基づいて今回のウィンドウサイズWSを決定する。ここでは、ウィンドウサイズWSが2に決定され、2つのHTTPRESパケットが一括送信されるものとして説明を続ける。時刻t9,t10では、前記2つのHTTPRESパケットの受信に応答してMHからサーバへACKパケットが返信される。このようなシーケンスにおいて、本実施形態では3ウェイハンドシェイクで送受されるSYNACKパケットの到着時刻taおよびそのACKの到着時刻tb、ならびにHTTPセッション内での各HTTPRESの到着時刻が参照される。ここで、MH側の無線区間のスループットRateは、測定期間中に通信される測定対象コネクションHTTPセッションの総データ量をTotalSize、通信の所要時間をTotalTimeとすれば次式で表される。Ratebps=TotalSizebit/TotalTimesec...前記総データ量TotalSizeは、ACKを待たずに送信された最後の送信パケットまたはパケット群のデータ量をSz、このSzを除く送信済みかつ確認応答ACK済みパケット群のデータ量をSumSentSzとすれば、次式で表される。TotalSize=SumSentSzSz...なお、SumSentSzACK済みのデータ量の合計値は、一般的にはACKを直接監視し、ACKされたデータのシーケンス番号を確認することで把握できるが、本実施形態ではACKが監視対象外なので、その代わりに以下のような手法で把握する。第1の手法として、サーバが送信する際のウィンドウサイズの遷移から推定する方法がある。第2の方法として、サーバが送信するデータパケットの連続送信状態から推定する方法がある。第3の方法として、対象セッションで送信された全データ量から、前記ACKを待たずに送信された最後の送信パケットまたはパケット群のデータ量Szを減算する方法がある。第1の手法では、ウィンドウサイズがTCPセッションの確立直後から通信毎に、例えば1,2,4,8...64と離散的かつ規則的に増加する点に着目し、各パケットの到着時刻およびデータサイズに基づいて、一括送信されるパケットの区切りが推定される。このとき、TCPセッションの確立時刻とHTTPセッションの開始時刻との差が所定の閾値例えば、1sec以内であり、HTTPセッションがTCPコネクションの確立直後に構築されているのであれば、当該HTTPセッションが最初のセッションであってウィンドウサイズ=1から開始されたと推定できるので、一括送信されるパケットの区切りを容易に推定できる。また、HTTPセッションがTCPコネクションの確立直後に構築されていない場合でも、当該TCPコネクションにおけるHTTPセッションおよびデータ通信のこれまでの推移、履歴などを記録しておけば、これらの情報を参照することによってウィンドウサイズの初期値を推定できる。例えば、当該TCPコネクションにおける直前のセッションにおいて、ウィンドウサイズが1,2,4,8,16と増加して終了していれば、今回のセッションはウィンドウサイズが32から始まるものと推定できる。なお、ウィンドウサイズの初期値、最大値および増え方は、各エンド端末の種類や採用されるTCPの種別により異なるが、各エンド端末の種類は、例えばHTTPのユーザエージェントを分析することで判別できる。また、TCPの種別はTCPヘッダに明示的に記述された情報やその後のシーケンスや挙動などを基に判定できる。第2の手法では、パケット送信が無い状態、すなわちパケット送信到着間隔が、例えば1RTTairや05RTTairなどの閾値を超えたら、当該タイミングをウィンドウサイズに基づく一括送信の切れ目と見なし、例えば一括送信の総回数が10回のセッションであれば、最後の一括送信を除く残り9回分の一括送信の総データ量をSumSentSzとして算出する。第3の方法では、前記第1または第2の方法と同様の手法で最後の一括送信のデータ量前記Szに相当を求め、これを総データ量から減じることでSumSentSzを算出する。例えば、一括送信の総回数が10回のセッションであれば、その総データ量から最後10回目の一括送信のデータ量前記Szに相当を減じてSumSentSzを算出する。前記TotalTimeは、キャプチャポイントで観測された、最初のHTTPRESパケットの到着時刻tcから最後のHTTPRESパケットの到着時刻tdまでの代替所要時間をT、無線区間においてデータ量とは無関係に固定的にかかる無線エンド側の遅延時間をRTTair、前記データ量Szの送信に要する時間をαとすれば次式で表される。TotalTime=T{RTTairα}...したがって、上式は前記データ量Szの送信時におけるスループットをRとすれば、次式のように展開できる。Rate=TotalSize/TotalTime=TotalSize/=TotalSize/}...上式を更に展開すると次式が得られる。Rate=RTotalSize/SzRate{RSz}=RTotalSize...ここで、データ通信時におけるスループットは当該通信時間内において同一であると仮定する、すなわち本実施形態ではセッション内の平均スループットを求めたいので、RateRとすれば、上式は次式のように展開できる。RSz=TotalSizeR=/=SumSentSz/...したがって、次式が成立し、前記ACKを待たずに送信されたデータ量Szを考慮する必要が無くなる。Ratebps=SumSentSz/...前記SumSentSzは、これを前記第1の方法で算出するのであれば、セッション開始時からのウィンドウサイズの遷移履歴に基づいて、ウィンドウサイズ単位で一括送信されたパケット群の切れ目を識別し、最初に送信されたパケット群P1から最後に送信されたパケット群Peの直前に送信されたパケット群Pe1までの総データ量ΣP=P1P2...Pe1として、前記通信ログを参照することで求められる。例えば、セッション開始時のウィンドウサイズが1であり、最後のパケット群が送信された際のウィンドウサイズが8であり、ウィンドウサイズが1,2,4,8...と増加するのであれば、最初の一括送信では1パケット、2番目の一括送信では2パケット、3番目の一括送信では4パケットが送信され、4番目の一括送信で残りの全てのパケット8パケット以下が送信されたことになる。したがって、SumSentSzは7パケット相当となる。また、セッション開始時のウィンドウサイズが2であり、最後のパケット群が送信された際のウィンドウサイズが8であれば、最初の一括送信では2パケット、2番目の一括送信では4パケットが送信され、3番目の一括送信で残りの全てのパケット8パケット以下が送信されたことになる。したがって、SumSentSzは6パケット相当となる。なお、前記SumSentSzを前記第2の方法で算出するのであれば、パケット送信到着間隔が閾値を超えた切れ目に基づいて識別される一括送信の総回数が例えば3回であり、最後を除く1,2回目の一括送信のパケット数がそれぞれ4,8であれば、SumSentSzは12パケット相当となる。さらに、前記SumSentSzを前記第3の方法で算出するのであれば、前記ウィンドウサイズの遷移やパケット送信到着間隔に基づいて一括送信の切れ目を識別し、総データ量ΣPが12パケット相当であって、最後の一括送信のデータ量が2パケット相当であれば、SumSentSzは10パケット相当となる。前記代替所要時間Tは、最初のHTTPRESパケットの到着時刻tcから最後のHTTPRESパケットの到着時刻tdまでの期間として、前記通信ログを参照することで求められる。さらに、データ量に依存しない各エンド側の固定遅延時間RTTair,RTTsrvは、3ウェイハンドシェイクにおける各制御パケットの到着時刻差から算出できる。なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、これをMHがサーバから通信データを受けきるまでとするならば、最後のACKがMHからチャプチャポイントに到着するまでの時間が不要となる。したがって、上式の代わりに次式を用いる。Ratebps=SumSentSz/...さらに、スループット計測の所要時間TotalTimeを、サーバがMHからACKを受信するまでとするならば、最後のACKがキャプチャポイントからサーバへ到着するまでの時間が不足する。したがって、上式,の代わりに次式を用いる。Ratebps=SumSentSz/...前記第2算出部105bは、通信ログを参照し、以上のようにしてSumSentSz、TおよびRTTair、さらには必要に応じてRTTsrvを算出すると共に、これらを上式,またはに適用することで無線区間のスループットRatebpsを算出する。なお、上式の代替所要時間Tについては、ウィンドウサイズが最大値に達するまでウィンドウが開ききるまでの一括送信回数n分やデータ通信における全ての一括送信回数N分だけ、無線エンド側固定遅延時間RTTairとサーバエンド側固定遅延時間RTTsrvとの和RTTsumだけ減じ、例えば上式であれば次式のように変更しても良い。Ratebps=SumSentSz/RTTair...次いで、1RTTセッションのスループット計測について説明する。図5は、1RTTセッションのシーケンスフローである。時刻t1~t3では、3ウェイハンドシェイクによりMHとサーバとの間にTCPコネクションが確立される。すなわち、時刻t1では、MHからサーバへSYNパケットが送信される。時刻t2では、SYNパケットを受信したサーバからMHへSYNACKパケットが返信される。時刻t3では、前記SYNACKパケットを受信したMHからサーバへACKが返信される。TCPコネクションが確立されると、時刻t4では、MHからサーバへHTTPREQパケットが送信される。時刻t5では、前記HTTPREQパケットの受信に応答してサーバからMHへHTTPRESパケットが送信される。時刻t6では、前記HTTPRESパケットの受信に応答してMHからサーバへACKパケットが返信される。時刻t7では、サーバからMHへFINパケットが送信される。時刻t8では、前記FINパケットに応答してMHからサーバへACKパケットが返信される。このようなシーケンスにおいて、本実施形態では3ウェイハンドシェイクで送受されるSYNパケットの到着時刻taおよびSYNACKパケットの到着時刻tbがキャプチャされ、TCPコネクション確立後のHTTPセッション内では、下りパケット本実施形態では、HTTPRESパケットおよびFINパケットの到着時刻のみがキャプチャされる。なお、今回のセッションの終了後に次のセッションが直ちに開始される場合は、後に詳述するように、当該次のセッションにおいてサーバからMHへ最初に送信される下り方向のHTTPRESパケットが、前記FINパケットの代わりにキャプチャされる。ここで、MH側の無線区間のスループットRateは、観測期間中に測定対象コネクションで通信される総データ量をTotalSize、通信の所要時間をTotalTimeとすれば、次式で表される。Ratebps=TotalSizebit/TotalTimesec...前記TotalSizeは、唯一の送信パケットのデータ量なので、そのログ情報を参照することで求まる。所要時間TotalTimeは、HTTPRESパケットの到着時刻tcからFINパケットの到着時刻teまでの代替所要時間Tと、前記HTTPRESパケットに対するACKパケットの到着時刻tdからFINパケットの到着時刻teまでの所要時間補正値ΔT3との差分として求まる。前記代替所要時間Tは、通信ログとして記録されたHTTPRESパケットおよびFINパケットの各到着時刻tc,teから求まる。一方、所要時間補正値ΔT3はサーバエンド側の固定遅延時間RTTsevに相当し、これはTCPコネクション確立時の3ウェイハンドシェイクにおけるSYNパケットに対するSYNACKパケットの応答遅延時間に相当するので、SYNパケットの到着時刻taからSYNACKパケットの到着時刻tbまでの所要時間として求まる。なお、前記サーバエンド側の固定遅延時間RTTsevや無線エンド側固定遅延時間RTTairも、厳密にはスループットの影響を受けることになるが、3ウェイハンドシェイクでは、送受されるパケットサイズが他のデータパケットに較べて十分に小さいので、実質的には無視できる。前記第2算出部105bは、通信ログを参照し、以上のようにしてTotalTimeおよびTotalSizeを算出すると共に、これらを上式に適用することで、無線区間のスループットRatebpsを算出する。本実施形態によれば、TCPコネクションの確立時に送受される制御パケット、およびTCPコネクション確立後のコネクション内ではダウンロード方向のパケットのみをキャプチャするだけで無線区間のスループットを正確に求められるようになる。したがって、一箇所のキャプチャポイントにおいて、一コネクション当たりのキャプチャ対象のパケット数を減ずることができ、その結果、多数のコネクションを監視することが可能になるので、スケーラブルなスループット測定が可能になる。図6は、セッション終了後もTCPコネクションが維持されるためにFINパケットを観測できないときに、当該FINパケットに代えて、次のセッションでサーバからMHへ送信されるHTTPRESパケットの到着時刻に基づいて所要時間TotalTimeを算出する例を示したシーケンスフローである。TCPコネクションが確立されると、時刻t4では、最初のHTTPセッションにおいて、MHからサーバへHTTPREQパケットが送信される。時刻t5では、前記HTTPREQパケットの受信に応答してサーバからMHへHTTPRESパケットが送信される。時刻t6では、前記HTTPRESパケットの受信に応答してMHからサーバへACKパケットが返信される。時刻t7では、次のHTTPセッションにおいて、MHからサーバへHTTPREQパケットが送信される。時刻t8では、前記HTTPREQパケットの受信に応答してサーバからMHへHTTPRESパケットが送信される。時刻t9では、前記HTTPRESパケットの受信に応答してMHからサーバへACKパケットが返信される。本実施形態では、前記所要時間TotalTimeが、最初のHTTPRESパケットの到着時刻tcから次のHTTPRESパケットの到着時刻teまでの代替所要時間Tと、前記最初のHTTPRESパケットに対するACKパケットの到着時刻tdから次のHTTPRESパケットの到着時刻teまでの所要時間補正値ΔT4との差分として求まる。前記補正値ΔT4は、サーバエンド側固定遅延時間RTTsrvとして求まる。そして、前記TotalSizeは、唯一の送信パケットのデータ量なので、そのログ情報を参照することで求まり、これらを上式に適用することで、無線区間のスループットRatebpsを算出できる。なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをMHがサーバから通信データを受けきるまでとするならば、最後のACKがMHからチャプチャポイントに到着するまでの時間が不要となる。したがって、前記代替所要時間Tから、サーバエンド側固定遅延時間RTTsrvおよび片道分の無線エンド側固定遅延時間RTTair2を減じることで前記所要時間TotalTimeを算出するようにしても良い。さらに、所要時間TotalTimeをサーバがMHからACKを受信するまでとするならば、最後のACKがキャプチャポイントからサーバへ到着するまでの時間を加える必要がある。したがって、前記代替所要時間Tから片道分のサーバエンド側固定遅延時間RTTsrv2を減じることで前記所要時間TotalTimeを算出するようにしても良い。次いで、本発明の第2実施形態について説明する。図7は、前記キャプチャ装置1の第2実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。ログ情報補完部106は、監視対象のコネクションに関して、前記パケットキャプチャ部101がキャプチャし損ねたパケットおよびそのデータ量を、その前後にキャプチャされたパケットのデータ量から予測されるMH側のウィンドウサイズWSの遷移状態から予測して前記ログ情報管理部102に補完する。すなわち、TCPではウィンドウサイズがコネクションの確立直後から離散的かつ規則的に所定の上限値まで増加し、例えば3回目の通信では、4パケット分のデータが送信されることになる。したがって、例えば前回の通信では2パケット分のログ情報が記録され、次回の通信では8パケット分のログ情報が記録されているにも関わらず、今回の通信で3パケット分のログ情報しか記録されていなければ、ここで1パケット分のキャプチャ漏れが生じたと判断して、当該1パケット分のログ情報を追加する。なお、キャプチャし損ねたパケットは、キャプチャできた各パケットに記述されているシーケンス番号の連続性に基づいても把握できる。本実施形態によれば、パケットキャプチャ部101においてパケットのキャプチャ漏れが生じても、ウィンドウサイズWSやシーケンス番号の遷移履歴に基づいて、キャプチャ漏れしたパケットのログ情報を補完できるので、総データ量をより正確に算出できるようになり、その結果、スループットの測定精度が向上する。なお、上記の実施形態では、代替所要時間を補正するための各エンド側固定遅延時間が、TCPコネクション確立時の3ウェイハンドシェイクで送受される制御パケットの到着時刻差に基づいて算出されるものとして説明したが、本発明はこれのみに限定されるものではなく、同一エリアまたは同一基地局において同一時間帯に他の同一種別の端末で別途に計測された遅延時間の算術平均や移動平均などを用いてもよい。また、上記の各実施形態では、スループットの計測対象がHTTPセッションである場合を説明したが、本発明はこれのみに限定されるものではなく、メールセッションのスループット計測にも同様に適用できる。ただし、メールセッションではTCPコネクションの確立後にユーザ認証処理やCIMAP処理などが実行され、これらのオーバヘッド処理によりデータ転送とは無関係な遅延が発生する。このため、メールセッションに対して前記HTTPセッションの場合と同様にスループット計測を行うと、本来よりも小さな計測結果しか得られない。したがって、本発明をメールセッションに適用する場合には、セッションサイズの小さいメールセッション例えば、1KB以下は計測対象外として当該メールセッションのセッション時間をオーバヘッド時間複数であれば、その平均時間として記憶し、セッションサイズの大きいメールセッション例えば、50KB以上のみを計測対象とすると共に、そのセッション時間から前記オーバヘッド時間を減じて所要時間を求めることが望ましい。"