JP2008141777A - Ｔｃｐ接続における制限因子の自動検出 - Google Patents

Abstract

【課題】ＴＣＰ関連の問題を検出し、および診断するための方法およびシステムを提供する。
【解決手段】本方法は、ＴＣＰ送信装置からネットワーク経路を介して送信されてＴＣＰ受信装置において受信されたＴＣＰパケットの時間及び順序に従って、再送タイムアウトが何回発生したかを検出することと、上記再送タイムアウトの発生回数が予め決められたしきい値を超過したとき、上記ネットワーク経路によって第１の性能問題が生じたことを表示することとを含む。
【選択図】図１

Description

本発明は、伝送制御プロトコル（ＴＣＰ）パフォーマンス問題状況の診断に関する。

ＴＣＰは、最も広く用いられているトランスポートプロトコルの１つである。ＴＣＰは、インターネットおよび多くのイントラネットの双方で用いられ、ＮＦＳ（ネットワークファイルシステム）データのみならず、ＨＴＴＰ（ハイパーテキスト転送プロトコル）およびＣＩＦＴＳ（共通インターネットファイルシステム）トラフィックにも用いられている。ＴＣＰは、様々なネットワーク上で、また、様々な速度で、信頼性のあるコネクション型通信を実現する強力なプロトコルであるが、以下の理由により、データ転送の測定レートが予想を下回る場合がある。（１）データパケット受信装置、もしくはデータパケット送信装置、もしくはその両方が、不十分に構成され、またはオーバーロードに陥っている、（２）ネットワークもしくはその一部が、十分な帯域幅を有していない（例えば、フリンジ上でギガビットレートで実行するネットワークでは、データ送信装置とデータ受信装置との間の経路のどこかにメガビットリンクを含むことがある）、（３）（輻輳もしくは他の理由で）複数のデータパケットの損失が起こり、粗い粒度（細分性）での再送タイムアウトが要求される、もしくは、（４）他の関連する原因。

ほとんどのＴＣＰの実装は、問題を容易にデバッグするようには設計されていないため、ＴＣＰ関連問題の診断には、様々な技術が設計されおよび実装されて来た。第１の技術は、バークリーパケットフィルター（Ｂｅｒｋｅｌｅｙ Ｐａｃｋｅｔ Ｆｉｌｔｅｒｓ）等の何らかのタイプのパケットキャプチャメカニズムと、キャプチャした低レベルのパケットトレースに対する手動のエキスパート分析とを用いて、異常なプロトコルの振舞いを隔離し、それをネットワーク経路内における構成上の障害がある要素もしくは過負荷の要素まで追跡することを含む。この技術により特定の通信の分析は可能となるが、どちらかと言えば、不便であり、高価な上にエラーが生じがちである。この技術の変形は、ＬＢＬ研究者により開発された、ティーシーパナリー（ｔｃｐａｎａｌｙ）と呼ばれるツール内に実装されている。ティーシーパナリー（Ｔｃｐａｎａｌｙ）は、パケットフィルタトレースを用いるＴＣＰの動作のパケットトレースを点検することにより、自動的にＴＣＰの実装の振舞いを分析する。トレースが、ＴＣＰの仕様に矛盾することが判明すると、ティーシーパナリー（ｔｃｐａｎａｌｙ）は、どの特定の動作が異常なのか、（可能ならば）診断し、もしくは指摘することになる。他のパケット駆動システムと同様に、ティーシーパナリー（ｔｃｐａｎａｌｙ）は、ネットワークの一般的な動的振舞いに注目するのではなく、輻輳制御を実行し、様々な形式のパケットの損失を扱う間、コーナー状態を処理するよう、むしろパケットフィルタの測定誤差、およびＴＣＰアルゴリズムの他の低レベルの詳細を検出することに注目している。
特開平１１−２７３０８号公報。 特表平９−５０９９２７号公報。 Ｗ．リチャード・スティーヴンス，詳解ＴＣＰ／ＩＰ Ｖｏｌ．１ ［新装版］ プロトコル，株式会社ピアソン・エデュケーション，２０００年１２月２０日。

