JP2006013920A - 障害解析プログラム、障害解析装置、記録媒体及び障害解析方法 - Google Patents

Abstract

【課題】 クライアントシステムやサーバシステムなどのエンドポイントそのものにおいて、性能障害の原因を正しく解析する。
【解決手段】 通信アプリケーション１１の実行時に送受信パケットを捕獲し（Ｓ１）、往復伝播時間を計測し（Ｓ２）、さらに捕獲した受信パケットを基に送信元の通信ウィンドウサイズを推定する（Ｓ３）。往復伝播時間及び通信ウィンドウサイズからスループットの推定値を算出し（Ｓ４）、スループットの推定値と実測値とを、通信ウィンドウサイズ及び往復伝播時間を含む各種通信パラメータとともに、例えば、ディスプレイ１０ａに提示する（Ｓ５）。これにより、定量的な分析から性能障害の原因を正しく解析可能になる。
【選択図】 図１

Description

本発明は障害解析プログラム、障害解析装置、障害解析プログラムを記録したコンピュータ読み取り可能な記録媒体及び障害解析方法に関し、特にネットワーク上で発生する性能障害の原因を解析する障害解析プログラム、障害解析装置、障害解析プログラムを記録したコンピュータ読み取り可能な記録媒体及び障害解析方法に関する。

ＩＰ（Internet Protocol）を用いたネットワークが社会インフラとして利用されるに伴い、通信ができないなどの機能的な障害だけでなく、応答時間が遅いなどの性能面での障害へも迅速、的確に対応しうる技術が求められている。

ネットワーク上で発生する障害に対しては、従来から、ＴＣＰ（Transmission Control Protocol）／ＩＰにおける代表的なネットワーク管理プロトコルであるＳＮＭＰ（Simple Network Management Protocol）を用いて監視する方法があった。ＳＮＭＰでは、ＭＩＢ（Management Information Base）という情報や、システムが生成発信するシステムメッセージを収集して解析することが行われている。ＭＩＢには、ＩＰパケットの送受信数などのトラヒック情報とともに、パケットロスとなったパケット数などがカウントされているので、これに基づき、ネットワーク機器などの障害を検知する。また、システムメッセージには直接的に各機器が検出した異常状況が記されているので、これにより障害検知を行う。

従来のネットワーク管理システムでは、このような、ＭＩＢやシステムメッセージによって表されている障害情報の収集やトレースを、例えば、システム管理者が起動するネットワーク監視端末（ＳＮＭＰマネージャ）などが集中管理して行う方法をとっている。非特許文献１には、商用のＩＳＰ（Internet Service Provider）のＤＮＳ（Domain Name System）サーバのトラヒック情報を収集して解析するものが報告されている。
加藤，関谷，「ＩＳＰのＤＮＳトラヒックの解析」，電子情報通信学会論文誌 Ｂ，Ｊ８７−Ｂ，Ｎｏ．３，ｐｐ．３２７−３３５，２００４年３月

しかし、ネットワーク規模の増大やネットワーク機器の多様化／機能の高度化に伴い、収集される情報が膨大なものになってきており、パケット個々の送受信記録などの詳細な情報を、集中管理することはその情報量の点で無理があるという問題があった。例えば、前述の非特許文献１ではＤＮＳサーバの収集したパケットの情報は、商用ＩＳＰの場合に０．７ＧＢ／時間となることが報告されている。また、収集した大量の情報から、関連のある情報を選別して的確な分析をすることは特に難しい。このように、集中管理方式での性能障害解析には限界がある。

一方、非集中管理としては、障害が起きた時点で、障害現場にパケットのトレースを行う計測解析装置（Ｓｎｉｆｆｅｒなど）を持ち込み、解析を行う方法もとられている。Ｗｅｂアクセスが遅い、ＩＰ電話の音声品質が悪いなどのように、機能的には正常だが、性能的に問題があるような障害原因を究明するためには、パケットのトレースを行う機能によるひとつひとつのパケット送受信の送受時刻、ステータスなどの詳細トレースを行うことが不可欠である。しかし、従来の計測解析装置では、ロス率など単純な情報が収集できるだけであり、パケットロス以外の要因があってスループットが低下していてもそれを発見しづらく、実際の解析も人が行うので、高いスキルが要求されていた。

