データネットワークの品質。 ソフトウェアおよびハードウェアの測定

通信システムとデータ伝送ネットワークの特性の測定に関する一連の記事を公開したいと思います。 この記事は入門書であり、非常に基本的な事項のみを扱います。 将来的には、「これはどのように行われるか」というスタイルをより深く見ていく予定です。



製品やサービスを購入するとき、私たちはしばしば品質などのコンセプトで運営しています。 品質とは？ オジェゴフの辞書に目を向けると、「オブジェクトまたは現象を他と区別して確実性を与える一連の重要な機能、プロパティ、機能」が表示されます。 定義を通信ネットワークの分野に移し、1つの回線または通信ネットワークの違いを一意に決定できるようにする「重要な機能、プロパティ、および機能」を定義する必要があると結論付けました。 すべての記号とプロパティの列挙は、「メトリック」の概念によって一般化されます。 誰かが通信ネットワークの測定基準について話すとき、彼は通信システム全体を正確に判断することを可能にする特性と特性を意味します。 品質評価の必要性は主に経済分野にありますが、技術的な部分も同様に興味深いものです。 この知識分野の最も興味深い側面をすべて明らかにするために、それらのバランスをとろうとします。



猫に興味がある人は誰でも聞いてください。

通信システムの監視と診断

上で書いたように、品質メトリックは、ネットワークまたは通信システムの所有権の経済的要素を決定します。 つまり 通信回線のレンタルまたはリースのコストは、この通信回線の品質に直接依存します。 コストは、順番に、市場の需要と供給によって決定されます。 その他のパタ​​ーンはAdam Smithによって記述され、Milton Friedmanによって開発されました。 ソ連の時代でさえ、計画された経済があり、彼らが「市場」を政府と国民に対する犯罪と考えていたとき、適切な品質を確保するために設計された軍事的および民間の目的のための国家受容機関がありました。 しかし、私たちの時代に戻って、これらの測定基準を決定してみてください。



現在最も人気のあるテクノロジーとして、イーサネットに基づいたネットワークを検討してください。 データ伝送メディアの品質メトリックは、エンドユーザーにとってほとんど関心がないため、考慮しません（メディア自体の素材が時々興味深い場合を除きます：ラジオ、銅、または光学系）。 最初に思い浮かぶ指標は帯域幅です。 単位時間あたりに転送できるデータ量。 2つ目は、1 つ目に関連付けられているパケットスループット（PPS、1秒あたりのパケット数）であり、単位時間あたりに転送できるフレーム数を反映しています。 ネットワーク機器はフレームで動作するため、このメトリックにより、機器が負荷に対処できるかどうか、およびその性能が宣言されたものと一致するかどうかを評価できます。



3番目のメトリックは、フレーム損失の指標です。 フレームを復元できない場合、または復元されたフレームがチェックサムと一致しない場合、受信側または中間システムはそれを拒否します。 これは、OSIシステムの第2レベルを指します。 より詳しく見ると、ほとんどのプロトコルは受信者へのパケットの配信を保証していません。彼らの仕事はデータを正しい方向に転送することだけであり、保証する人（たとえばTCP）はフレーム転送（再送）のために帯域幅を大幅に失う可能性がありますが、それだけですこれらはL2フレームに依存しており、このメトリックの損失が考慮されます。



4番目 -遅延（遅延）、つまり ポイントAから送信されたパケットがポイントBに到達するまでの時間。この特性からさらに2つを区別できます。1トリップ遅延（1トリップ）と循環（ラウンドトリップ）です。 秘Theは、AからBへのパスを1つにすることができるが、BからAへのパスはすでに完全に異なることです。 時間を分割するだけでは機能しません。 また、遅延は時々変化する可能性があります。つまり、「震え」があります。このようなメトリックはジッタと呼ばれます。 ジッタは、隣接するフレームに対する遅延の変動を示します。 2番目のパケットに対する1番目のパケットの遅延偏差、または4番目のパケットに対する5番目のパケットの遅延偏差と、その後の所定の期間の平均。 ただし、画像全体を分析する必要がある場合、またはテスト時間全体で遅延を変更する必要があり、ジッタが画像を正確に反映していない場合は、遅延変動インジケータが使用されます。 5番目のメトリックは、チャネルの最小MTUです。 多くの場合、このパラメーターは重要ではありません。これは、ジャンボフレームを使用することが推奨される「重い」アプリケーションを操作する場合に重要になる可能性があります。 6番目のパラメータ、および多くのパラメータでは明らかではない-バースト-正規化された最大ビットレート。 このメトリックを使用して、ネットワークまたはデータ転送システムを構成する機器の品質を判断し、機器のバッファのサイズを判断し、信頼性条件を計算できます。