市販のパケットスニファシステムなどの他の技術は、ユニックス（ＵＮＩＸ）（登録商標）のネットスタット（ｎｅｔｓｔａｔ）コマンドにより報告される種類の、集約されたＴＣＰ統計情報を分析するロジックを含んでいる；あいにく、他の同様のこうした技術は、概して、システムがそれまでに体験した総接続の広域分析に制限される。このように、これらは２つのシステム間の特定の接続の特定の障害を検出したり、もしくは診断したりするのに役立つ手段ではない。

従って、ＴＣＰ関連の問題を検出し、および診断するための方法およびシステムを提供することが望まれている。この方法は、自動診断ロジックを含む機器システムが、ネットワークと接続可能で、ＴＣＰのための自動診断技術を実装可能な、本発明の実施例で達成される。

本発明は、ＴＣＰプロトコルの動的動作での、パフォーマンスの障害を検出し、および分析するための方法およびシステムを提供する。好ましい実施例では、本発明は自動診断ロジックを含み、このような自動診断ロジックは、ＴＣＰ受信装置、ＴＣＰ送信装置、もしくは双方に接続される何らかの機器の形態の自動診断モジュールにおけるさまざまなオペレーティングシステム（データオンタップ（Ｄａｔａ ＯＮＴＡＰ）など）のいずれにおいても実装可能である。

本発明の第１の態様では、ＴＣＰイベントがサンプルされ、これらのイベントにおいて注意深く維持された統計値の組が維持される。サンプリングの粒度およびサンプルされる期間は、特定のシステムの必要条件を満たすよう調整されてもよい。これらの統計値は、送信装置側または受信装置側のいずれか、もしくはその両方における障害を診断する際に用いることが出来る。

受信装置側のＴＣＰ診断技術は、（１）送信装置の再送タイムアウトを検出すること、（２）受信されるパケットの平均サイズを評価すること、（３）受信装置が、計算もしくはプロトコルのボトルネックとして作用しないと決定すること、および（４）着信したデータストリームについての他の統計学的評価を実行することを含んでいる。

送信装置側の診断技術は、（１）過度の伝送タイムアウトにフラグを立てること、（２）伝送されるパケットの平均サイズをモニターすること、（３）広告ウィンドウが、受信装置システムと送信装置システムを接続するネットワークの遅延帯域積に対して十分に大きいか否かを評価すること、（４）様々なボトルネックチェックを実行すること、および、（５）送出されるデータストリームについての他の統計学的評価を行うことを含んでいる。

本発明の第２の態様では、クライアントシステムの既知の属性を含むデータベースを用いて、自動診断の結果が集約される。属性の例には、ＩＰサブネット番号、ＯＳタイプ／バージョン、最新の構成変更日付、遅延距離、ルート情報、バーチャルＬＡＮ情報、自動診断情報の履歴の概要、および、自動診断情報の集約に役立ち得る他の属性が含まれる。共通問題領域および共通属性を伴うクライアントシステムは、システム管理者への提示のために一緒にグループ化される。

好ましい実施例では、ＴＣＰ自動診断ロジックは、オンラインもしくはオフラインで実行可能である。この自動診断ロジックは、どんな合理的実装に対しても、比較的非破壊的であるが、この特徴により、例えば、演算リソースへの総需要が比較的小さい場合には、非臨界時にシステム分析が実行可能となる。

以下の説明では、好ましい処理ステップとデータ構造を伴う、本発明の好ましい実施例が説明されている。しかし、当業者は、この出願の熟読後に、本発明の実施例が、プログラム制御下で作動する１台以上の汎用プロセッサ（もしくは、特定の処理ステップとデータ構造に順応した専用プロセッサ）を用いて実行可能であり、さらに、こうした設備を用いる、本願明細書内で説明される好ましい処理ステップおよびデータ構造の実現が、過度の実験、あるいはさらなる発明を要しないことを認識するだろう。

システム要素
図１は、ＴＣＰ接続内の制限因子自動検出システムのブロック図を示している。

システム１００は、通信ネットワーク１３０と接続される、複数のＴＣＰ受信装置１１０およびＴＣＰ送信装置１２０を含んでいる。ＴＣＰ送信装置１１０もしくはＴＣＰ受信装置１２０のうちの少なくとも１つは、オペレーティングシステム１４０と自動診断モジュール１５０とを含んでいる。