本発明はこのような点に鑑みてなされたものであり、クライアントシステムやサーバシステムなどのエンドポイントそのものにおいて、パケットを収集することで詳細な情報を得て、定量的な分析から性能障害の原因を正しく解析可能な障害解析プログラム、障害解析装置、障害解析プログラムを記録したコンピュータ読み取り可能な記録媒体及び障害解析方法を提供することを目的とする。

本発明では上記問題を解決するために、ネットワーク上で発生する性能障害の原因を解析する障害解析プログラムにおいて、図１に示すように、コンピュータ（障害解析装置（クライアントＰＣ）１０と図示している）を、通信アプリケーション１１の実行時の送受信パケットを捕獲するパケット捕獲手段Ｓ１、往復伝播時間を計測する往復伝播時間計測手段Ｓ２、捕獲した受信パケットを基に送信元（例えばサーバ２０）の通信ウィンドウサイズを推定する通信ウィンドウサイズ推定手段Ｓ３、通信ウィンドウサイズ及び往復伝播時間を基にスループットの推定値を算出するスループット推定値算出手段Ｓ４、スループットの推定値とスループットの実測値とを、通信ウィンドウサイズ及び往復伝播時間を含む各種通信パラメータとともに提示する解析結果提示手段Ｓ５、として機能させる障害解析プログラムが提供される。

このような障害解析プログラムをコンピュータに実行させると、通信アプリケーション１１の実行時に送受信パケットを捕獲し、往復伝播時間を計測し、さらに捕獲した受信パケットを基に送信元の通信ウィンドウサイズを推定する。往復伝播時間及び通信ウィンドウサイズからスループットの推定値を算出し、スループットの推定値と実測値とを、通信ウィンドウサイズ及び往復伝播時間を含む各種通信パラメータとともに、例えば、ディスプレイ１０ａに提示する。

本発明は、通信アプリケーションの実行時に送受信パケットを捕獲し、往復伝播時間を計測し、捕獲した受信パケットを基に送信元の通信ウィンドウサイズを推定し、通信ウィンドウサイズ及び往復伝播時間からスループットの推定値を算出し、スループットの推定値と実測値とを、通信ウィンドウサイズ及び往復伝播時間を含む各種通信パラメータとともに提示するので、クライアントシステムやサーバシステムなどのエンドポイントそのものにおいても、定量的な分析から性能障害の原因を正しく解析できる。

以下、本発明の実施の形態を図面を参照して詳細に説明する。
図１は、本発明の障害解析装置の原理を示す図である。
障害解析装置１０は、例えば、クライアントＰＣ（パーソナルコンピュータ）であり、パケット捕獲手段Ｓ１、往復伝播時間計測手段Ｓ２、通信ウィンドウサイズ推定手段Ｓ３、スループット推定値算出手段Ｓ４、解析結果提示手段Ｓ５を有する。

パケット捕獲手段Ｓ１は、ＦＴＰ（File Transfer Protocol）ソフトやＷｅｂなどの通信アプリケーション１１の実行時の送受信パケットを捕獲する。受信パケットは、送信元（以下サーバ２０とする）からネットワーク３０を介して送信されたものである。

往復伝播時間計測手段Ｓ２は、往復伝播時間（ＲＴＴ：Round Trip Time）を計測する。
通信ウィンドウサイズ推定手段Ｓ３は、捕獲した受信パケットを基にサーバ２０の通信ウィンドウサイズ（以下単にウィンドウサイズと称する）を推定する。

図２は、ウィンドウ制御によるパケットの送受信の様子を示す図である。
ウィンドウ制御では、送信側から複数のパケット５１を続けて（例えば１ｍｓｅｃ以下の間隔で）送信する。確認応答のパケット５２の受信を待たずに送信可能なパケット群５３の大きさが、ウィンドウサイズである。また、確認応答のパケット５２はパケット５１を受信したことを送信側に通知するものであるが、送信側ではこの受信に、ＲＴＴ（例えば、１０ｍｓｅｃ以上）だけかかる。

障害解析装置１０のウィンドウサイズは、送信パケットのＴＣＰヘッダ内の情報から獲得できるが、サーバ２０のウィンドウサイズは、障害解析装置１０の通信ウィンドウサイズ推定手段Ｓ３により推定する。詳細は後述するが、通信ウィンドウサイズ推定手段Ｓ３は、サーバ２０のウィンドウサイズを、サーバ２０からの複数の受信パケットの到着累積時間が、図２のようなＲＴＴに等しくなるまでの受信パケットのデータ量の累計から推定する。パケットロスがある場合などについては後述する。

