はじめに
Wiresharkを使用している中で、よく使うグラフの1つにTCPストリームグラフというものがあります。こちらの使い方ですが、検索しても中々出てくることもなく、また詳しい説明もないためブログ管理人の方で作成しちゃいました。この記事がお役に立てば幸いです。
どこから開くことができるのか
統計タブ > TCPストリームグラフから開くことができます。
種類について
合計で5種類あります。
本記事では、タイムシーケンス(stevens)とタイムシーケンス(tcptrace)の解説を行います。
その他のグラフについては別の記事で紹介しております。そちらをご覧ください。
タイムシーケンス(Stevens)について
最も基本的なグラフとなります。
Y軸にシーケンス番号、X軸に時間がセットされています。このグラフを見ることで
・おおよそのスループット
・1つのコネクション(ストリーム番号で区別されます）の終了時間
・開始から終了までのスループットの推移
・1つのコネクションでやり取りされたデータの送信に使用したシーケンス数
がわかります(※1)
グラフ例
シーケンス番号とはTCPヘッダに格納される値の一種となります。
ここで、TCPヘッダフォーマットを見てみましょう。
出典：https://monoist.itmedia.co.jp/mn/articles/2004/20/news005_3.html
この番号は、送ったデータ(ペイロード)[Bytes]分だけシーケンス番号が増えていきます。
つまり、時間当たりのシーケンス番号の増え方を見ることでどれくらいの速度で転送されているのかを確認することが可能です。
グラフを分析してみる
例として掲載している図ですが、途中でシーケンス番号が進んでいない箇所がありますね。データ転送開始から8秒～10.5秒の間にまったくパケットが送信されていない状態が発生していることがここからわかります。
まず、青い縦線ですが、これは送信されたデータ(ペイロード)[Bytes]を表しています。
さらに、その中でも●が2つ連続続いている箇所があります。
下図のような箇所です。
これは、受信側（192.168.0.134)からの確認応答(ACK)無しに、送信側(185.206.27.94)がパケットを送信したことを意味します。そして、●から次の●までのX軸の長さは、受信側（192.168.0.134)から要求されたパケットを送信するまでに費やした時間を意味します。
グラフを分析してみる その2
シーケンス番号が下がっている箇所がありますね。本来送られてるはずのパケットが受信側に届いていないためパケットが再送されたことを意味します。図をクリックするとその箇所のパケットをメイン画面で確認することができます。その時のメイン画面が下図となります。
黒色の背景になっている行があります。これは、TCPに関するエラーをWiresharkで確認できたことを意味します。
ここで、TCPエラーについてここに表示されているものをメインに解説をします。
Dup ACK(Dupulicated ACK)
確認応答であるACKを複数回確認できたことを意味します。通常ならばパケットを受け取ったらその確認応答としてACKを返答します。しかし、NWの輻輳が原因で、そのACKで要求しているシーケンス番号のパケットが経路途中で破棄されてしまった場合、送信先はパケットが送られていないことに気づくため再度そのパケットを要求します。後述するTCP Fast Retransmissionの発動契機にもなります。
TCP Retransmission
TCPの再送タイムアウト(RTO：Retransmission Time Out)による再送を意味します。RTOは、往復時間(RTT)によって動的に決定されるため、回線状況次第となります。
TCP Retransmissionで送信されたパケット内のTCP Analysis FlagsでRTOや送信されたデータ(ペイロード)[Bytes]を確認することが可能です。
TCP Fast Retransmisson
Dup ACKを3回以上受信した場合に、RTOを待たずに再送されたことを意味します。
この図からわかることは、パケットを送信側(185.206.27.94)が送ったにも関わらず、受信側（192.168.0.134)で受け取るまでのどこかでパケットが損失したことです。
受信側（192.168.0.134)は何度もこのパケットを送信側(185.206.27.94)にACKを通して要求していますが送られてきません。
そして、RTOに達すると、送信側(185.206.27.94)からパケットが自動的に再送されます。これが図のNo428のパケットとなります。詳細を載せておきます。PSHフラグが有効化されていますね。
さらに、TCPエラーをよく見てみると、SLE(Segment Left Edge)とSRE(Segment Right Edge)という文字がありますね。これは、SACK(Selective ACK)と呼ばれるTCPオプション機能によるものです。
SACK(Selective ACK)は、まだ受信していないセグメントよりも大きいシーケンス番号のセグメントを受信した場合に、それを送信側に伝える機能です。
これを使用することで、受け取っていないセグメントのみを受信側は送信側に伝えることができます。
ここでは、178121-176661 = 1460(byte)のデータを受信側（192.168.0.134)は受け取っていないことがわかります。
また、シーケンス番号176661のパケットが再送されるまでに、シーケンス番号188341までのパケットは受信側で受け取っていることもわかります。
向きを切り替え
「向きを切り替え」ボタンを押すと、送信側と受信側の方向を逆にすることができます。
シーケンス番号が全く進んでいないですね。これは、一方方向からデータをダウンロードしている場合などに見られます。
今回のケースの場合、EVE-NGをダウンロードしている時の通信をキャプチャしているため、このような結果となります。
※1：1つのコネクション当たりのデータ量は統計タブから対話を選択することで確認できます。
TCPコネクション毎に、双方向のパケット総数、データ量(Byte)、送信レート、そして所要時間を確認することができます。例で載せたストリームID1のTCPコネクションでは、約2MBのデータがアドレスBからアドレスAへ、平均送信レート447kbpsで送信されたことがわかります。また、所要時間は25.96秒です。
タイムシーケンス(tcptrace)について
タイムシーケンス(Stevens)と基本的には一緒です。しかし、さらに色々な種類の線が追加されています。
線の色の種類について
4種類あります。青色、黄色、黄緑色、そして赤色です。順番に見ていきましょう。
青色線
stevensのグラフの青色の線と同じで、実際に送信されたパケットのシーケンス番号を表しています。1つ1つの縦線が実際に送られたデータ(ペイロード)[Bytes]となります。
黄色線
こちらは受信側のACKの数を確認することができます。また、とあるシーケンス番号で受領したパケットへの確認応答に費やした時間もわかります。
図では、シーケンス番号56940に対するACKの応答が、1.670121 – 1.6701 = 0.000021秒 かかっていることが確認できました。
また、確認応答を返してから次のシーケンス番号のパケットが送られてくるまでの時間も確認することができます。
黄緑色
受信ウインドウズサイズを表しています。TCPヘッダ内の16bitで表現されます。つまり、63355byteまで受信バッファに空きがあることを送信側に通知することができます。
しかし、65535byteではサイズが小さすぎるため、オプションのwindows scaling factorという値で乗じることができます。
出典：https://monoist.itmedia.co.jp/mn/articles/2004/20/news005_3.html
下図は、受信バッファに常に空きがある状態を表しています。このような場合は、受信側のデータ処理速度に応じたデータ量で転送されているため高いスループットが出ている状態となり、このような状態が続くことが望ましいです。
もし仮に、青い縦線が黄緑色と接する状態が続いている場合は、そのTCPコネクションにおいて、受信側のバッファが足りていないことを意味します。
このような場合は、下記のようなやり取りが発生します。
・受信側：ACK応答時にWindowsサイズを0にして送信。受信バッファに空きがないことを知らせる。TCP Zero Windowというエラーメッセージが確認できます。
・送信側：データの送信を中止します。
・受信側：受信バッファに空きが出来たら、windowsサイズで知らせます。TCP Window Updateというエラーメッセージで確認できます。
・送信側：データの送信を再開します。通知されたwindowsサイズまでデータを送り切ったら、TCP Window Fullというエラーメッセージを確認することができます。
赤色線
TCPに関するエラーが出ていることを意味します。
この図の〇になっている箇所をズームしてみたいと思います。
今回の場合はDup ACKが出ているため赤色の表示されています。
さらにグラフを分析してみる
2つ前の図で〇で選択されているセグメントをメイン画面で確認してみます。
Previous segment not capturedが確認できました。
これは、①wiresharkでパケットのキャプチャに失敗している、②1つ前のセグメントが損失している、のどちらかが原因となります。
赤枠の箇所を見てみましょう。
シーケンス番号402298のパケットが再送されていることが確認できました。
つまり、この番号のパケットが輻輳などが原因で損失したことがわかりました。また、SLEとSREの番号を確認すると、このシーケンス番号よりも大きい値となっているため、このパケットのみが損失したことが確認できました。
さらに、このセグメントが再送されるまでに先に受信したセグメントを確認してみます。#142819のACKが何度も送信されていることが確認できます。
最後に、赤線が表示されているtcptraceのグラフから読み取れることを1つの図で表現したいと思います。
おすすめブログ
ここでは紹介していない、残り3つのグラフについて解説します。
スループットがあがらない…。けど、理由が良くわからない。原因はTCP送信ウインドウサイズの大きさを決める2つの要素にあります。図を用いて丁寧に解説しております。是非、ご覧ください。海外の方からもコメントで称賛していただいております。
コメント