ＴＣＰ受信装置１１０およびＴＣＰ送信装置１２０は、クライアントワークステーション、もしくはサーバ、もしくは一般化されたチューリングパラダイム内に包含される他の情報機器などの、汎用コンピュータを含んでいてもよい。これらの装置は、ＴＣＰ受信装置１１０もしくはＴＣＰ送信装置１２０として分類されるが、この区別は一方の装置と他方の装置との関係に基づくものである。特定のデータパケット用のＴＣＰ受信装置１１０として特徴付けられた装置が、他のデータパケット用のＴＣＰ送信装置１２０として特徴付けられることもある。

通信ネットワーク１３０は、データ通信のために、ＴＣＰ受信装置１１０とＴＣＰ送信装置１２０の間に配置される。好ましい実施例では、通信ネットワーク１３０は、インターネットなどのパケット交換ネットワークを含むとともに、追加または代替として、イントラネット、企業ネットワーク、エクストラネット、仮想専用線ネットワークまたは仮想交換ネットワークを含んでいる。代替的実施例では、通信ネットワーク１３０は、ＴＣＰ受信装置１１０およびＴＣＰ送信装置１２０を接続する、他のいかなる通信リンクの組をも含んでいてもよい。

自動診断モジュール１５０は、オペレーティングシステム１４０（好ましくはデータオンタップ（Ｄａｔａ ＯＮＴＡＰ））と結合され得るソフトウェアインストラクションのセット１５５を含んでいる。他の実施例では、自動診断モジュール１５０は、ＴＣＰ受信装置１１０またはＴＣＰ送信装置１２０のいずれか一方、もしくはその両方と接続可能な、別個の機器の形を取ってもよい。これらのソフトウェアインストラクション１５５は、ＴＣＰ受信装置１１０およびＴＣＰ送信装置の双方上の、問題となる状態を診断するロジック技術を含んでいる。これらのロジック技術に加えて、ソフトウェアインストラクション１５５は、さらに以下を含んでいる。（１）（以下に説明される）様々な決定手順を実行するインストラクション。（２）特定の問題となる状態を改善するインストラクション、および（３）システム管理者に提示するための情報を集約するインストラクション。

ＴＣＰ受信装置１１０側で実行可能なソフトウェアインストラクション１５５は、以下を含む：

ＴＣＰ送信装置１２０再送タイムアウトを検出し、および評価するインストラクション
インストラクションセット１５５は、ＴＣＰ送信装置１２０で起こる再送タイムアウトを評価する。インストラクションセット１５５は、ＴＣＰ再アセンブリ待ち行列に挿入される各受信パケットに、タグ付けをするインストラクションを含んでいる。インストラクションが、（１）データパケットが各ＴＣＰ受信装置１１０上に到達する時間、および（２）データパケットが到達するシーケンス番号、の双方を評価するので、「バースト」トラフィックにおける沈黙期間と、再送タイムアウトとを区別することが可能である。特定のパケット間到着ギャップ（通常５００ｍｓ）を伴う、順序が前後した多数のパケットの存在は、ＴＣＰ送信装置で再送タイムアウトが起こったことを示している。

平均パケットサイズ
インストラクションセット１５５は、ＴＣＰ送信装置１２０が十分大きなフレームを用いているか否かを判定するため、着信したデータパケットのサイズを測定し、着信パケットの到達時間を測定するインストラクションを含んでいる。インストラクションセット１５５は、連続した複数のパケット（back-to-back packets）のバーストの一部であるそれらの着信パケットのサイズを決定することにより、小さなＴＣＰパケットを用いて必須のものとして伝送される制御情報等の情報や、またはメタデータに対して混乱をもたらすことを回避する。この決定は、バーストの一部でない着信パケットには実行されない。平均パケットサイズが不適当に小さいような場合（これは、アプリケーションが不十分に書かれていたり、もしくは、ネットワークに構成上の障害があるような場合に起こる）では、インストラクションセット１５５が、修復ステップに提供されてもよい。

