• ベストアンサー
  • すぐに回答を!

WiresharkのFlow Graph

現在WiresharkのFlow Graphという機能を使用して、クライアント端末がサーバー端末へのTCP通信での3ウェイハンドシェイクのパケットやりとりを観測したいと思っています。 次のようなパケットをモニターしました。 |Time | 192.168.1.111 | | | | 192.168.1.222 | |6.402 | PSH, ACK - Len: 1212 |Seq = 1 Ack = 1 | |(6057) ------------------> (5000) | |6.606 | PSH, ACK - Len: 1212 |Seq = 1 Ack = 1 | |(6057) ------------------> (5000) | |6.835 | PSH, ACK - Len: 1212 |Seq = 1 Ack = 1213 | |(6057) <------------------ (5000) | |7.039 | ACK | |Seq = 1213 Ack = 1213 | |(6057) ------------------> (5000) | |7.150 | ACK | |Seq = 1213 Ack = 1213 このパケットのやりとりを観ていて思ったのですが、TCP通信は3ウェイハンドシェイクは SYN--->SYN ACK---> ACK という順序でのパケットのやりとりをクライアントとサーバー間で行うと思っていたのですが、 PSH, ACK ----> PSH, ACK ----> ACK ----> ACK このような順序になっているように思うのですが、これはなぜなのかご教授頂けないでしょうか? どうぞ、よろしくお願い致します。

共感・応援の気持ちを伝えよう!

  • 回答数2
  • 閲覧数1844
  • ありがとう数3

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

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

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

共感・感謝の気持ちを伝えよう!

質問者からのお礼

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

関連するQ&A

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

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

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

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

  • 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のデータみたいなものを返せばよいだけだと思うのですが、理由はあるのでしょうか?

その他の回答 (1)

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

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)|

共感・感謝の気持ちを伝えよう!

質問者からのお礼

回答頂きありがとうございます。 私は 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

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

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

  • 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 素人に説明出来る方、宜しくお願い致します。

  • 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の接続処理と終了処理について

    TCPでコネクションを確立するとき、制御フラグでSYN、SYN+ACK、ACKで3パケットをやりとしますが、終了手順のときは、FIN、ACK、FIN、ACKと4パケットをやりとりします。 これは何故でしょうか? コネクション確立時と同じく、FIN、FIN+ACK、ACKにしないのは何故でしょうか?教えてください。

  • ソケット通信の送受信遅延-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以降のパケットのみを抽出するフィルター条件式はどのように設定すれば良いか教えて頂けないでしょうか? どうぞ、よろしくお願い致します。

  • WinsockによるUDP通信にて

    WinsockでUDP通信を行うプログラムを作っているのですが、 原因不明の問題が発生していて困っています。 通信手順は以下のとおりです。 (1) クライアントからサーバへ要求パケット送信 (2) 要求パケットを受け取ったサーバは、クライアントへACKを送信 (3) サーバが要求に対する応答パケットをクライアントへ送信 (4) 応答パケットを受け取ったクライアントは、サーバへACKを送信 クライアント-サーバ間でやりとりするデータは最大で992バイト、 それ以上になる場合は、分割して送信します。 パケットの分割が発生しない場合は、(1)~(3)がパケットの損失もなく通信できるのですが、 パケットの分割が発生する場合には、2回目以降の(4)のパケットがクライアントに届きません。再現率は今のところ100%です。 クライアント側のselect関数でもソケットを検出しません。 たしかにUDPは信頼性が低いですが、パケット分割が発生しないパターンでは100%届くので、UDPの仕様とは関係ないような気がします。 原因がさっぱりわからないので、アドバイスをお願いいたします。 ちなみに、クライアント、サーバともに同一端末内にあります(双方がループバックアドレスに対してパケットを送信)が、 これはテスト段階だからであって、本来はそれぞれ別々の端末で動作します。

  • TCP/IP ACKについて

    初めて質問させて頂きます。 現在WinpCapを使ってTCPの通信プログラムを作成しています。 単純にパケットの受信や送信は出来たので、ローカルサーバーに接続出来るか試しているのですが、通信が確立しません。 状況としては、こちらからSYN = 1でサーバーに信号を送ると、サーバーから返事が来ます。 サーバーの返事を待ってACK = 1でサーバーに返事をするのですが、そのときの状態をWiresharkで確認すると、ACKの番号が2067011292等と表示されて通信が確立しません。 ACKの値が異常なのは判りますが、この数値はどこから来るのか、又対処方法などが有りましたら教えてください。 環境はVC2003、WInXP/Win7です。

  • FINパケット、RSTパケットが返却される理由?

    アパッチのヘルスチェックにて、パケットをみました。 シーケンス番号を追っていきましたが、下記のような 通常ではない動作がありました。 <ケース1> (1)サーバからのHTTPのGETに対して、クライアントがFIN.ACKパケットを返却する。 (2)サーバがFIN.ACKパケットをクライアントに送る。 (3)クライアントからRSTパケットが返却される。 ※RSTパケット内にて、broken tcpとの記載あり <ケース2> (1)サーバからのFIN.ACKパケットに対して、クライアントからRST.ACKパケットが返却される。 ・質問1 それぞれについて、正常な動作とはおもえないのですが、 異常でしょうか? ・質問2 FIN.ACKパケット又はRSTパケットが返却されるのはどんな場合が想定されるのでしょうか? ・質問3 FIN.ACKパケット→RST.ACKパケットは異常な動作でしょうか? よろしくお願いします。

  • C++言語でのWinsock2を使用したパケットモニタの作成

    こんにちは 現在Winsock2を使用したパケットモニタを作成しています パケットを受信できるプログラムは作成することができましたが、TCPパケットが期待した順番通りに受信できません 例えば、3WAYハンドシェイクのパケットのやり取りで、期待しているパケットの受信順は 1. host ---> net: SYN 2. host <--- net: SYN,ACK 3. host ---> net: ACK ですが、パケットモニタでは以下の順番でパケットを受信しています 1. host ---> net: SYN 2. host ---> net: ACK 3. host <--- net: SYN,ACK hostから送信されるパケットが先に受信されているような感じですが、これらを時刻順に受信するオプションなどはあるのでしょうか? もしあるならどのように設定すればよろしいのでしょうか? (ソケットなどの設定内容) 初期化  WSADATA wsd;  WSAStartup(MAKEWORD(2, 2), &wsd) ソケット作成  SOCKET sock;  sock = WSASocket(AF_INET, SOCK_RAW, IPPROTO_IP, NULL, 0, WSA_FLAG_OVERLAPPED) 無差別受信モードに設定  int op = RCVALL_ON;  WSAIoctl(sock, SIO_RCVALL, &op, sizeof(op), NULL, 0, &dword, NULL, NULL) パケットの受信  WSABUF wsb;  DWORD len = 0;  DWORD flag = 0;  WSARecv(sock, &wsb, 1, &len, &flag, NULL, NULL)