Flowmon NPMメトリックの計算
- Last Updated: April 5, 2026
- 7 minute read
- Flowmon Products
- Flowmon
- Documentation
この章では、以下のNPM (ネットワークパフォーマンスモニタリング)メトリックがFlowmonプローブでどのように計算されているのかを詳細に説明します。
-
RTT - ラウンドトリップ時間
-
SRT - サーバ応答時間
-
RTR - 再送信
-
OoO - アウトオブオーダーパケット
すべてのNPMメトリックにはマイクロ秒の精度が与えられます。
特定のL7拡張が有効な場合、対応するフローに対してNPMメトリックは計算されません。理由は、このL7拡張では、L7の可視性を提供するために、追加のL7情報を使用して典型的なフローが分割されるからです。
このように小さく分割されたフローには通信全体が含まれないため、NPM統計の計算は不正確になります。NPMメトリック(遅延およびジッターを含む)は、COAP、SMB、VOIP、DHCP、MYSQL、PGSQL、MSSQLといったL7拡張が有効なフローの場合は提供されません。
適切なNPMメトリック監視のためには、1つのモニタリングポートで両方向のトラフィックを監視する必要があります。このため、NPMメトリックをTAP経由で監視することができません。
ラウンドトリップ時間(RTT)
ラウンドトリップ時間は、ネットワーク遅延を表します(クライアントからサーバに送信され、サーバからクライアントに戻ってくるパケット)。TCPベースのネットワーク通信で利用可能であり、TCPハンドシェイクの観察によって測定されます。
-
サーバネットワーク時間 = TCPハンドシェイクの先頭にある2つのパケット: (SYNパケットとSYN-ACKパケット)間の時間差
-
クライアントネットワーク時間 = TCPハンドシェイクの2番目と3番目のパケットである、SYN-ACKパケットとACKパケットとの時間差
-
RTT = サーバネットワーク時間とクライアントネットワーク時間の合計
サーバ応答時間(SRT)
サーバ応答時間は、すべてのTCPフロー、およびDNSトラフィックを伴うUDPフロー(つまり、ポートの1つが53であるUDPフロー)の場合に測定されます。すべての時間測定がマイクロ秒の精度で行われます。
TCPフロー
クライアントとサーバは、SYNパケットの送信側(クライアント)とSYN+ACKパケットの送信側(サーバ)を示す情報に基づき識別されます。測定されたサーバ応答時間は、サーバのACKパケットの予測された観察時間(この予測はクライアント要求の観察時間と以前に測定されたサーバネットワーク時間に基づいています)とサーバ応答の観察時間との時間差を表しています。測定では、応答前のサーバからのACKパケットの観察を信頼することはできません。これは、ACKパケットがサーバ応答とマージされる可能性があるためです。クライアントの要求パケットの前にサーバの応答パケットがキャプチャされる場合、SRTは0になります。
-
L4プロトコルがTCPの場合(のみ)、TCPハンドシェイク時のクライアントのSYNパケットとサーバのSYN+ACKパケットの観察の時間的な差異として、サーバネットワーク時間tsntを測定します。
-
-
TLSプロトコルを除くすべてのTCPトラフィックの場合: クライアント要求(1)の前の、サーバ応答の最初の観察(2)と最新の観察(3)の時間差∆trrを測定します。
-
TLSプロトコルの場合: サーバのTLSアプリケーションデータ応答の最初の観察と最新の(3)先行クライアントのTLSアプリケーションデータ要求の観察との時間差∆trrを測定します。
-
-
サーバ応答時間tsrt = max(0, ∆trr* − tsnt) (4)、フローエクスポート時に∆trrが測定されない場合は、tsrt = 0となります。
DNS (UDP)フロー
クライアントとサーバは、53番が送信元ポート(サーバ)であるか宛先ポート(クライアント)であるかに基づいて識別されます。測定されたサーバ応答時間は、クライアント要求の観察時間とサーバ応答の観察時間の差を表します。DNS (UDP)フローの測定アルゴリズムは、TCP測定のステップ2および3と似ています。クライアントの要求パケットの前にサーバの応答パケットがキャプチャされる場合、SRTは0になります。
-
クライアントの要求の最初の観察(1)と、それに続く最初のサーバ応答の観察(2)との時間差∆trrを測定します。
-
サーバ応答時間tsrt = ∆trr、フローエクスポート時に∆trrが測定されない場合は、tsrt = 0となります。
複数のDNS要求と応答が同じUDPポート番号を共有する場合、そのDNS要求と応答は異なる方法で処理されます。このようなパケットが交互の順序(要求、応答、要求、応答)を維持せずに混在している場合、SRTは測定されません。
(1) アプリケーション層のデータを含むクライアントからのパケットすべてが、要求と認識されます。
(2) アプリケーション層のデータを含むサーバからのパケットすべてが、応答と認識されます。
(3) クライアントの要求に複数のパケットが含まれる可能性があります。この場合、最後に受け取ったクライアントパケットの観察時間を使用します。
(4) L4プロトコルがTCPでない場合、SYNパケットおよびSYN+ACKパケットがアウトオブオーダーで観察された場合、あるいは、どのパケットも観察されなかった場合、tsntは暗黙的にtsnt = 0と定義されます。
再送信(RTR)とアウトオブオーダーパケット(OoO)
再送信またはアウトオブオーダーパケットは、通信当事者間でデータパケットが正しく送られず、再送信または再構築の必要がある状況を表します。計算は複雑で、以下のアルゴリズムで説明されます。
使用される用語:
-
SEQ - TCPパケットのシーケンス番号
-
ACK - TCPパケットの確認番号
-
**しきい値 - 初期のラウンドトリップ時間(TCPハンドシェイクで測定)または3ミリ秒(RTTが利用不可の場合)
-
TCPキープアライブ - セグメント長が0または1で、現在のSEQが予期されるSEQより1少なく、さらにパケットにSYN、FIN、またはRSTフラグがない。**このような場合、**このパケットはTCPキープアライブです。
-
重複ACK - セグメント長が0で、パケットにSYN、FIN、またはRSTフラグがなく、さらにウィンドウおよびACK番号が前のセグメントと同じ**で、**現在のSEQが予期されるSEQと等しい。**このような場合、**このパケットは重複ACKです。
評価アルゴリズム
データ長が0より大きいパケット、SYNまたはFINフラグが設定されたパケットのみを処理します。TCPキープアライブパケットはスキップします。
(以下の条件をいくつか満たすと、現在のパケットの処理が終了します。条件は以下の順序で実行されます。)
-
高速再送か? - 現在のSEQが予期されるSEQを下回っていて、逆方向に複数の重複ACKが存在し(後述)、SEQ番号が複数の重複ACK番号に対応していて、最後の重複ACKパケットの後、最大20ミリ秒でセグメントが受信された。このような場合、このパケットは(高速)再送です。
-
アウトオブオーダーか? - 現在のSEQが予期されるSEQを下回っていて、セグメントが、最大のシーケンス番号を持つ最後のセグメントの後、最大の「しきい値」ミリ秒で受信され、現在のSEQ + セグメント長が予期されるSEQと異なっている(そうでない場合、最後のパケットの再送信となる)。このような場合、このパケットはアウトオブオーダーです。
-
スプリアス再送か? - 現在のセグメント長が0を上回っていて(パケットにデータが含まれる)、現在のSEQ + セグメント長が最後のACK以下となっている(このセグメントはすでにACK済み)。このような場合、このパケットは(スプリアス)再送です。
-
再送か? - 現在のSEQが予期されるSEQを下回っている。このような場合、このパケットは(典型的な)再送です。
前述のとおり、最終の再送件数が検出されたすべての再送の合計となります。