"無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上でパッシブに監視して通信品質を測定する通信品質測定装置において、無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントに到着した上りのTCPパケットをキャプチャするキャプチャ手段と、前記キャプチャされたパケットのログ情報をコネクションおよび/またはセッションごとに管理するログ情報管理手段と、前記ログ情報に基づいて、前記キャプチャポイントから見た各エンド側の固定的な遅延時間を算出するエンド側固定遅延算出手段と、スループット計測用の所要時間内に通信されたデータ量に基づいて無線クライアント側のスループットを算出する通信品質算出手段とを具備し、前記通信品質算出手段は、無線区間の影響を受けて変化する代替所要時間を上りのTCPパケットの到着時刻差で計測し、当該代替所要時間を前記エンド側の固定遅延時間で補正することで前記所要時間を算出することを特徴とする通信品質測定装置。前記エンド側固定遅延算出手段は、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて、前記各エンド側の固定遅延時間を算出することを特徴とする請求項1に記載の通信品質測定装置。前記ログ情報を参照し、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が、1回および2回以上のいずれであるかを判定する一括送信回数判定手段をさらに具備し、前記通信品質算出手段は、前記一括送信回数に基づいて、到着時刻を前記代替所要時間の算出に用いる上りパケットを選択することを特徴とする請求項1または2に記載の通信品質測定装置。前記一括送信回数判定手段は、前記通信開始時のウィンドウサイズを検知するウィンドウサイズ検知手段を具備し、前記一括送信回数を、通信のデータ量が前記通信開始時のウィンドウサイズ以下であれば1回と判定し、前記ウィンドウサイズよりも大きければ2回以上と判定することを特徴とする請求項3に記載の通信品質測定装置。前記一括送信回数が2回以上と判定されたときに、前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、前記品質算出手段は、無線クライアントからサーバへウィンドウサイズ単位で一括送信される第1番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを前記代替所要時間として算出し、前記2番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和を少なくとも一倍を減じて所要時間を算出し、前記総データ量を前記所要時間で除してスループットを算出することを特徴とする請求項3または4に記載の通信品質測定装置。前記一括送信回数が2回以上と判定されたときに、前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、前記品質算出手段は、無線クライアントからサーバへウィンドウサイズ単位で一括送信される第1番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを前記代替所要時間として算出し、前記2番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも1倍だけ減じ、片道分のサーバエンド側固定遅延時間を加えて所要時間を算出し、前記総データ量を前記所要時間で除してスループットを算出することを特徴とする請求項3または4に記載の通信品質測定装置。前記品質算出手段は、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の倍を減じることを特徴とする請求項5または6に記載の通信品質測定装置。前記品質算出手段は、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和を、ウィンドウサイズが開き切るまでの通信回数分の倍数だけ減じることを特徴とする請求項5または6に記載の通信品質測定装置。前記一括送信回数が1回と判定されたときに、前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、前記品質算出手段は、TCPコネクション確立時の3ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第1番目のパケット群の到着時刻までを前記代替所要時間として算出し、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて所要時間を算出し、前記第1番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする請求項3または4に記載の通信品質測定装置。前記一括送信回数が1回と判定されたときに、前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、前記品質算出手段は、TCPコネクション確立時の3ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第1番目のパケット群の到着時刻までを前記代替所要時間として算出し、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて、さらに片道分のサーバエンド側固定遅延時間を加えて所要時間を算出し、前記第1番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする請求項3または4に記載の通信品質測定装置。前記キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を具備したことを特徴とする請求項1ないし10のいずれかに記載の通信品質測定装置。測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項1に記載の通信品質測定装置。前記一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、当該取得した情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項3ないし11のいずれかに記載の通信品質測定装置。前記一括送信回数判定手段は、無線クライアントの種別を識別し、当該種別から識別されるTCPウィンドウサイズの初期値、最大値および増え方を規定する情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項3ないし11のいずれかに記載の通信品質測定装置。前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、通信開始時のウィンドウサイズ、最大値および増え方に基づいて識別することを特徴とする請求項1ないし4のいずれかに記載の通信品質測定装置。前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、各パケットの到着時刻の差に基づいて識別することを特徴とする請求項1ないし4のいずれかに記載の通信品質測定装置。前記一括送信回数が1回と判定されたときに、TCPコネクションの確立から第1番目のパケット群の到着時刻までの時間が無線エンド側固定遅延時間の半分以内であることを条件にスループットが算出されることを特徴とする請求項9または10に記載の通信品質測定装置。無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた上りのTCPパケットのログ情報をコネクションごとに管理し、前記ログ情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定し、前記一括送信回数が2回以上であると、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、無線クライアントからサーバへウィンドウサイズ単位で一括送信される第1番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを前記代替所要時間として算出し、前記2番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも1倍を減じて所要時間を算出し、前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする通信品質測定方法。無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた上りのTCPパケットの種別および到着時刻をログ情報としてコネクションごとに管理し、前記ログ情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定し、前記一括送信回数が1回であると、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、TCPコネクション確立時の3ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第1番目のパケット群の到着時刻までを前記代替所要時間として算出し、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて所要時間を算出し、前記第1番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする通信品質測定方法。前記スループット計測がHTTPセッション単位で行われ、セッション間のthinktimeがスループットの計測対象期間から除外されることを特徴とする請求項18または19に記載の通信品質測定方法。前記スループット計測がメールセッション単位で行われ、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項18または19に記載の通信品質測定方法。相互に通信するノードペアの一方が無線端末である場合、その無線区間の通信品質としてスループットを測定するのであれば、経路上のキャプチャポイントにおいて、データ通信の開始を要求する要求パケットの到着時刻tstartと、データ通信の完了を通知する完了パケットの到着時刻tendと、その間に送受された総データ量dとを測定し、総データ量dをデータ通信の所要期間TotalTimeで除せば良い。なお、無線区間を含むネットワークでのデータ通信の場合、一般的に無線区間がボトルネックとなることから、無線区間側のスループットを算出することにより、ユーザあるいは端末が享受体感しているスループットを算出することができる。しかしながら、このようなパッシブ測定ではキャプチャポイントを通過するパケット量が膨大であるため、双方向の全てのパケットを漏れなくキャプチャし、かつ全ての要求パケットと応答パケットとを対応付けることは、処理規模が膨大となり、リアルタイムまたは准リアルタイムに計算するのが困難であった。さらに、リクエストパケットに対する応答として返信されるACKパケットは、TCPの性質上、一つのデータパケットの受信毎に返信されるとは限らない。このため、パケット転送の終了タイミングをACKパケットの到着時刻で代表させてしまうと、所要期間が大きな誤差を含むことになり、スループットを正確に測定できなくなる。本発明の目的は、上記した従来技術の課題を全て解決し、監視対象の通信トラヒックが集約される経路上でパケットをパッシブに測定し、パケットの種別や到着時刻に基づいて無線クライアント側の通信品質を正確に分析できる通信品質測定方法および装置を提供することにある。上記の目的を達成するために、本発明は、無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上でパッシブに監視して通信品質を測定する通信品質測定装置において、以下のような手段を講じた点に特徴がある。無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントに到着した上りのTCPパケットをキャプチャするキャプチャ手段と、キャプチャされたパケットのログ情報をコネクションおよび/またはセッションごとに管理するログ情報管理手段と、ログ情報に基づいて、キャプチャポイントから見た各エンド側の固定的な遅延時間を算出するエンド側固定遅延算出手段と、スループット計測用の所要時間内に通信されたデータ量に基づいて無線クライアント側のスループットを算出する通信品質算出手段とを設けた。通信品質算出手段は、無線区間の影響を受けて変化する代替所要時間を上りのTCPパケットの到着時刻差で計測し、当該代替所要時間を前記エンド側の固定遅延時間で補正することで前記所要時間を算出するようにした。エンド側固定遅延が、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて算出されるようにした。データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が、1回および2回以上のいずれであるかを判定し、この一括送信回数に基づいて、到着時刻を前記代替所要時間の算出に用いる上りパケットを選択するようにした。通信開始時のウィンドウサイズを検知するウィンドウサイズ検知手段を設け、一括送信回数を、通信のデータ量が通信開始時のウィンドウサイズ以下であれば1回と判定し、ウィンドウサイズよりも大きければ2回以上と判定するようにした。データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が2回以上と判定されると、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、無線クライアントからサーバへウィンドウサイズ単位で一括送信される第1番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを代替所要時間として算出し、2番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、前記代替所要時間から、無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも1倍を減じて所要時間を算出し、前記総データ量を前記所要時間で除してスループットを算出するようにした。なお、無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和を減じる回数はスループットの定義に応じて変更しても良い。例えば、このような固定遅延オーバヘッドをスループットに含ませないのであれば、各固定遅延時間の和の倍を減じれば良い。また、TCPウィンドウサイズが開き切るまでの固定遅延のみを余計なオーバヘッドとみなすのでれば、TCPウィンドウサイズが開ききるまでの通信回数の倍数だけ減じればよい。さらに、所要時間として、無線クライアントがデータを送信しきるまでではなく、サーバが受信するまでとするのであれば、前記所要時間は、代替所要時間から無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも1倍を減じ、片道分のサーバエンド側固定遅延時間を加えることで算出する。データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が1回と判定されると、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、TCPコネクション確立時の3ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第1番目のパケット群の到着時刻までを前記代替所要時間として算出し、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて所要時間を算出し、前記第1番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、前記総データ量を前記代替所要時間で除してスループットを算出するようにした。ただし、このようなスループット算出方式は、TCPの確立直後例えば、01sec以内からデータ通信が開始されることが前提となる。なお、所要時間として、無線クライアントがデータを送信しきるまでではなく、サーバが受信するまでとするのであれば、前記所要時間は、代替所要時間から無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて、さらに片道分のサーバエンド側固定遅延時間を加えることで算出する。キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段をさらに設けた。測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とするようにした。スループット計測がHTTPセッション単位で行われ、セッション間のthinktimeがスループットの計測対象期間から除外されるようにした。一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、当該取得した情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定するようにした。本発明によれば、以下のような効果が達成される。TCPコネクションのスループットを、ネットワーク上に設けたキャプチャポイントにおいて一方向のパケット無線クライアントからサーバへ送信される上りパケットのみをパッシブに監視するだけで計測できるようになる。したがって、一コネクション当たりの監視パケット数を少なくでき、その結果、多数のコネクションを同時に監視できるようになるので、スケーラブルなスループット測定が可能になる。無線側およびサーバ側の各エンド側固定遅延時間が、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて求められるので、各エンド側の固定遅延時間を計測する為の機能を別途に用意する必要がない。データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定し、一括送信回数が1回の場合と2回以上の場合とで、スループットの測定アルゴリズムを異ならせるので、通信の総データ量にかかわらず常に正確なスループット計測が可能になる。また、一括送信回数が1回であるか2回以上であるかを、通信開始時のウィンドウサイズをデータサイズと比較するだけで判定できるようになる。キャプチャ漏れしたパケットのログ情報を、ウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を設けたので、通信の総データ量を、より正確に算出できるようになる。メールセッションでは、セッションサイズの小さいメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズの大きいメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じてメールセッションの所要時間とするので、メールセッションについても正確なスループット計測が可能になる。HTTPセッションでは、スループット計測がセッション単位で行われるので、例えばHTTPWEBにおいて、今回のセッションと次回のセッションとの間に無線クライアント側でユーザのThinkTimeが生じても、このThinkTimeが除外された正確なスループット計測が可能になる。TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得することにより、クライアント端末やTCPの違いにかかわらず通信開始時のウィンドウサイズを正確に判別できるようになる。その結果、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を正確に判定できるようになる。以下、図面を参照して本発明の実施形態について詳細に説明する。ここでは初めに、本発明の概要について説明し、次いで、その具体的な実施形態について説明する。なお、以下の説明では基本的に、トランスポート層第4層での接続をコネクションと表現し、これよりも上位層での接続をセッションと表現することで両者を区別しているが、両者をコネクションで代表する場合もある。本発明は、無線区間を含むTCPコネクションのスループットをコネクション単位で測定するものとし、ネットワーク上のキャプチャポイントで監視するキャプチャ対象のパケットを、TCPコネクションの確立時に送受される制御パケット、ならびにTCPコネクション確立後は当該コネクションまたはそのセッション内で観測される上りパケットのみに限定することで、一コネクション当たりのキャプチャ対象のパケット数を減じ、多数のコネクションを監視対象とできるようにすることで、パッシブ測定に必須のスケーラビリティを担保しながら、精度の高いスループット測定を可能にしている。ただし、このようにして計測される期間上りパケットの到着時刻差は、スループット計測のための前記所要時間TotalTimeとは異なり、また当該期間内で通信されるデータ量も、スループット計測のための前記総データ量dとは異なる。そこで、本発明ではスループット計測に用いる所要時間TotalTimeおよび総データ量dを、前記期間に応じて補正、見直すことで、所要時間TotalTimeを直接求めることなくスループットを正確に計測できるようにしている。さらに、本発明では通信データが無線クライアントからサーバへウィンドウサイズ単位で一括送信バルク送信される回数を判定し、この一括送信回数が1回であるのか、あるいは2回以上であるのかに応じて測定アルゴリズムを異ならせることで、各セッションにおけるデータ量の多少に関わらずスループットを高精度で測定できるようにしている。A.セッションが2回以上の一括送信を要する場合、あるいは総データ量が初期ウィンドウサイズを越える場合/無線クライアント端末MH側のスループットは、図7に示したように、3ウェイハンドシェイクによるTCPコネクションの確立後、MHが最初のリクエストパケットを送信した時刻tsから、最後のリクエストパケットに対してサーバから返信されたACKパケットがMHへ到着した時刻teまでを所要時間Tairとし、この間にアップロードされたデータ量M1,M2...の総和を前記所要時間Tairで除すことで求まる。しかしながら、本発明ではキャプチャポイントをMHではなくネットワーク上に設定し、かつ監視対象のパケットを、TCPコネクション確立後の当該コネクション内では上りパケットのみに限定し、キャプチャ対象のパケット数を減ずることでスケーラビリティを確保する。したがって、ここではMHからサーバへアップロードされるパケットのキャプチャポイントへの到着時刻のみを所要時間の算出基準とすることを考える。ネットワーク上にキャプチャポイントを設けた場合、第1番目のリクエストパケットの到着時刻t1から最後ここでは、第3番目のリクエストパケットに対するACKの到着時刻t5までが前記スループット計測の所要時間TotalTimeに相当する。しかしながら、本発明では下りパケットは監視対象外であり、また、第1番目のリクエストパケットの到着時刻t1には無線区間の影響が現れない。そこで、上りパケットの到着時刻のみで計測でき、かつ無線区間の影響を受けて変化する代替の所要時間Tとして、第1番目のリクエストパケットの到着時刻t1から最後ここでは、第3番目のリクエストパケットの到着時刻t4までの期間t4t1に着目する。第2番目のアップロードが無線区間の影響を受けることで変化する所要時間ΔT2は、第1番目のリクエストパケットの到着時刻t1から第2番目の最後のリクエストパケットの到着時刻t3までの経過時間t3t1として求まる。そして、この所要時間ΔT2は、第1番目のリクエストパケットの到着時刻t1からそのACKパケットの到着時刻t2までの所要時間t2t1と、前記t2からt3までの所要時間t3t2との和に等しい。ここで、サーバ側のネットワーク及び接続回線は有線回線であることが多く、帯域幅も大きく、スループットによる遅延は微少であるとみなせることから、前記所要時間t2t1は、サーバエンド側の固定的な遅延時間RTTsrvと略等しく、所要時間t3t2は、第2番目のリクエストパケットのデータ量をM2とすれば、無線エンド側の固定的な遅延時間RTTairと所定のスループット下でデータ量M2を送信するのに要する遅延時間tとの和に等しい。したがって、前記所要時間ΔT2は次式で表せる。ΔT2=RTTsrvRTTairt...同様に、第3番目のアップロードが無線区間の影響を受けることで変化する所要時間ΔT3は、当該第3番目のリクエストパケットのデータ量をM3とすれば、次式で表せる。ΔT3=RTTsrvRTTairt...したがって、サーバエンド側および無線側の各固定遅延時間RTTsrv,RTTairの和をRTTsumで表現すれば、最後の第3番目の送信までに要する代替所要時間T3ΔT2ΔT3は次式で表せる。T3=tt2×RTTsum...また、第2、3番目のアップロード時のスループットをRとし、各リクエストパケットのデータ量M2,M3の総和をΣMとすれば次式,が得られる。T3=ΣM/R2×RTTsum...R=ΣM/...したがって、n番目のアップロードまでのスループットRateは、当該n番目までにアップロードされたリクエストパケットのデータ量から第1番目のリクエストパケットのデータ量を減じたデータ量をSzとすれば、次式で求まる。Rate=Sz/×RTTsum...なお、上式の右辺分母において、TnからRTTsumの減じる回数倍数はスループットの定義に応じて適宜に変更でき、少なくともRTTsumの1倍が減ぜられれば良い。例えば、RTTsumのオーバヘッドをスループットに含ませないのであれば、上式のように、送信回数分のオーバヘッドn1×RTTsumを全てTnから減じるようにすればよい。これに対して、RTTsumのオーバヘッドも含めてスループットと定義するのであれば、次式のように、所要時間ΔTの開始直後の最初の1回分のRTTsum図7の時刻t1~t3に占めるRTTsumのみを減じるようにすれば良い。Rate=Sz/...上式によれば、本発明のようにネットワーク上にキャプチャポイントを設け、このキャプチャポイントにおいて上りパケットの到着時刻のみを基準にしてスループットを計測しようとする際に、その所要時間の開始時に含まれてしまう無関係なオーバヘッドを排除できるので、より正確なスループット計測が可能になる。さらに、TCPウィンドウサイズが開き切るまでのRTTsumのみを余計なオーバヘッドとみなすのでれば、TCPウィンドウサイズが開ききるまでのm回分のRTTsumのみが排除されるように、次式を採用しても良い。Rate=Sz/...以上の考察から、本発明では第1番目のリクエストパケットの到着時刻t1からn番目のリクエストパケットの到着時刻までを代替所要時間Tnとし、その間にアップロードされた総データ量Sz、代替所要時間Tnならびに無線エンド側およびサーバエンド側の各固定遅延時間RTTair,RTTsrvをログ情報等から算出し、これらをスループットの定義に応じて上式,,のいずれか以下、単に式で代表する場合もあるに代入することでスループットRateを算出する。なお、以上ではMHから送信されたリクエストパケットがキャプチャポイントへ到着するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをサーバがリクエストパケットを受けきるまでとするならば、キャプチャポイントからサーバまでの区間に相当する片道分のサーバエンド側固定遅延時間RTTsrv2を上式の分母に加算すれば良い。B.セッションが1回の一括送信のみで完了する場合、あるいはデータ量が初期ウィンドウサイズ以下の場合/無線クライアント端末MH側のスループットは、図8に示したように、3ウェイハンドシェイクによるTCPコネクションの確立後、MHがリクエストパケットを送信した時刻tsから、このリクエストパケットに対してサーバから返信されたACKパケットがMHへ到着した時刻teまでを所要時間Tairとし、この間にアップロードされたデータ量M1を前記所要時間Tairで除すことで求まる。しかしながら、本発明ではキャプチャポイントをMHではなくネットワーク上に設定し、かつ監視対象のパケットを、TCPコネクション確立後の当該コネクション内では上りパケットのみに限定し、キャプチャ対象のパケット数を減ずることでスケーラビリティを確保する。したがって、ここではMHからサーバへアップロードされるパケットのキャプチャポイントへの到着時刻のみを所要時間の算出基準とすることを考える。ネットワーク上にキャプチャポイントを設けると、セッションが1回の送信のみで完了する場合、TCPコネクション確立後の当該コネクション内でキャプチャできるリクエストパケットが第1番目のリクエストパケットに限られてしまうので、アップロードの所要時間を算出することができない。そこで、本発明では第1番目のアップロードが無線区間の影響を受けることで変化し、リクエストパケットの到着時刻差のみで計測できる代替所要時間Tとして、3ウェイハンドシェイクにおいてMHからサーバへ送信されるSYNパケットの到着時刻t1から第1番目のリクエストパケットの到着時刻t2までに注目し、この代替所要時間Tt2t1にアップロードされる総データ量に基づいてスループットを計測する。ただし、本実施形態では3ウェイハンドシェイクによるTCPの確立直後から最初のデータ通信が開始されることが前提となる。前記TCPの確立直後からの開始であるか否かは、TCPの確立から最初のデータ通信が開始されるまでの時間本実施形態では、3WHSにおいてMHから送信されるACKのキャプチャ時刻から、最初のデータのキャプチャ時刻までの時間が、12RTTAIR以内であるか否か、あるいは例えば01sec以内であるか否かに基づいて判断できる。これは、TCPが確立されてから12RTTAIRあるいは例えば01secを超えると、平均的な無線回線側の片側オーバヘッド遅延を超えることになり、連続した通信ではないと解せるからである。換言すれば、12RTTAIR以内あるいは例えば01sec以内であれば、オーバヘッド未満の通信であって連続通信であると解せる。ただし、上記の代替所要時間Tは、無線側のスループットに影響されないサーバエンド側および無線エンド側の各固定遅延時間RTTsrv,RTTair、ならびにHTTPREQが無線区間をMHからキャプチャポイントまでの片道だけ経由する際の遅延時間RTTair/2を余計に含むので、スループット計測に用いる所要時間TotalTimeは次式で求める。TotalTime=T-RTTSUM-RTTair/2...また、この所要時間T内にアップロードされるリクエストパケットの総データ量ΣMは、HTTPREQのパケットサイズM1とACKのデータサイズMaとの和なので次式で求まる。なお、3ウェイハンドシェイクの最初にMHから送信されるSYNについては、無線区間の影響が代替所要時間Tに表れないので考慮する必要はない。ΣM=M1Ma...したがって、アップロード時のスループットRateは次式で求まる。Rate=M/T...本発明では、代替所要時間Tt2t1、RTTSUM、RTTair/2およびパケットサイズM1を通信ログ等に基づいて算出し、これらを上式に代入することでスループットRateを算出する。なお、以上ではMHから送信されたリクエストパケットがキャプチャポイントへ到着するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをサーバが通信データを受けきるまでとするならば、片道分のサーバエンド側固定遅延時間RTTsrv2を上式の分母に加算すれば良い。次いで、本発明の実施形態について具体的に説明する。図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からサーバへ送信された総データ量をデータ通信開始時における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パケットが返信される。本実施形態では、前記SYN、SYNACKおよびACKの各パケットがキャプチャされ、その到着時刻ta,tb,tcが通信ログとして記録される。TCPコネクションが確立されると、時刻t4では、MHからサーバへ最初のHTTPREQパケットが送信されてHTTPセッションが開始される。時刻t5では、前記HTTPREQパケットの受信に応答して、サーバからMHへACKが返信される。このACKには、サーバ側で受信可能な最大受信ウィンドウサイズが記述されている。時刻t6,t7では、前記ACKの受信に応答して、MHからサーバへ2番目のHTTPREQパケットが送信される。このとき、MHはサーバから通知された最大受信ウィンドウサイズとMH自身が管理する送信ウィンドウサイズとに基づいて今回のウィンドウサイズWSを決定する。ここでは、ウィンドウサイズWSが2に決定され、2つのHTTPREQパケットが一括送信されるものとして説明を続ける。時刻t8,t9では、前記HTTPREQパケットの受信に応答して、サーバからMHへACKが返信される。本実施形態では、このような2RTT以上セッションについては上式が適用され、右辺分母の代替所要時間Tnは、第1番目のHTTPREQパケット群の到着時刻tdからn番目最後のHTTPREQパケット群の到着時刻teまでの経過時間tetdとして、前記通信ログを参照することで算出される。なお、上記のようにHTTPREQパケットのアップロードにおいてウィンドウサイズ単位での一括送信が繰り返される場合、第1番目のHTTPREQパケット群のログ情報と第2番目以降の各HTTPREQパケット群のログ情報との識別が難しくなる。そこで、本発明ではウィンドウサイズ単位で一括送信されるパケット群の切れ目を、以下のような手法で推定するようにしている。第1の手法として、MHがパケットを送信する際のウィンドウサイズの遷移から推定する方法がある。第2の方法として、MHが送信するパケットの連続送信状態から推定する方法がある。第1の手法では、ウィンドウサイズがTCPセッションの確立直後から通信毎に、例えば1,2,4,8...64と離散的かつ規則的に増加する点に着目し、各パケットの到着時刻およびデータサイズに基づいて、一括送信されるパケット群の切れ目が推定される。このとき、TCPセッションの確立時刻とHTTPセッションの開始時刻との差が所定の閾値例えば、1sec以内であり、HTTPセッションがTCPコネクションの確立直後に構築されているのであれば、当該HTTPセッションが最初のセッションであってウィンドウサイズ=1から開始されたと推定できるので、第1番目のHTTPREQパケットを容易に推定できる。また、HTTPセッションがTCPコネクションの確立直後に構築されていない場合でも、当該TCPコネクションにおけるHTTPセッションおよびデータ通信のこれまでの推移、履歴などを記録しておけば、これらの情報を参照することによってウィンドウサイズの初期値を推定できる。例えば、当該TCPコネクションにおける直前のセッションにおいて、ウィンドウサイズが1,2,4,8,16と規則的に増加して終了していれば、今回のセッションはウィンドウサイズ32から始まるものと推定できる。なお、ウィンドウサイズの初期値、最大値および増え方は、各エンド端末の種類や採用されるTCPの種別により異なるが、各エンド端末の種類は、例えばHTTPのユーザエージェントを分析することで判別できる。また、TCPの種別はTCPヘッダに明示的に記述された情報やその後のシーケンスや挙動などを基に判定できる。第2の手法では、パケット送信が無い状態、すなわちパケット送信到着間隔が、例えば1RTTairや05RTTairなどの閾値を超えたら、当該タイミングをウィンドウサイズに基づく一括送信の切れ目と推定する。このように、本発明ではウィンドウサイズ単位で一括送信されるパケット群の切れ目を簡単に推定できるので、第1番目のHTTPREQパケット群の到着時刻tdからn番目最後のHTTPREQパケット群の到着時刻teまでの経過時間tetdを求められるようになる。上式に戻り、右辺分母のRTTsumは、無線エンド側およびサーバエンド側の各固定遅延時間RTTair,RTTsrvの和なので、前記3ウェイハンドシェイクで送受された各制御パケットの到着時刻差から、これらも記通信ログを参照することで算出される。一方、右辺分子のSzn番目までにアップロードされた総データ量から第1番目のアップロードに対応する1パケット分のデータ量を減じた値:ここでは、第2番目のHTTPREQパケットのデータ量に相当についても、上記のように各HTTPREQパケット群の切れ目を推定できれば、第1番目のHTTPREQパケット群のデータ量を簡単に求められるので、これを総データ量から減じるか、あるいは第2番目以降の全てのHTTPREQパケットのデータ量の総和として求められる。なお、以上ではMHから送信されたパケットがキャプチャポイントに到着するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、これをサーバがHTTPREQパケットを受けきるまでとするならば、最後の通信データがキャプチャポイントからサーバへ到着するまでの時間が不足する。したがって、例えば上式の代わりに次式を用いる。Rate=Sz/×RTTsumRTTsrv2...前記第2算出部105bは、通信ログを参照し、以上のようにしてSz、TnおよびRTTsum、さらには必要に応じてRTTsrvを算出すると共に、これらを上式またはに適用することで無線区間のスループットRatebpsを算出する。次いで、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パケットが返信される。このようなシーケンスにおいて、本実施形態でも3ウェイハンドシェイクで送受されるSYNパケット、SYNACKパケットおよびACKパケットがキャプチャされ、それぞれの到着時刻t1,t2,t3が通信ログとして記録される。また、TCPコネクション確立後のコネクションまたはセッション内では、MHから送信されるHTTPREQパケットの到着時刻teのみがキャプチャされる。本実施形態では、このような1RTTセッションについては上式が適用され、右辺分母の代替所用時間Tがtetaとして算出され、サーバエンド側および無線エンド側の各固定遅延時間RTTsrv,RTTair、ならびにRTTair/2が前記と同様に通信ログに基づいて算出され、これらを上式に代入することでTotalTimeが差出される。データ量Mについては、HTTPREQのパケットサイズM1が前記通信ログに基づいて算出され、これとACKのパケットサイズMaとを上式に代入して求める。そして、これらを上式に適用することでスループットRateが算出される。本実施形態によれば、TCPコネクションの確立時に送受される制御パケット、およびTCPコネクション確立後のコネクション内では上りパケットのみをキャプチャするだけで無線区間のスループットを正確に求められるようになる。したがって、一箇所のキャプチャポイントにおいて、一コネクション当たりのキャプチャ対象のパケット数を減ずることができ、その結果、多数のコネクションを監視することが可能になるので、スケーラブルなスループット測定が可能になる。また、HTTPセッションでは、スループット計測をセッション単位でも行えるので、例えばHTTPWEBにおいて、今回のセッションと次回のセッションとの間に無線クライアント側でユーザのThinkTimeが生じても、このThinkTimeが除外された正確なスループット計測が可能になる。次いで、本発明の第2実施形態について説明する。図6は、前記キャプチャ装置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以上のみを計測対象とすると共に、そのセッション時間から前記オーバヘッド時間を減じて所要時間を求めることが望ましい。"