測定について

メトリックを決定したので、測定方法とツールを選択する価値があります。

遅延

ほとんどのオペレーティングシステムに同梱されている有名なツールは、pingユーティリティ（ICMP Echo-Request）です。 多くの人が1日に数回使用して、ノード、アドレスなどの可用性を確認します。 RTT（往復時間）を測定するためだけに設計されています。 送信者は要求を作成して受信者に送信し、受信者は応答を作成して送信者に送信し、送信者は要求と応答の間の時間を測定し、遅延時間を計算します。 すべてが明確でシンプルで、何も発明する必要はありません。 いくつかの精度の問題があり、次のセクションで説明します。



しかし、一方向のみの遅延を測定する必要がある場合はどうでしょうか？ ここではすべてがより複雑です。 実際には、遅延を推定するだけでなく、送信側ノードと受信側ノードの時刻を同期すると便利です。 このために、PTPプロトコル（Precision Time Protocol、IEEE 1588）が発明されました。 私がNTPをより良く説明するのは、 ここにはすべてがすでに描かれています。正確な時間をナノ秒に同期できるとだけ言っておきます。 その結果、pingのようなテストになります：送信者はタイムスタンプ付きのパケットを生成し、パケットはネットワークを通過し、受信者に到達し、受信者はパケットの時間とそれ自体の時間の差を計算し、時間が同期されていれば、正しい遅延が計算されます。その測定は間違っています。



測定に関する情報を蓄積し、遅延の履歴データに基づいて、VoIPおよびIPTVネットワークの重要な指標であるジッタと遅延変動を簡単にプロットおよび計算できます。 その重要性は、主にエンコーダとデコーダの動作に関連しています。 「フローティング」遅延とアダプティブコーデックバッファを使用すると、情報を回復する時間がなくなる可能性が高くなり、音声に「リンギング」（VoIP）またはフレーム「ミキシング」（IPTV）が発生します。

フレームロス

遅延を測定するときに、応答パケットが受信されなかった場合、パケットが失われたと見なされます。 これがpingの機能です。 すべてが単純でもあるように見えますが、これは一見しただけです。 上記のように、pingの場合、送信者は1つのパケットを形成して送信し、受信者は独自のパケットを形成して応答として送信します。 つまり 2つのパッケージがあります。 紛失した場合、どれが失われますか？ 私たちの直接のパケットルートが反対に対応している場合、それはそうではない場合、それは重要ではないかもしれません（疑わしいことですが） そうでない場合は、ネットワークのどの部分が問題であるかを理解することが非常に重要です。 たとえば、パケットが受信者に到達した場合、ダイレクトパスは正常に機能しますが、そうでない場合は、このセクションの診断から開始する必要がありますが、パケットが到達したが戻らなかった場合は、健全な直接セグメントのトラブルシューティングを行う価値はありません。 識別は、テストパッケージに埋め込まれた順序タグによって助けられます。 両端に同じタイプのメーターがある場合、それぞれの端はいつでも送受信されたパケットの数を知っています。 どのパケットが受信者に届かなかったかは、送信されたパケットと受信されたパケットのリストを比較することで取得できます。

最小MTU

この特性を測定することはそれほど難しくなく、退屈で日常的な作業です。 最小MTU（最大伝送ユニット）サイズを決定するには、異なるフレームサイズとDF（断片化しない）ビットセットを使用してテスト（同じping）を実行するだけで済みます。これにより、フラグメンテーション禁止のためにフレームサイズより大きいパケットを渡すことができなくなります。



たとえば、これは機能しません：

