• ベストアンサー
※ ChatGPTを利用し、要約された質問です(原文:WiresharkのFlow Graph)

WiresharkのFlow Graphとは?TCP通信の3ウェイハンドシェイクのパケットやりとりを観測

このQ&Aのポイント
  • WiresharkのFlow Graphは、クライアント端末とサーバー端末のTCP通信のパケットやりとりを観測する機能です。
  • 通常、TCP通信の3ウェイハンドシェイクはSYN→SYN ACK→ACKという順序で行われますが、実際に観測したパケットではPSH, ACK→PSH, ACK→ACK→ACKという順序になっていました。
  • なぜこのような順序になっているのか、詳しい理由を教えていただけると助かります。

質問者が選んだベストアンサー

  • ベストアンサー
  • Wr5
  • ベストアンサー率53% (2177/4070)
回答No.2

>ip.dst == 192.168.1.222 || ip.src == 192.168.1.222 一応、正しい…ですかねぇ。 Flow Graphではなく、WireSharkの画面ではどうなっていますか? パケットキャプチャから漏れた…という可能性も捨てきれない…というところでしょうか……。 さもなくば…… 既にハンドシェーク終わった後からキャプチャしていた…という可能性もありますかね。 # 対象アプリ(サーバアプリ)を終了している状態からキャプチャ開始するとか。

techhouse
質問者

お礼

回答頂きありがとうございます。ハンドシェイクし終わったら、その後はやらないんですね。常にTCPは3wayハンドシェイクをしている物だと思っていました。

全文を見る
すると、全ての回答が全文表示されます。

その他の回答 (1)

  • Wr5
  • ベストアンサー率53% (2177/4070)
回答No.1

Flow Graphで表示する前の、フィルタ条件がおかしかった…ということはありませんか? 手元の環境(WireShark 1.8.2とLinuxで動作しているPOP3サーバ)でキャプチャして、 ip.addr == 192.168.1.250 でフィルタしてからFlow Graphで表示すると、ちゃんと3ウェイハンドシェークしていますよ。 # クライアントPCが192.168.1.2(Win7 64Bit) # POP3サーバが192.168.1.250でDebian。 全角空白とかで成形したけど、ちゃんと見えるかなぁ…。 # ズレてたらテキストエディタなどに貼り付けてください。固定ピッチフォントの。 |Time | 192.168.1.2     192.168.1.250 | |3.702|     SYN           |Seq = 0 |   |(52553) ------------------> (110)| |3.702|     SYN, ACK         |Seq = 0 Ack = 1 |   |(52553) <------------------ (110)| |3.702|     ACK           |Seq = 1 Ack = 1 |   |(52553) ------------------> (110)| |3.703|     PSH, ACK - Len: 20    |Seq = 1 Ack = 1 |   |(52553) <------------------ (110)| フィルタをip.dst == 192.168.1.250にしてからだと… # キャプチャし直したものなのでTimeは異なりますが…。 |Time | 192.168.1.2     192.168.1.250 | |2.118|     SYN           |Seq = 0 |   |(52557) ------------------> (110)| |2.118|     ACK           |Seq = 1 Ack = 1 |   |(52557) ------------------> (110)| |2.120|     PSH, ACK - Len: 6    |Seq = 1 Ack = 21 |   |(52557) ------------------> (110)|

techhouse
質問者

お礼

回答頂きありがとうございます。 私は 192.168.1.111(クライアント端末) <---> 192.168.1.222(サーバ端末側) この端末間のパケット通信を ip.dst == 192.168.1.222 || ip.src == 192.168.1.222 このようなフィルター条件でdisplayしました。 たぶんこれで、 192.168.1.111(クライアント端末) <---> 192.168.1.222(サーバ端末側) この端末間の通信は全部表示できているんじゃないかと思うのですが、 もし間違いありましたらご指摘頂けるとありがたいです。

全文を見る
すると、全ての回答が全文表示されます。