ボトルネックチェック
インストラクションセット１５５は、ＴＣＰ受信装置１１０が、データ転送でボトルネックを生成するか否か判定する、インストラクションの３つの関連するサブセットを含んでいる。第１のインストラクションサブセットは、ＴＣＰ受信装置１１０に接続したバッファ内の、利用可能な空きスペース量をモニターすることを伴う。第２のインストラクションサブセットは、プロトコル処理に利用される受信装置ＣＰＵの量をモニターすること、および、ＴＣＰ処理で費やされるＣＰＵサイクルの量と、アイドルタイムとして残された量とを比較することを伴う。第３のインストラクションサブセットは、受信装置アプリケーションが、ＴＣＰソケット受信装置バッファから読み出すレートをモニターすることを伴う。（１）所定量にわたる空きスペースの収縮を実質的に伴うことなく、パケットがおおよそ一定レートで連続的に到達する場合、（２）ＴＣＰ受信装置１１０が、プロトコル処理実行のためにＣＰＵサイクルを消費し尽くしているのではない場合、あるいは（３）受信装置アプリケーションがバッファから読み出すレートが、所定の閾値を下回らない場合、ＴＣＰ受信装置１１０は、計算もしくはプロトコルのボトルネックとして作用している可能性は低い。

ＴＣＰ送信装置１２０側で実行可能なソフトウェアインストラクション１５５は、以下を含む：

過度の再送タイムアウトにフラグを立てること
インストラクションセット１５５は、（１）いつ粗い粒度の再送タイマが満了してパケットが再送されるかを判定するインストラクション、（２）任意のＴＣＰ接続における再送タイムアウトの数が、特定の所定閾値を超えるか否かを判定するインストラクション、および、（３）この閾値が超過された場合にシステムマネージャに通知するインストラクションを含んでいる。

平均パケットサイズ
インストラクションセット１５５は、ＴＣＰ送信装置１２０により送られる伝送データパケットの平均サイズをモニターするインストラクションを含んでいる。ＴＣＰ受信装置１１０上で実行されるパケットサイズのモニタリングと同様に、平均パケットサイズの分析を、連続したパケット列に含まれているパケットに制限することにより、制御情報を運ぶ小さなパケットのようなデータを歪める多くの要因を排除する。

受信装置ウィンドウモニタリング
ＴＣＰ送信装置１２０上のインストラクションセット１５５は、ＴＣＰ受信装置１１０によって広告されるウィンドウをモニターする。特定のインストラクションは、広告ウィンドウが送信装置および受信装置間の経路の遅延帯域積に対して十分に大きいか否かを、ＴＣＰ送信装置１２０にチェックさせる。また、インストラクションセット１５５は、経時的なＴＣＰ受信装置の広告ウィンドウの変化のモニタリングを制御する。広告ウィンドウが比較的一定のまま変化しない場合、ＴＣＰ受信装置１１０がボトルネックとして作用している可能性は低い。

ボトルネックチェック
ＴＣＰ受信装置１１０と同様に、インストラクションセット１５５は、ＴＣＰ送信装置１２０が、計算的もしくはプロトコルのボトルネックでないことを保証するよう、様々なインストラクションサブセットを含んでいる。第１のインストラクションサブセットは、ＴＣＰ送信装置１２０に接続されるバッファサイズと、ＴＣＰ送信装置１２０およびＴＣＰ受信装置１１０間のネットワーク経路の完全な帯域幅とを比較することを伴っている。バッファサイズが適切で、後述のような他の指示情報が存在しない場合は、ＴＣＰ送信装置がボトルネックとして作用している可能性は低い。第２のインストラクションサブセットは、送信バッファ装置にキューイングされた未送信のデータをモニターすることを伴っている。ＴＣＰ送信装置１２０が何も送ることが出来ない期間がある場合、ＴＣＰ送信装置１２０は、ボトルネックとして作用している可能性がある。最後に、第３インストラクションサブセットは、ＴＣＰ送信装置１２０が、ＴＣＰ受信装置１１０のデータ消費ペースを維持するよう、プロトコル処理を十分速く実行可能か否かをモニターする。プロトコル処理がＴＣＰ受信装置１１０に対して低速度で実行される場合、ＴＣＰ送信装置はボトルネックとして作用している可能性がある。