$ ping -s 1500 -Mdo 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 1500(1528) bytes of data. ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500 ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1006ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、それは行く：

 $ ping -s 1400 -Mdo 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 1400(1428) bytes of data. 1408 bytes from 8.8.8.8: icmp_seq=1 ttl=48 time=77.3 ms 1408 bytes from 8.8.8.8: icmp_seq=2 ttl=48 time=76.8 ms 1408 bytes from 8.8.8.8: icmp_seq=3 ttl=48 time=77.1 ms ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 76.839/77.133/77.396/0.393 ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

商業的な観点からはあまり使用されませんが、場合によっては関連します。 繰り返しますが、非対称パケットパスでは、異なる方向の異なるMTUが可能であることに注意してください。

スループット

確かに、単位時間あたりに送信される有用な情報の量はフレームのサイズに依存するという事実を知っています。 これは、フレームに多くのサービス情報が含まれているためです。ヘッダーは、フレームのサイズが変更されてもサイズは変わりませんが、「ペイロード」のフィールドが変わります。 これは、リンク速度でデータを送信したとしても、同じ期間に送信される有用な情報の量は大きく異なる可能性があるという事実にもかかわらずです。 したがって、チャネル帯域幅を測定するユーティリティ（たとえば、iperf）があるにもかかわらず、ネットワーク帯域幅で信頼できるデータを取得することは不可能な場合があります。 問題は、iperfがプロトコルヘッダー（通常はUDP、ただしTCPも可能）に囲まれた非常に「有用な」部分の計算に基づいてトラフィックデータを分析するため、ネットワーク負荷（L1、L2）が計算（L4）と一致しないことです。 ハードウェアメーターを使用する場合、トラフィック生成のレートはL1に設定されます。 それ以外の場合、フレームサイズの測定中に負荷が変化する理由はユーザーには明らかではありません。帯域幅の%%として設定してもそれほど顕著ではありませんが、速度（Mbps、Gbps）の単位で示すと非常に顕著です。 テスト結果では、原則として、各レベルの速度が示されます（L1、L2、L3、L4）。 たとえば、次のようになります（出力でL2、L3を切り替えることができます）。

1秒あたりのフレーム数での帯域幅

ネットワークまたは通信システムを、正常な機能を保証する通信回線とアクティブな機器の複合体として話す場合、そのようなシステムの効率は、それを構成する各リンクに依存します。 通信回線は、宣言された速度（線形速度）で作業を提供する必要があり、アクティブな機器はすべての着信情報を処理する時間を確保する必要があります。



すべての機器メーカーは、PPS（パケット/秒）パラメーターを宣言します。このパラメーターは、機器を「消化」できるパケットの数を直接示します。 以前は、圧倒的な数の機器が膨大な数の「小型」パッケージを処理できなかったため、このパラメーターは非常に重要でした。現在、メーカーはワイヤスピードをますます報告しています。 たとえば、小さなパケットが送信される場合、処理時間は通常大きなパケットと同じくらい費やされます。 パッケージの内容は機器にとって興味深いものではありませんが、ヘッダーからの情報は重要です-誰から来たのか、誰に送信するのか。



今日、ASIC（特定用途向け集積回路）-特定の目的のために特別に設計された非常に高性能のマイクロ回路であり、FPGA（フィールドプログラマブルゲートアレイ）は非常に頻繁に使用されています-スイッチング機器でより広く使用されています-その用途についてここで同僚と読んで、 ここで聞くことができます 。

バースト

多くのメーカーがコンポーネントを節約し、小さなパケットバッファを使用していることは注目に値します。 たとえば、リンク速度（wirespeed）での作業が宣言され、実際には、ポートバッファーがこれ以上のデータを収容できないためにパケット損失が発生します。 つまり プロセッサはまだ蓄積されたパケットキューを処理しておらず、新しいパケットキューは引き続き使用されます。 多くの場合、この動作はさまざまなフィルターまたはインターフェイスコンバーターで観察できます。 たとえば、フィルター処理されたトラフィックが確実に100Mbps未満であることがわかっている場合、フィルターは1Gbpsストリームを受け入れ、処理結果を100Mbpsインターフェースに送信すると想定されています。 しかし、実際には、ある時点で100 Mbpsを超えるトラフィックの「急増」が発生し、この状況ではパケットが整列することがあります。 バッファサイズが十分である場合、それらはすべて損失なしにネットワークに移動し、そうでない場合は単に失われます。 バッファが大きいほど、過剰な負荷に耐えることができます。