関連するQ&A

  • wiresharkの見方がよく分からない(3ウェイハンドシェイク)。

    wiresharkを使って(遊んで?)、ネットワークの勉強をしているのですが(『実践 パケット解析』という本を読んでいます)、いまいち見方がよく分かりません。ネットワークの知識が乏しいせいかもしれませんが。 例えば、TCPの接続で、3ウェイハンドシェイクというものがあると思うのですが、その時のinfoで、 2580>http [syn] seq=0 Len=0 MSS=1460 という、表示があります。多分、一番最初のSYNパケットを送っているところだと思うのですが、なぜ最初にhttpという表示があるのでしょうか?まず、TCPで3ウェイハンドシェイクで行って、セッションを確立してからhttp…だと思っているのですが…。また、2580>の意味もよく分かりません。本には、この部分は触れられていませんでした。 よろしくお願いします。

  • BBルータでTCP通信のデータ部が捨てられている?

    インターネット上のServerと自宅PC間でWebを併用したデータ交換をしているのですが、ある限られたデータ部のみ、自宅のBBルータにより毎回捨てられているようで受信できません。 Serverと自宅PC(Client)にEtherealを同時に仕掛けPacketをモニタリングしました。 Server側のLogを見る限り、Serverは該当データを正しく送り、BBルータも正しく受信しているようです。 しかし、Client側のLogを見ると、その部分は Len=0 になっており、ヘッダ部だけのPacketが送信されて来たかのようになっております。 BBルータの設定可能項目では、いたって通常の設定になっており、また、自宅PCはWindowsXP SP2でFirewallはOff、ウィルス対策ソフトもアンインストール状態で実験しております。今回のトラブル以外は全てにおいて不具合は発生しておりません。 何か単純なTCP規則違反に該当しているのではとRFC793も確認したのですが原因がわかりません。 該当部分のEtherealのLogは以下の通りです。 何か大事なことを忘れていそうなのですが、どなたかご教授をお願い致します。 <Server側Log> ※No.292~294は3way handshakeです。 ※()内はTCP詳細部の内容抜粋です。 ※Server側のPortはWeb併用なので80番をそのまま使用。 No. SRC  DIST  Prot  Info 295 Client Server HTTP Continuation or non-HTTP Trafic 296 Server Client HTTP Continuation or non-HTTP Trafic (http > 62327 [PSH,ACK] Seq=1 Ack=24 Win=65512 Len=90) 297 Server Client TCP http > 62327 [FIN,ACK] Seq=91 Ack=24 Win=65512 Len=0 298 Client Server TCP 62327 > http [ACK] Seq=24 Ack=92 Win=65535 Len=0 299 Client Server TCP 62327 > http [FIN,ACK] Seq=24 Ack=92 Win=65535 Len=0 300 Server Client TCP http > 62327 [ACK] Seq=92 Ack=25 Win=65512 Len=0 <Client側Log> ※No.295と297~300はServer側Logと矛盾はありません。 No. SRC  DIST  Prot  Info 296 Server Client TCP http > 1157 [PSH,ACK] Seq=1 Ack=24 Win=65512 Len=0 以上

  • TCP/IP通信3ハンドシェイクについて

    TCP/IPのTCP通信の3ハンドシェイク通信に関して質問なのですが、インターネットを使ったある端末でセンターのサーバーと6秒に1度程度3ハンドシェイク通信を行ってインターネット回線が正常かどうかを判定する機能を持っているそうなのですが、その時に1回の通信でどの程度のパケットをやり取りしているのかということを質問してみたら、約1.2kbyte程度のパケットをやり取りしていると業者の方が言っていました。 ちょっと興味があってWireSharkでこの端末とサーバ間のパケット通信をのぞいてみたところ、端末が1.2kbyte送信していたのですが、サーバからのACKと思われるパケットが1.2kbyteのパケットを返してきていて、再度端末が60バイト程度のパケットをサーバのIPアドレスに送信していました。 私はてっきり、端末とサーバー間のこの3ウェイハンドシェイクのパケットの総量が1.2kbyteだと思っていたのですが、これだと1.2k + 1.2k + 60 = 2.46kbyteとなると思うのですが、パケットのやり取りとしては正しいのでしょうか? サーバー側が受信したら同じ容量の1.2kbyteのデータをACKとして返してきているように思うのですが、Wiresharkで見ても全く同じデータでは無いようでした。サーバはデータを受け取ったら、ちゃんと受信したという1 or 0のデータみたいなものを返せばよいだけだと思うのですが、理由はあるのでしょうか?

  • 3ウェイハンドシェイクの流れを変える方法

    OS「fedora 5」、言語「C」で、ソケットプログラミングを使い、3ウェイハンドシェイクの流れ <3ウェイハンドシェイク> クライアント     サーバ  syn    →→→        ←←← syn/ack  ack    →→→ これを クライアント     サーバ   syn     →→→         ←←←  rst         ←←←  syn syn/ack   →→→         ←←←  ack の流れにしようと考えています。 参考書を読んだり、ソケットプログラムのことについて調べたのですが、お手上げ状態です。 コントロールフラグの変更の仕方はどうやるのでしょうか? また理論上は3ウェイハンドシェイクを変えることきているのですが、実際は流れ自体変える事は不可能なことなのでしょうか?

  • 3ウェイハンドシェイクについて

    TCP通信を行う場合、3ウェイハンドシェイクでパイプをつくるようですが、その始め(通信の始め)にSYNを送り、その返信にACKを返す仕組みになっていると思います。そのSYNを送るときに、MAC、IP、TCPヘッダーをつけたパケットを送ると思うのですが、アプリが作ったデータもまた送るのでしょうか?通信できるかどうかを確かめるだけなら最初の通信はデータが必要ないと思うのですが・・・。また、データをつけないパケットなども送ることができるのか(フォーマットに合わないような気が・・・)どうかもあわせてお願いします。

  • windowsでSYN/ACKを返すプログラム

    以下の現象が発生して、大変困っております。 <現象> クライアントからhttpsアクセスをしようとして、 ブラウザに「ページが表示できません」エラーとなることがある。 <調査状況> クライアント、OS上でWireSharkを仕掛けて、TCPの通信をキャッチしたところ、 問題が発生した通信は「SYN」がOSまでは来ているが、 「SYN/ACK」が返ってきていない。 <環境> サーバ:windows2003server,Apache クライアントOS:WindowsXP <質問内容> クライアントからの「SYN」要求に対して、「SYN/ACK」を返すのは、具体的に何が返しているのでしょうか。 (windowsのソケットプログラム?) また、その調査方法があれば教えて頂けないでしょうか。 よろしくお願い致します。

  • Wiresharkでみるときの、1回のパケット

    Wiresharkでみるときの、1回のパケットを追う方法を探してます。 TCP通信にて、通信確立後にデータのやり取りをしている通信を数時間tcpdumpにて取得し、 Wiresharkで流れをみています。そのときに、1回のデータのやり取りと見るために方法を教えてください。 クライアントからのリクエストとサーバからのレスポンスで、 1回目クライアントからデータ送信し、 複数かいやり取りして、終了(200 OKを返却して) 2回目クライアントからデータ送信し、 複数かいやり取りして、終了(200 OKを返却して) という動作を繰り返してますが、 この1回目がここからここまでのパケット、2回目がここからここまでのパケットと知りたいのです。 なんとなくみると、ストリームNoなどもありますが、 ストリームNoが1回の通信後とのNoかとおもったら、 ストリームNoでフィルタしたら、 1回目5回目8回目・・と複数回のものが同じストリームNoであり、 どうゆうことだとうと疑問になってます。 詳しい方よろしくお願いします。

  • ソケット通信の送受信遅延-02 その後

    前回のNo.1031658 「ソケット通信の送受信遅延」に追加させてもらいます その後、プロトコルアナライザで現状調査を行い以下の現象を確認しました ◇正常時  サーバがメッセージ送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  0.2msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓  10msecで サーバが送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  0.2msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓          以下繰り返り ◇不具合時  サーバがメッセージ送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  0.2msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓  10msecで サーバが送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  約130msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:0 + 返信データなし ↓  約250msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ といった状況です どう解釈すれば良いのでしょうか 遅延の原因はソケットなのかそれ以外なのでしょうか?是非アドバイスをおねがいします。

  • Wiresharkのフィルター条件

    現在、事務所内に設置したサーバー端末(ip = 192.168.1.120)とクライアント端末(ip = 192.168.1.140)の通信パケットをモニターするために、2日程度のパケットログデータのWiresharkのデータがあります。 この2つの端末間のみのパケットで、かつ、昨日の夜20:00以降のパケットのみを抽出するフィルター条件式はどのように設定すれば良いか教えて頂けないでしょうか? どうぞ、よろしくお願い致します。

  • TCPパケット解析

    下記は、何を使用としているのかを、解析したいと思っています。 Source / destination /protocol /length /info A / B / TCP / 54 / 10085-80 (ACK) Seq=572 Ack=2032 win=65700 Len=0 B / A / TCP / 54 / 80-10085 (FIN, ACK) Seq=2032 Ack=572 win=6992 Len=0 A / B / TCP / 54 / 10085-80 (ACK) Seq=572 Ack=2033 win=65700 Len=0 A / B / TCP / 54 / 10085-80 (FIN, ACK) Seq=572 Ack=2033 win=65700 Len=0 B / A / TCP / 54 / 80-10085 (ACK) Seq=2033 Ack=573 win=6992 Len=0 素人に説明出来る方、宜しくお願い致します。

このQ&Aのポイント
  • ET-M571Tでカラー印刷をする際に、色が縦方向にズレて印刷される問題が発生しています。
  • 白黒印刷では問題なく、ノズルチェックも正常に行われているため、原因がわかりません。
  • EPSON社製品であるET-M571Tのカラー印刷時にY、M、Cの順に1cm程度ずれて印刷される現象について、解決策をお教えください。
回答を見る