スループット推定値算出手段Ｓ４は、ウィンドウサイズ及びＲＴＴを基にスループットの推定値を算出する。スループットは、障害解析装置１０のウィンドウサイズと、通信ウィンドウサイズ推定手段Ｓ３で推定したサーバ２０のウィンドウサイズのうち小さい方で制限される。そこで、小さい方のウィンドウサイズを用い、スループットの推定値を、スループット推定値＝ウィンドウサイズ／ＲＴＴの式で求める。なお、スループット推定値算出手段Ｓ４は、パケットロスによる影響を補正してスループットの推定値を算出する機能をさらに有している。これについては後述する。

図３は、典型的なＴＣＰのスループットとＲＴＴの関係を示した図である。
縦軸がスループット（推定値）［Ｍｂｐｓ］、横軸がＲＴＴ［ｍｓｅｃ］であり、複数のウィンドウサイズごとのスループットとＲＴＴの関係を示している。この関係からわかるように、ＲＴＴが増大するとともに、スループットは低下する。また、ウィンドウサイズが大きいほどスループットが高くなる。これは、通信エラーを回復するために、一定のウィンドウサイズを保持して送るウィンドウ制御が行われるが、図２のように確認応答を送信元に送るためには、ＲＴＴが必要であり、少なくとも、ＲＴＴの時間内には、ウィンドウサイズ以上の情報は伝搬できないことを示している。ただし、これは理想状態でのスループットの上限を示したものであり、現実には、パケットロスによって、ウィンドウサイズは動的に変化するので（詳細は後述する）、現実のスループットはこれよりも低下する。

解析結果提示手段Ｓ５は、スループット推定値算出手段Ｓ４で得たスループットの推定値と、スループットの実測値（一定時間内に、パケット捕獲手段Ｓ１で捕獲した送受信パケットの情報量から算出可能である）とを、ウィンドウサイズ、ＲＴＴを含む各種通信パラメータとともに、ディスプレイ１０ａに表示してユーザに提示する。

以下障害解析装置１０の動作についてまとめる。
通信アプリケーション１１が実行されると、パケット捕獲手段Ｓ１は送受信パケットを捕獲し、往復伝播時間計測手段Ｓ２は、ＲＴＴを計測する。また、通信ウィンドウサイズ推定手段Ｓ３は、捕獲した受信パケットを基にサーバ２０のウィンドウサイズを推定する。スループット推定値算出手段Ｓ４は、障害解析装置１０のウィンドウサイズと、通信ウィンドウサイズ推定手段Ｓ３で推定したサーバ２０のウィンドウサイズのうち小さい方のウィンドウサイズを用い、スループットの推定値を、スループットの推定値＝ウィンドウサイズ／ＲＴＴの式で求める。スループットの推定値が求まると、解析結果提示手段Ｓ５は、スループットの推定値と、スループットの実測値とを、ウィンドウサイズ、ＲＴＴを含む各種通信パラメータとともに、ディスプレイ１０ａに表示して解析結果をユーザに提示する。

このように、スループットの推定値と、実測値とを、ウィンドウサイズ、ＲＴＴを含む各種通信パラメータとともに、定量的に比較提示することで、パケットロス以外の要因があってスループットが低下していても、その見逃しを防止することができる。

次に本発明の詳細を説明する。
図４は、障害解析装置の構成例を示す図である。
ＴＣＰ／ＩＰ通信では、クライアントシステムやサーバシステム内で、スループットに大きく影響するエンドポイント（プロトコルの終端点）でパケットを捕獲して解析することが必要であるため、Ｗｅｂアクセスを行うクライアントＰＣを障害解析装置１００として機能させた場合について示している。

障害解析装置１００は、解析／制御部１０１と、ユーザインターフェース部１０２と、データ保管部１０３と、通信パラメータ値計測部１０４と、通信処理部１０５と、通信アプリケーション１０６を有している。

解析／制御部１０１は、図１で示したような、スループットの推定値の算出や、パケットロスの影響の補正など、各種の解析及び障害解析装置１００の各部を制御する。解析／制御部１０１は、例えば、ＣＰＵ（Central Processing Unit）である。

ユーザインターフェース部１０２は、マウス１１０、キーボード１１１などによって入力されるユーザからの応答を受信して解析／制御部１０１に通知したり、解析／制御部１０１で生成されたユーザへの指示（性能障害の解析結果なども含む）をＧＵＩ（Graphical User Interface）などにて処理し、ディスプレイ１１２に表示することによってユーザに提示する機能を有している。