様々な決定手順を実行するインストラクションは、周期的なＩＣＭＰ（インターネット制御メッセージプロトコル）ｐｉｎｇを用いてラウンドリップ時間を測定し、ＴＣＰのフィンガープリンティング（TCP fingerprinting）を使用し、帯域幅、ＭＴＵサイズ、およびＲＴＯ推定に関する様々な仮定をおくことにより、オフライン遅延計算値を測定することを含んでいる。これらの様々な決定手順は、上述された他のタイプのインストラクションの実行に用いられてもよい。

また、ソフトウェアインストラクション１５５に加えて、自動診断モジュールは、データベース１５７を含んでいる。データベース１５７は、ＩＰサブネット番号、ＯＳタイプ／バージョン、最新の構成変更日付、遅延距離、ルート情報、バーチャルＬＡＮ情報、自動診断情報の履歴の概要、および、診断情報を集約してシステム管理者にそれを提示する場合に役に立ち得るような他の属性など、既知のクライアントシステムの様々な属性を記述する、一連のフィールド１５８を含んでいる。この一連のフィールド１５８内に含まれる各フィールドには、適切な重み付けが割り当てられる。この加重された値は、自動診断結果を集約する時に用いられる。

図２Ａおよび図２Ｂは、ＴＣＰ受信装置での制限因子自動検出方法の、処理フローチャートを示している。

方法２００の自動診断は、自動診断モジュール１５０がＴＣＰ受信装置１１０側と接続されている、システム１００の実施例によって実行される。自動診断方法２００は逐次的な一連のステップとして説明されているが、方法２００のステップは、複数の構成要素によって共にもしくは並列に、非同期式でも、パイプライン方式でも、もしくは他の方式でも実行可能である。方法２００は、特に断りのない限り、本明細書及び図面にステップを列挙した順序と同じ順序で実行されなければならないという特別な要件はない。

フローポイント２０５では、システム１００は、ＴＣＰ受信装置１１０で自動診断を始める準備ができている。

ステップ２１０で、１組のイベント統計が定義される。１組のイベント統計の定義は、どんなイベントがモニターされ、そのイベントをモニターするためにどのような時間粒度が用いられるかを決定する。好ましい実施例では、自動診断を特定のシステムに合わせて調節するように特定イベントと特定粒度を識別することが可能である。

ステップ２１５では、ＴＣＰ再アセンブリ待ち行列に挿入される着信パケットは、パケットがＴＣＰ受信装置１１０に到達した時間、および、パケットが到着した順序に関してタグ付けされる。

ステップ２２０では、タグは、順序が前後して受信されたパケットを識別するために評価される。あるパケットが本来の順序とは異なる順序で到達したと識別され、パケット間到達時間が閾値を超えている場合、ＴＣＰ送信装置１２０の再送タイムアウトを示すイベントのフラグが立てられる。過度の数のこうした再送タイムアウトは、送信装置と受信装置との間のネットワーク経路の何らかの問題による、パフォーマンス上の問題を示すもの考えられ、システム管理者に報告されてもよい。可能なら、修復手順が管理者に提示されてもよく、もしくは実行されてもよい。

ステップ２２５では、特定のタイムフレーム内に到達する特定セットのパケットは、（１）セット内のどのパケットも、小さなパケットの使用を必要とする制御情報、メタデータ、もしくは他のタイプのデータを含まず、かつ、（２）セット内のすべてのパケットがデータパケットの同一バーストの一部であるものとして、識別される。「バースト」は、ＴＣＰ送信装置により連続して伝送されるパケットにてなるセットと定義される。

ステップ２３０では、ステップ２２５で識別されたパケットのセット内に含まれたパケットの平均サイズが計算される。セット内のパケットの所定数が不適当に小さい場合は、ＴＣＰアプリケーションが不十分に書かれていること、もしくは、ネットワークに構成上の障害があることを示すフラグが設定される。修復手順が、システム管理者に提示されてもよく、もしくは実行されてもよい。

