こんにちはszkです。
前回から1か月も間が空いてしまいましたが、前回の記事の続きとなります。
ネットワークインフラの可視化についての記事です。
通常、アプライアンスやすでに規制のソフトウェアで構築されている部分の話ですし、活用されることの少ない知識であると思いますがご査収いただければと思います。

前回の記事においては可視化する必要性の部分を記載したので、今回はその方法の部分となります。
基礎知識としてTCP/IPの通信仕様に関する基本的な知識が必要となります。ご了承ください。

もし、ご興味があればこちらの方の記事をお読みになりながらご覧いただけるとわかりやすいかと思います。

■可視化を行う方法について

さて、可視化を行うにはその元となるデータの取得が必要です。
データの取得方法は様々で、Javascriptからクライアントの測定データを取得したり、
NW機器のログから取得したり、サーバで定期的にコマンドを実行したりと様々な方法があります。

ネットワークの可視化においてもその方法は様々ですが、ここでは”パケットキャプチャを用いたデータ取得”を紹介します。
非常にニッチな方法かつ、難しい手法であり、実現までのコスト対パフォーマンスの低い方法ではありますが、
パケットキャプチャから行うデータ取得のメリットは以下のようなものが挙げられます。

・システムの大幅な変更が不要
システムパフォーマンスを測る際に、一般的な監視ソフトウェアや測定ソフトを使った場合、
サーバ内部にエージェントを導入するといった操作が必要になる場合が多くあります。
しかし、この方法の場合、パケットキャプチャを行える機器さえあれば、既存のサービス機器に対する変更は不要です。
通信の多くが通過するコアスイッチに対してSPANPortを設定し、パケットキャプチャ機器を接続すれだけで情報の収集ができ
取り外しを行う際も簡単にそれを行えます。

・ある程度のノードパフォーマンスも測れる
スタンドアロンで動作するアプリ以外、つまりTCPポートを使用し、通信が発生するアプリケーションが動作するノードに対しては
パケット情報のFormとTo。つまり送受信ノードの特定と、その使用ぽが可能であり、それらの通信を測ることができます。

つまり平常時と比べたときに通信の異常性、特異性を察知することができる。
(傾向性検知みたいな)

・使用できるデータが豊富である
TCP/IPパケットにはその基本情報となるデータが数多く存在する。
これらを適切に理解し、組み合わせることでネットワークのパフォーマンスとしてデータ抽出することが可能である。
WireShakeなどを使って測定することもできなくはないが、人間の目視で行うのは非常に大変。
その為、これらを行いたい場合は特定のメーカーが販売しているアプライアンスか、パケット情報を取得しTxt化した上で
Splunkなどの統合ログ管理システムなどを用いて仕組みを自作する必要があることを付け加えておく。
(ここが一番難しい)

■用語について

以下から技術的な内容を記載する。
ここで、本人の整理も兼ねて用語の整理を行う。

・メトリック(測定基準）
NW的なメトリックとは異なる、監視用語。
メジャーどころの監視ソフトウェアでこのワードが使われているので拝借する。
例えば「CPU使用率」や「メモリ使用率」といった監視対象の数値を「メトリック」と総称する。

・ノード
IPアドレスを持った機器(クライアント/サーバを問わない)のことを指す。

・クライアント(クライアントノード)
通信時に送信要求を行ったノードのことを指す。

・サーバ(サーバノード)
送信要求を受けたノードのことを指す。
サービスやシステムが動いてるノードは大体こっち。

・ターン数
通信が「1往復」する回数。
クライアントが通信のリクエストを行い、それに対するデータの返信がある。
その後に次のリクエストを行うまでが1ターンとなる。

■キャプチャしたパケットの関連性(接続性)を特定する

TCP/IPの通信においてパケットは1つのコネクションの中で複数回やり取りされる。
(ここでいう「コネクション」は3WayhandShakeを実行要請してから最後のFINに対してACKを返すまで)
これらの紐づけを行うのがパケットキャプチャを行った後の第一歩である。
以下の方法が挙げられる。

・3WayhandShake
クライアントのSYNから
クライアントのFINまで

・シーケンス番号を用いて特定する

■サーバの応答時間を求める(初動)

サーバの応答時間は通信が発生し、クライアントを知ることで、その対象ノード自体のキャパシティを知ることができる。
例えば、平均と比べてサーバの応答時間が長い場合そのノードではアプリケーションやH/Wスペックを原因とした処理の遅延が発生している可能性がある。
TCP/IPでは送信したデータを問題なく受信した際に「SQ番号にデータのバイト数を加算して返答する」
その為、データ転送時も送信に対する受信のパケットがこれにより特定できる。
応答時間を算出するためには「送信時間」と「受信時間」の要素が必要となるが、TCP/IPのタイムスタンプはオプションかつ脆弱性対象となる為常にONになっているわけではない。
その為応答時間は「キャプチャを行った機器での取得タイミング」をタイムスタンプとするのが良い。

：計算式：応答時間　＝　送信パケットをキャプチャした時間　-　受信パケットをキャプチャした時間

■データ転送時間を求める

データの転送時間を知ると、ある区間のネットワーク使用帯域との相関を行うことでネットワーク上の通信遅延を知ることができる。
また、サーバ側でウィンドウサイズの変更があれば、その相関からサーバの受信処理限界を察知することもできる。
TCP/IPでは通信オープン時の3WayHandshakeの後の通信についてはウィンドウサイズや転送するサイズそのものの違いによって
単体のTCP/IPパケットのみで測ろうとするとどうしても測定条件にバラつきが出てしまう。
そのため、データ転送時間の場合はその尺度をパケット単体ではなく「データを送り始めてから送り終わるまで」とし、ターン数で平均を割れば近似する条件で結果が得られる。

：計算式：(3WayhandShake終了後の次のパケットの送信時間～最後のクライアントのACKパケット)
(パケット単体の時間が知りたい場合：上記/ターン数

■再送遅延時間を求める

パケットが何らかの理由で通信拒否(RSTパケットによる拒否)されたり、タイムアウトすると通常TCPパケットは再送される。
この時、サーバは同様の内容のパケットを重複送信することになり、もちろんその送信時間分本来想定された通信時間から足が出る。
このことを「再送遅延」と呼ぶ。
再送遅延時間はサーバキャパシティ、或いはFWやLBといったネットワーク中間機器のキャパシティや、NW機器でのDiscardでも発生するため、事象の発生時のヒントとなりうることが多い。

■ラウンドトリップタイムを求める

電気回路などで、通信に対する応答する速度を大まかにラウンドトリップタイムという。
データの転送を行い、それに対応するACKが返ってくるまでの時間がこれにあたる。
データ転送時間との違いはデータ転送時間は「データを転送し始めてからデータを転送し終わるまで」を通信回数で割るのに対して
ラウンドトリップタイムは「ノードAから送信される通信にノードBが応答するまで」という性質なので、送信するデータサイズやデータファイル(通信の数)に捕らわれない。
単純にネットワークの速度という意味ではこちらの数値を使うほうが正しいが、実際に人間の体感時間で考慮するとデータ転送時間で計算を行ったほうがしっくりする数値となるので、個人的には使いづらい印象。
ラウンドトリップタイムとデータ転送時間を相関するとネットワークの物理スペックと設計による乖離がわかったり、、、したらいいな。
取得する方法はサーバ応答時間と同様で、「ノードの送信パケットをキャプチャした時間」で「それに対応する受信パケットをキャプチャした時間」を減算することで求められる。

---

他にもいろいろありますが、結構書いたので今回はここまで。
気が向いたら続きかくかもです。