データ保管部１０３は、パケットの情報や通信パラメータなどのデータを保管する。データ保管部１０３は、例えば、ハードディスク装置（ＨＤＤ）や、ＲＡＭ（Random Access Memory）である。

通信パラメータ値計測部１０４は、解析／制御部１０１の制御のもとパケットのロス率や、ＲＴＴ、ウィンドウサイズなどの通信パラメータの計測を行う。また、スループットの実測値を求める。

通信処理部１０５は、インターネットや、ＩＰ−ＶＰＮ（Internet Protocol-Virtual Private Network）などのＩＰネットワーク３００と接続する。また、解析／制御部１０１の制御のもと、通信アプリケーション１０６実行時の送受信パケットを捕獲する。また、通信パラメータ値計測部１０４でＲＴＴを計測するために、ＴＣＰ／ＩＰのインターネット層のプロトコルであるＩＣＭＰ（Internet Control Message Protocol）のｐｉｎｇ（Packet InterNet Groper）コマンドを実行してもよい。ただし、ＦＴＰなどの通信アプリケーション１０６の実行時におけるＲＴＴを計測するためには、ＴＣＰの確認要求パケット（以下ＳＹＮパケットと称する）に対する確認応答パケット（以下ＳＹＮＡＣＫパケットと称する）の応答時間を計測してもＲＴＴとほぼ同じ時間を計測することができる。

ＦＴＰなどの通信アプリケーション１０６は、例えば、ＨＤＤなどに格納されており、ユーザからの指示を受けた解析／制御部１０１の制御のもと実行される。
以下、障害解析装置１００の動作を説明する。

例えば、ユーザがマウス１１０やキーボード１１１操作などで、通信アプリケーションを実行する旨の入力を行うと、ユーザインターフェース部１０２にてその情報を受信し、解析／制御部１０１に転送される。そして、指定された通信アプリケーション１０６が、解析／制御部１０１の制御のもと実行される。その通信アプリケーション１０６が、ＩＰネットワーク３００を介してサーバ２００と通信を行うものであるとすると、通信パラメータ値計測部１０４のパケット捕獲要求に対して、通信処理部１０５は、通信アプリケーション１０６の実行中に送信するパケットと受信するパケットとを捕獲する。さらに、捕獲したパケットの情報は、データ保管部１０３で保管されるとともに、パケット捕獲結果として、通信パラメータ値計測部１０４に送られる。

通信パラメータ値計測部１０４は、解析／制御部１０１の計測要求に応じて、捕獲したパケットの情報をもとに各種通信パラメータ値の計測を行う。
ＲＴＴは、前述したように、障害解析装置１００において、ＳＹＮパケットの送出後、これを受信したサーバ２００から即座に送出されるＳＹＮＡＣＫパケットを受信するまでの時間を計測することで得られる。

また、パケットのロス率は、受信方向はパケットのシーケンス番号の抜けの観測、送信方向は再送パケット数の観測により得られる。
ウィンドウサイズは、クライアントＰＣである障害解析装置１００から送信されるパケットのＴＣＰヘッダ内の情報から獲得できる。一方、サーバ２００側のウィンドウサイズは、複数の受信パケットの到着累積時間が、ＲＴＴに等しくなるまでの受信パケットのデータ量の累計から推定する。具体的には、図２のようにウィンドウサイズ分のパケット５１は短い間隔（例えば１ｍｓｅｃ以下）で送信され、ＲＴＴはそれより十分大きいので、パケット間隔がＲＴＴ程度開いた場合に、ウィンドウサイズの区切りと考え、その間の受信パケットのデータ量の累計をウィンドウサイズと推定する（後述の図６参照）。

また、スループットの実測値を、一定時間内に捕獲した送受信パケットの情報量から計測する。
以上のようにして計測した各種通信パラメータは、データ保管部１０３に保管されるとともに、解析／制御部１０１に、計測結果として転送される。解析／制御部１０１は、ウィンドウサイズ及びＲＴＴを基にスループットの推定値を算出する。スループットは、障害解析装置１００のウィンドウサイズと、サーバ２００のウィンドウサイズのうち小さい方で制限される。そこで、小さい方のウィンドウサイズを用い、スループットの推定値を、スループットの推定値＝ウィンドウサイズ／ＲＴＴの式で求める。ただし、ウィンドウサイズは、パケットのロスにより変動するので、これを補正することが必要である。以下、パケットロスの影響を補正する方法について説明する。