ステップ２３５では、ＴＣＰ受信装置１１０に接続したバッファ内の空きスペース量が、所定期間モニターされ、同じ期間の間にパケットが受信されるレートと比較される。パケットが比較的一定レートに到達する時間の間に、空きスペース量が所定の閾値未満になる場合、フラグが設定される。これは、受信装置がデータ転送においてボトルネックである状況を示していると考えられるだろう。可能なら、修復手順が、システム管理者に提示されてもよく、もしくは実行されてもよい。

ステップ２４０では、受信装置ＴＣＰ１１０の処理に利用されるＣＰＵサイクル数は、アイドルタイムとして残される量と比較される。ＣＰＵサイクル数が、所定の閾値を超える場合、フラグが設定される。この状況は、受信装置システムがデータ転送においてボトルネックとなっていることを示していると考えられる。可能なら、修復手順が自動的に実行されてもよい。

ステップ２４５では、受信装置アプリケーションがＴＣＰソケット受信装置バッファから読み出すレートが、モニターされる。レートが所定の閾値未満になる場合、フラグが設定される。フラグが設定される場合、可能なら、修復手順が自動的に実行されてもよい。

ステップ２５０では、適切なタイプおよび適切な量のデータをシステム管理者に提示出来るように、モニターされてきたイベントに対して診断後集約が実行される。この診断後集約は、以下のうちの一部もしくはすべてを識別することを含む：（１）集約のために適切なクライアントシステムのグループ、（２）特に関連する１つ以上の属性タイプ（ＩＰサブネット番号、ＯＳタイプ／バージョン、最新の構成変更および他の要因など）の組、（３）これらのクライアントシステム内で起こった一連の問題。どのクライアントシステムが集約のために適切であるかを決定した後、共通の問題を共有するシステムが特定される。これは、データベース１５７に格納されている様々な属性に与えられた特性および重み付けを参照することにより行われる。

ステップ２５５では、最終レポートが、（１）診断後集約と、（２）集約されなかった個々の問題の記述とに基づいて生成される。

ステップ２６０では、最終レポートは、システム管理者に伝送される。

ステップ２６５では、方法２００のパフォーマンスに関連した、診断結果、修復手順、システム管理者へのメッセージ、および他の情報の記録が、データベース１５７に格納される。

図３Ａおよび図３Ｂは、ＴＣＰ送信装置での制限因子自動検出方法の処理フロー図を示している。

自動診断のための方法３００は、自動診断モジュール１５０がＴＣＰ送信装置１２０側に接続されている、システム１００の実施例により実行される。自動診断方法３００は連続した一連のステップとして説明されているが、方法３００のステップは、複数の構成要素のよって共に、もしくは並列に、非同期式でも、パイプライン方式でも、もしくは他の方式でも実行可能である。方法３００は、特に断りのない限り、本明細書及び図面にステップを列挙した順序と同じ順序で実行されなければならないという特別な要件はない。

フローポイント３０５では、システム１００は、ＴＣＰ送信装置１２０で自動診断を始める準備ができている。

ステップ３１０では、粗な粒度の再送タイマがモニターされ、いつタイマが満了してパケットが再送されるかを判定する。再送タイムアウトの数が所定の閾値を超える場合、フラグが設定される。この状況は、送信装置と受信装置との間のネットワーク経路内に、何らかの問題があることを示していると考えられる。可能なら、修復手順が実行されてもよい。

ステップ３１５では、特定のタイムフレーム内に送られる特定セットのパケットは、（１）セット内のどのパケットも、小さなパケットの使用を必要とする制御情報、メタデータ、もしくは他のタイプのデータを含まず、かつ、（２）セット内のすべてのパケットがデータパケットの同一バーストの一部であるものとして、識別される。

ステップ３２０では、ステップ３１５で識別されたパケットのセット内に含まれたパケットの、平均サイズが計算される。セット内のパケットの所定数が不適当に小さい場合は、ＴＣＰアプリケーションが不十分に書かれていること、もしくは、ネットワークに構成上の障害があることを示すフラグが設定される。可能なら、修復手順が実行されてもよい。

ステップ３２５では、ＴＣＰ受信装置１１０により広告されるウィンドウのサイズがモニターされる。