測定誤差

しかし、科学計測は、その裁量で説明し、どのように測定するかについては、科学ではありません。 知識の分野は、確認された知識に基づいた研究方法の特性が決定されると科学になります。 そのような計測特性の1つは、測定ツール自体が測定プロセスに誤差を持ち込むべきではないこと、またはこの誤差を確実に把握して決定する必要があることです。 ソフトウェアベースのツールや汎用オペレーティングシステムを扱っている場合、残念ながら測定誤差を正確に判断することができず、測定機器を適切に校正することはできません。 問題は、データ処理中に発生するプロセス、ネットワークからパケットを受信するプロセス、応答を生成するプロセスが、オペレーティングシステムのアーキテクチャに関連して、本質的に確率的であることです。 例としてpingを使用して説明します。

• プログラムは時間を測定し、データを含むパケットを形成し、OSIを介して「降下」のためにOSに渡します。
• OCはパケットをキューに入れ、それを処理し、必要に応じて欠落しているカプセル化を適用し、コンテキストをプルし、ドライバーを介してネットワークカードバッファーにパケットを入れます。
• パケットは、受信者に到達するまでネットワークを通過します。
• パケットを受信して​​バッファに格納した受信者のネットワークカードは、割り込みを生成します。
• 受信者のOSは、他の処理を停止し、パケットを読み取って処理のためにキューに入れ、処理し、それを送り返します（pingについて話している場合）、またはコンテキストをプルして処理のためにプログラムに渡します（処理が「核」でない場合）。 アイテム1-2は、受信者側でのみ繰り返されます。
• パケットは再び反対方向にのみネットワークを移動します（直接の方向に正確に対応するという事実ではありません）。
• 条項4〜5は送信者に対して繰り返されます。
• 送信側プログラムは、開始1と終了7の間の時間を計算します。

したがって、ポイント3および6で金額を取得する代わりに、プログラムによるパッケージの作成から同じ応答パッケージを受信するまでの時間を取得しました。 遅延では、「スプリアス」セクションが考慮されます。 この種の問題の解決策は、ネットワーク出力にできるだけ近いタイムスタンプをパケットに挿入することです。 少なくともネットワークカードバッファ。 これにより、ポイント1〜2の「寄生的な」影響を遮断できますが、4〜5は残ります。 受信側では、たとえば受信側と送信側のMACを入れ替えるだけで、オペレーティングシステムで処理せずにパケットを返す必要があります。 このようなパケットを受信した最初の送信者は、ネットワークへの出力で設定された初期マークをネットワークからの入力で現在のマークと比較し、遅延のより正確な計算を行うことができます。 Bercut-ETまたはBercut-ETXでエコー要求モードと認定テストモードの遅延を測定すると、良い例が見られます。 一部のシステムでは、アーキテクチャにより、pingは直接接続（クロスコネクト）で30〜60ミリ秒の範囲の値を表示できますが、認定テストでは8〜16 nsを表示します。 違いは桁違いです。 2台のコンピューターが最良の結果を示す可能性がありますが、遅延の測定でそれらによって導入されたエラーは考慮できません。 また、このデバイスのエコーリクエストは、遅延を測定するためのものではなく、ネットワーク上のノードの可用性を確認するための標準ツールとして存在します。

おわりに

以下のメトリックは、通信ネットワークおよびシステムの品質を評価するための基本的かつ支援的なものです。

• 帯域幅
• パケットスループット
• フレームロス
• 遅れる
  
  
  • ワントリップ
  • 往復
  • ジッター
  • 遅延変動
• 最小MTU
• 破裂

測定の一般原則は、測定セクションの出力（または入力）にできるだけ近いテストパケットを生成（または評価）することです。そうしないと、測定に影響する要因の数が増えるため、精度を確保できなくなります。 現在、RFC2544やY.1564などのテスト方法が一般的であり、適用されています。 デバイスの動作原理とテストの詳細について多くのことが書かれています。 次の出版物で、いくつかの秘密を明らかにする予定です。

ご清聴ありがとうございました。