ＴＣＰでは、パケットのロスを検出するとウィンドウサイズを小さくし、パケットのロスがないときはＩＰネットワーク３００が空いていると判断し、ウィンドウサイズを大きくするような制御（以下ウィンドウ制御と称する）を行う。これにより転送レートを可変する。詳細は、「西田、“ＴＣＰ詳説”［ｏｎｌｉｎｅ］、Ｉｎｔｅｒｎｅｔ Ｗｅｅｋ ９９ パシフィコ横浜、１９９９年１２月１４日、［２００４年６月１７日検索］、インターネット＜URL: http://www.nic.ad.jp/ja/materials/iw/1999/notes/C3.PDF＞」で説明されているが、ウィンドウサイズの制御アルゴリズムには、以下のように、代表的な２つのアルゴリズムが存在する。

図５は、ウィンドウサイズの制御アルゴリズムの例であり、（Ａ）がＴａｈｏｅのアルゴリズム、（Ｂ）がＲｅｎｏ，ＮｅｗＲｅｎｏのアルゴリズムである。
いずれも縦軸がウィンドウサイズで、横軸が時間である。ウィンドウサイズの制御のしかたは、スロースタート段階Ｆ１と、輻輳回避段階Ｆ２とに分かれており、各通信段階によって増加量は異なる。すなわち、スロースタート段階Ｆ１では、ＳＹＮＡＣＫパケットを受け取るたびに指数的に増加し、輻輳回避段階Ｆ２では、ＳＹＮＡＣＫパケットを受け取るたびに線形的に増加する。図５（Ａ）のＴａｈｏｅのアルゴリズムでは、パケットロスの発生を検出すると、ウィンドウサイズを１に下げる。一方の図５（Ｂ）のＲｅｎｏ，ＮｅｗＲｅｎｏのアルゴリズムでは、パケットロスの発生を検出すると、ウィンドウサイズを直前の１／２に下げる。

以上のようなロスによるウィンドウサイズの動的制御の影響を考慮して、障害解析装置１００は、受信パケットの捕獲結果からサーバ２００のウィンドウサイズを推定する。
図６は、受信パケットの流れとパケット間隔との関係を示す図である。

縦軸がパケット間隔（ｍｓｅｃ）で、横軸がパケットのシーケンス番号である。
パケット間隔が長い、例えば、１０ｍｓｅｃ以上となるパケットを、障害解析装置１００から送信されるＡｃｋパケット（パケットを受信したことをサーバ２００に通知するパケット）の到着を待ってサーバ２００から送出されるＡｃｋ待ちパケット（間隔がほぼＲＴＴとなるパケット）５０１と推定する。そして、Ａｃｋ待ちパケット間のパケットデータサイズ和をサーバ２００のウィンドウサイズと推定する。パケットのロスが無い場合のウィンドウサイズが最大となるが（図の“８１９２”ｂｙｔｅ）、パケットのロスが発生すると、図５のようにウィンドウサイズは小さくなる。よって、図６のウィンドウサイズの平均値として、ロスを考慮したウィンドウサイズを推定できる。また、図６のような受信パケットの捕獲結果から推定された最大ウィンドウサイズと、通信パラメータ値計測部１０４で計測したロス率と、図５で示したようなウィンドウサイズの制御アルゴリズムを参照して、ロスを考慮したウィンドウサイズを推定してもよい。

ロスによるウィンドウサイズの補正は、以下のような方法によっても可能である。
図７は、受信パケットの間隔とパケット分布数との関係を示す図である。
縦軸がパケット分布数で、横軸がパケット間隔［ｍｓｅｃ］である。

まず、計測したＲＴＴから、パケット間隔の違いによってパケット分布を３つのグループＧ１、Ｇ２、Ｇ３にグループ分けする。グループＧ１は、パケット間隔が０〜ＲＴＴ（１−α）のパケット群であり、これらは短い間隔で受信されるパケット群である。グループＧ２は、パケット間隔がＲＴＴ（１−α）〜ＲＴＴ（１＋α）のパケット群であり、パケット間隔がＲＴＴに近いパケット群（Ａｃｋ待ちパケットと推定されるパケット群）である。グループＧ３は、パケット間隔がＲＴＴ（１＋α）以上のパケット群であり、再送遅延などの影響で長い間隔で受信されるパケット群である。なお、αは、パケット間隔の分散（ゆらぎ）を考慮するためのもので、例えば、０．２〜０．５程度の値である。ウィンドウサイズは、ウィンドウサイズ＝１パケットの平均データサイズ／全体におけるグループＧ２の割合、という式で推定できる。