ステップ３３０では、遅延帯域積が計算される。

ステップ３３５では、広告ウィンドウのサイズと遅延帯域積とが比較される。ウィンドウのサイズが遅延帯域積に対して十分に大きくない場合、このことは、ＴＣＰ受信装置１１０がボトルネックとして作用しているのを示している可能性がある。これらの条件の下でフラグが設定され、可能なら、修復ステップが実行されてもよい。

ステップ３４０では、ＴＣＰ受信装置１１０上の広告ウィンドウサイズの変化が、ＴＣＰ送信装置１２０のパフォーマンスと比較される。サイズ変化が所定のパターンに適合する場合、ＴＣＰ送信装置１２０は、ボトルネックとして作用していると考え得る。これらの条件の下ではフラグが設定され、可能ならば、修復ステップが実行されてもよい。

ステップ３４５では、ＴＣＰ送信装置１２０のバッファのサイズが、ＴＣＰ送信装置１２０とＴＣＰ受信装置１１０との間のネットワーク経路の帯域幅と比較される。送信バッファサイズがネットワーク経路の帯域幅に対して不十分なものである場合は、ＴＣＰ送信装置１２０はボトルネックとなっている可能性がある。これらの条件の下ではフラグが設定され、可能ならば、修復ステップが実行されてもよい。

ステップ３５０では、各ＴＣＰ送信装置１２０上の送信バッファにキューイングされた未送信のデータの量がモニターされる。ＴＣＰ送信装置１２０が接続経路上に何も送信出来ない回数が、特定の閾値を超える場合、ＴＣＰ送信装置１２０はボトルネックとなっている可能性がある。これらの条件の下ではフラグが設定され、可能ならば、修復ステップが実行されてもよい。

ステップ３５５では、モニターされて来たイベントに対して診断後集約が実行される。このステップは、方法２００のステップ２５０と同様である。この診断後集約は、（１）集約のために適切なクライアントシステムのグループ、（２）特に関連する１つ以上の属性タイプ（ＩＰサブネット番号、ＯＳタイプ／バージョン、最新の構成変化、他の要因など）の組、あるいは、（３）これらのクライアントシステム内で発生した問題の組、を識別することを含んでいる。どのクライアントシステムが集約のために適切かを決定した後、共通の問題を共有するシステムは、データベース１５７に格納された様々な属性の重みづけを調べることにより特定される。

ステップ３６０では、最終レポートが、（１）診断後集約と、（２）集約されなかった個々の問題の記述とに基づいて生成される。

ステップ３６５では、最終レポートがシステム管理者に伝送される。

ステップ３７０では、方法３００のパフォーマンスに関連する診断結果、修復手順、システム管理者へのメッセージ、および他の情報の記録が、データベース１５７に格納される。

代替実施例
好ましい実施例が、本願明細書に開示されているが、本発明の概念、範囲、および精神の範囲内で、多くの変形が可能であり、これらの変形は、この出願を熟読することにより、当業者にとり明白なものとなろう。

ＴＣＰ接続内の、パフォーマンス制限因子自動検出システムのブロック図を示す。 ＴＣＰ受信装置内のパフォーマンス制限因子自動検出方法の処理フロー図の一部を示す。 ＴＣＰ受信装置内のパフォーマンス制限因子自動検出方法の処理フロー図の残部を示す。 ＴＣＰ送信装置内のパフォーマンス制限因子自動検出方法の処理フロー図の一部を示す。 ＴＣＰ送信装置内のパフォーマンス制限因子自動検出方法の処理フロー図の残部を示す。

符号の説明

１００ システム、１１０ ＴＣＰ受信装置、 １２０ＴＣＰ送信装置、１３０ 通信ネットワーク、１４０ オペレーティングシステム、１５０ 自動診断モジュール、１５５ ソフトウエアインストラクション、１５７ データベース、１５８ フィールド。

Claims (11)

1. ＴＣＰ送信装置からネットワーク経路を介して送信されてＴＣＰ受信装置において受信されたＴＣＰパケットの時間及び順序に従って、再送タイムアウトが何回発生したかを検出することと、
   上記再送タイムアウトの発生回数が予め決められたしきい値を超過したとき、上記ネットワーク経路によって第１の性能問題が生じたことを表示することとを含む方法。
2. 上記受信された複数のＴＣＰパケットから、連続した複数のパケットのバーストを識別することと、
   予め決められた第２のしきい値未満のサイズをそれぞれ有する上記連続した複数のパケットのバーストに係る第２の数を決定することと、
   上記第２の数が予め決められた第３のしきい値を超過したとき、第２の性能問題を表示することとを含む請求項１記載の方法。
3. 上記複数のＴＣＰパケットが定常レートで受信される所定の時間期間にわたって、上記ＴＣＰ受信装置に接続されたバッファにおける空きスペースの量をモニタリングすることと、
   上記空きスペースの量が予め決められた第２のしきい値未満になったとき、上記ＴＣＰ受信装置によって第２の性能問題が生じたことを表示することとを含む請求項１記載の方法。
4. 上記ＴＣＰパケットを処理するために使用される上記ＴＣＰ受信装置のプロセッササイクルの百分率を決定することと、
   上記百分率が予め決められた第２のしきい値を超過したとき、上記ＴＣＰ受信装置によって第２の性能問題が生じたことを表示することとを含む請求項１記載の方法。
5. 上記再送タイムアウトが何回発生したかを検出することは、
   上記各ＴＣＰパケットに、タイムスタンプ及びシーケンス番号をタグ付けすることと、
   上記タイムスタンプ及び上記シーケンス番号に従って、上記各ＴＣＰパケットが連続した順序で到来したか否かを決定することとを含む請求項１記載の方法。
6. 予め決められたサイズ未満のサイズをそれぞれ有するパケットの使用を要求する制御情報、メタデータ又は他のタイプのデータをいずれも含まないようなＴＣＰパケットのセットを、ＴＣＰ送信装置から送信されるＴＣＰパケットのバーストから識別することと、
   上記ＴＣＰパケットのセットの平均サイズを計算することと、
   予め決められた値だけ上記平均サイズよりも小さなサイズをそれぞれ有する上記ＴＣＰパケットのセットの数を決定することと、
   上記数が予め決められたしきい値を超過したとき、第１の性能問題を表示することとを含む方法。
7. 広告ウィンドウのサイズの変動が予め決められたパターンに適合するか否かを決定することと、
   上記広告ウィンドウのサイズが遅延帯域積に対して十分に大きくないとき、第２の性能問題を表示することとを含む請求項６記載の方法。
8. 上記広告ウィンドウのサイズの変動が予め決められたパターンに適合するか否かを決定することと、
   上記変動が上記予め決められたパターンに適合するとき、第３の性能問題を表示することとを含む請求項７記載の方法。
9. プロセッサと、
   上記プロセッサに接続されたメモリとを備えた処理システムであって、上記メモリは、上記プロセッサによって実行されたときに上記処理システムに以下の処理を実行させる命令を格納し、上記処理は、
   ＴＣＰ送信装置からネットワーク経路を介して送信されてＴＣＰ受信装置において受信されたＴＣＰパケットの時間及び順序に従って、再送タイムアウトが何回発生したかを検出することと、
   上記再送タイムアウトの発生回数が予め決められたしきい値を超過したとき、上記ネットワーク経路によって第１の性能問題が生じたことを表示することとを含む処理システム。
10. 上記処理はさらに、
    上記受信された複数のＴＣＰパケットから、連続した複数のパケットのバーストを識別することと、
    予め決められたしきい値未満のサイズをそれぞれ有する上記連続した複数のパケットのバーストに係る第２の数を決定することと、
    上記第２の数が予め決められた第３のしきい値を超過したとき、第２の性能問題を表示することとを含む請求項９記載の処理システム。
11. 上記処理はさらに、
    上記複数のＴＣＰパケットが定常レートで受信される所定の時間期間にわたって、上記ＴＣＰ受信装置に接続されたバッファにおける空きスペースの量をモニタリングすることと、
    上記空きスペースの量が予め決められた第２のしきい値未満になったとき、上記ＴＣＰ受信装置によって第２の性能問題が生じたことを表示することとを含む請求項９記載の処理システム。

Images