以上のように、ロスの影響を考慮したウィンドウサイズを用いて、障害解析装置１００の解析／制御部１０１は、スループットの推定値を求めることができる。
ところで、ロスの発生が再送を要求するＡｃｋパケットによってわからない場合がある。このような場合、一般的に３秒程度の転送できない時間である再送遅延時間（以下再送タイムアウト時間（ＲＴＯ：Retransmission Time Out）と称する）が存在する。ＲＴＯが発生する原因は、以下の２つの場合に分けられる。

図８は、パケットのロスによってＲＴＯが発生する例を示す図であり、（Ａ）は再送パケットが再びロスした場合、（Ｂ）はウィンドウサイズのデータのうち最後のパケットがロスした場合の例である。

図８（Ａ）のように、例えば、“４”というパケット５０２がロスした場合、受信側からその旨を受けると送信側は“４”の再送パケット５０３を送信しなおす。しかし、これが再びロスすると、送信側は、ＲＴＯ経過後、再度、再送パケット５０３を送信する。このようなパケット５０２の推定個数は、以下の式で表される。

推定個数＝データサイズ／平均セグメントサイズ×ロス率²……（１）
データサイズは受信パケットの全データサイズであり、平均セグメントサイズは、１つのパケットの平均のデータサイズである。ロス率は、前述した通信パラメータ値計測部１０４で計測されたものを用いる。

一方、図８（Ｂ）のように、ウィンドウサイズのデータのうち最後のパケット５０４がロスした場合、送信側では、ＲＴＯ経過後、再送パケット５０５を送信する。このような再送パケット５０５の推定個数は、以下の式で表される。

推定個数＝データサイズ／平均セグメントサイズ×平均セグメントサイズ／推定したウィンドウサイズ×ロス率……（２）
上式で、推定したウィンドウサイズは、前述の図６、図７で推定したウィンドウサイズを用いる。

この２つの場合を考慮して、障害解析装置１００の解析／制御部１０１は、スループットの推定値を算出する。
スループットの推定値は、以下の式で表される。

スループットの推定値＝データサイズ／（ＲＴＴ遅延の総和＋ＲＴＯ遅延の総和）……（３）
ここで、ＲＴＴ遅延の総和は、パケット間隔がＲＴＴ程度のパケットの個数×ＲＴＴで与えられる。パケット間隔がＲＴＴ程度のパケットは、図６ではパケット５０１、図７ではグループＧ２に属するパケットに相当し、データサイズ／推定したウィンドウサイズ、で与えられる。

また、式（３）のＲＴＯ遅延の総和は、図８で示したようなＲＴＯ遅延の原因となるパケットの個数×ＲＴＯ平均遅延時間、という式によって算出される。ＲＴＯ遅延の原因となるパケットの個数は、前述の式（１）と式（２）の和によって与えられる。ＲＴＯ平均遅延時間は、例えば、ＲＴＴ×ロス率×β、で与えられることが考えられる。ここでβは経験則により与えられる値である。

以上のように、障害解析装置１００の解析／制御部１０１では、パケットロスの影響を補正してスループットの推定値を算出することができる。
最後に、解析／制御部１０１の制御のもと、ユーザインターフェース部１０２にて、スループットの推定値とスループットの実測値とを、ロス率、ウィンドウサイズ及びＲＴＴなどの各種通信パラメータとともに障害解析結果としてディスプレイ１１２に表示して、ユーザに提示する。

図９は、障害解析画面の例である。
障害解析画面は、パケットの捕獲（キャプチャ）を開始するためのキャプチャ開始ボタン５１０を有している。ユーザは、ある通信アプリケーション１０６の実行時、キャプチャ時間などを指定してキャプチャ開始ボタン５１０をマウス１１０などにより、画面上で選択することにより、障害解析処理を開始させることができる。解析結果は通信する相手先ごとに得られる。この図の例では、サーバアドレス“１０．２５．１４４．１７３”のサーバ２００のポート“２０”と、クライアントアドレス“１０．２５．１４４．１２１”のクライアントＰＣ（障害解析装置）１００のポート“２１４９”が選択されていることを示している。解析結果は、データ保管部１０３から取り出されて表示される。例えば、通信パラメータの計測結果として、通信時間、データの送信量、受信量、速度、クライアントＰＣ１００からサーバ２００へのデータ送信の際の上りロス率、サーバ２００からクライアントＰＣ１００へのデータ送信の際の下りロス率が表示される。

また、前述した解析／制御部１０１の処理によって算出したスループットの推定値（図ではモデル値と表記している）と実測値を、ＴＣＰヘッダの情報から得られるクライアントＰＣ１００のウィンドウサイズ（図ではＲＷＩＮ最大値と表記している）と、推定したサーバ２００のウィンドウサイズ（図では推定ＳＷＩＮと表記している）と、ＲＴＴとロス率とともに表示している。なお、ここではサーバ２００からクライアントＰＣ１００へのデータ送信の際のスループットを計測しているが、その反対のスループットも計測できる。また、図９のように、スループット診断結果としてその旨を表示するようにしてもよい。ここでは、サーバ２００からクライアントＰＣ１００へのデータ送信の際のスループットが低いことを提示している。そしてそれが、送信平均ウィンドウサイズ（推定ＳＷＩＮ）が小さいことに起因していると表示している。また、クライアント側のＲＷＩＮ最大値は適切であり、ロス率は５．３％と、高いということを表示している。

なお、図９のように、通信パラメータを変化させてモデル値をシミュレーションできるようにしてもよい。通信パラメータを入力後、再計算ボタン５１１を押すことで、モデル値が、解析／制御部１０１の制御のもと再計算され表示される。また、推定伝送路速度を入力するようにして、モデル値が、推定伝送路速度を超えるような場合には、その速度に制限するようにしてもよい。これにより利用者は、パケットのロス率などを改善するとどのようなスループットが期待できるかを計測結果も交えて推測することができ、性能障害を修復する計画立案の支援ができる。

以上のように、スループットの推定値と、実測値とを比較提示することで、実際のシステムが正常な通信プロトコルに従って動作し、その結果として性能低下を起こしているかが判別できることになる。つまり、パケットロスが大きいとそのためにスループットは低下するが、これを定量的に推定できるので、因果関係を定量的に把握できる。従来は、パケットロスなどの計測結果を絶対的な尺度（例えば、１％以上ならば、何らかの障害があるとの判定尺度）で判断していたが、これでは、パケットロス以外の要因があって、スループットが低下していても、これを見逃すことになる。本発明では、定量的に実測値と、推定値とを比較するので、このような見逃しの可能性を低減することができる。

なお、上記の処理内容は、コンピュータによって実現することができる。その場合、障害解析装置１００が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、性能障害発生時または適宜、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

以上、本発明を実施例に基づいて説明したが、本発明は上記に限定されるものではなく、特許請求の範囲に記載の範囲内で様々な変形が可能である。

本発明の障害解析装置の原理を示す図である。 ウィンドウ制御によるパケットの送受信の様子を示す図である。 典型的なＴＣＰのスループットとＲＴＴの関係を示した図である。 障害解析装置の構成例を示す図である。 ウィンドウサイズの制御アルゴリズムの例であり、（Ａ）がＴａｈｏｅのアルゴリズム、（Ｂ）がＲｅｎｏ，ＮｅｗＲｅｎｏのアルゴリズムである。 受信パケットの流れとパケット間隔との関係を示す図である。 受信パケットの間隔とパケット分布数との関係を示す図である。 パケットのロスによってＲＴＯが発生する例を示す図であり、（Ａ）は再送パケットが再びロスした場合、（Ｂ）はウィンドウサイズのデータのうち最後のパケットがロスした場合の例である。 障害解析画面の例である。

符号の説明

１０ 障害解析装置（クライアントＰＣ）
１０ａ ディスプレイ
１１ 通信アプリケーション
２０ サーバ
３０ ネットワーク
Ｓ１ パケット捕獲手段
Ｓ２ 往復伝搬時間計測手段
Ｓ３ 通信ウィンドウサイズ推定手段
Ｓ４ スループット推定値算出手段
Ｓ５ 解析結果提示手段

Claims (10)

1. ネットワーク上で発生する性能障害の原因を解析する処理をコンピュータに機能させる障害解析プログラムにおいて、
   コンピュータを、
   通信アプリケーション実行時の送受信パケットを捕獲するパケット捕獲手段、
   往復伝播時間を計測する往復伝播時間計測手段、
   捕獲した受信パケットを基に送信元の通信ウィンドウサイズを推定する通信ウィンドウサイズ推定手段、
   前記通信ウィンドウサイズ及び前記往復伝播時間を基にスループットの推定値を算出するスループット推定値算出手段、
   前記推定値と前記スループットの実測値とを、前記通信ウィンドウサイズ及び前記往復伝播時間を含む各種通信パラメータとともに提示する解析結果提示手段、
   として機能させる障害解析プログラム。
2. 前記通信ウィンドウサイズ推定手段は、前記通信ウィンドウサイズを、複数の前記受信パケットの到着累積時間が前記往復伝播時間に等しくなるまでの前記受信パケットのデータ量の累計から推定することを特徴とする請求項１記載の障害解析プログラム。
3. 前記スループット推定値算出手段は、パケットロスによる影響を補正して前記スループットの推定値を算出することを特徴とする請求項１記載の障害解析プログラム。
4. 捕獲した前記受信パケットのうちパケット間隔が前記往復伝搬時間付近の前記受信パケットの割合と、１パケットの平均データサイズとを基に、前記通信ウィンドウサイズを推定することを特徴とする請求項１記載の障害解析プログラム。
5. 前記往復伝搬時間による往復伝搬遅延と、パケットロスにより生じる再送遅延とを推定し、前記往復伝搬遅延及び前記再送遅延の総和をもとに、前記スループットの前記推定値を算出することを特徴とする請求項１記載の障害解析プログラム。
6. 前記再送遅延の総和は、パケットのロス率の２乗に比例する通信途中にロスする可能性のある再送パケットの推定個数と、前記ロス率に比例する前記通信ウィンドウサイズのデータのうち、ロスする可能性のある最後の前記受信パケットの推定個数との和に、平均の再送遅延時間を乗じた時間であることを特徴とする請求項５記載の障害解析プログラム。
7. 計測した前記各種通信パラメータを可変させ、前記スループットの前記推定値を再計算することを特徴とする請求項１記載の障害解析プログラム。
8. ネットワーク上で発生する性能障害の原因を解析する障害解析装置において、
   通信アプリケーション実行時の送受信パケットを捕獲するパケット捕獲手段と、
   往復伝播時間を計測する往復伝播時間計測手段と、
   捕獲した受信パケットを基に送信元の通信ウィンドウサイズを推定する通信ウィンドウサイズ推定手段と、
   前記通信ウィンドウサイズ及び前記往復伝播時間を基にスループットの推定値を算出するスループット推定値算出手段と、
   前記推定値と前記スループットの実測値とを、通信ウィンドウサイズ及び前記往復伝播時間を含む各種通信パラメータとともに提示する解析結果提示手段と、
   を有することを特徴とする障害解析装置。
9. ネットワーク上で発生する性能障害の原因を解析する処理をコンピュータに機能させる障害解析プログラムを記録したコンピュータ読み取り可能な記録媒体において、
   コンピュータを、
   通信アプリケーション実行時の送受信パケットを捕獲するパケット捕獲手段、
   往復伝播時間を計測する往復伝播時間計測手段、
   捕獲した受信パケットを基に送信元の通信ウィンドウサイズを推定する通信ウィンドウサイズ推定手段、
   前記通信ウィンドウサイズ及び前記往復伝播時間を基にスループットの推定値を算出するスループット推定値算出手段、
   前記推定値と前記スループットの実測値とを、前記通信ウィンドウサイズ及び前記往復伝播時間を含む各種通信パラメータとともに提示する解析結果提示手段、
   として機能させる障害解析プログラムを記録したコンピュータ読み取り可能な記録媒体。
10. ネットワーク上で発生する性能障害の原因を解析する処理をコンピュータが行う障害解析方法であって、
    コンピュータが、
    通信アプリケーション実行時の送受信パケットを捕獲するパケット捕獲ステップと、
    往復伝播時間を計測する往復伝播時間計測ステップと、
    捕獲した受信パケットを基に送信元の通信ウィンドウサイズを推定する通信ウィンドウサイズ推定ステップと、
    前記通信ウィンドウサイズ及び前記往復伝播時間を基にスループットの推定値を算出するスループット推定値算出ステップと、
    前記推定値と前記スループットの実測値とを、前記通信ウィンドウサイズ及び前記往復伝播時間を含む各種通信パラメータとともに提示する解析結果提示ステップと、
    を実行することを特徴とする障害解析方法。

Images