• ベストアンサー

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

日吉 龍(@VDSL)の回答

回答No.1

詳しい本を見れば分かりますが、いわゆる3-Way Handshakeの間はアプリケーションのデータは送られません。 アプリケーションのデータが送信されるのは、コネクションが確立されたからになります。 #質問ではパイプと書かれていますが、一般的にコネクションといいます。 データをつけないパケット...というのが意味が良く分かりませんが、MACやIPという意味であれば、送ることはできません。 というか、送ることはできますが、相手先で破棄されてしまいます。

noname#46712
質問者

補足

VDSLさん、貴重なご回答ありがとうございます。「アプリケーションのデータが送信されるのは、コネクションが確立されたからになります。・・・アプリケーションのデータが送信されるのは、コネクションが確立されたからになります。」とありますが、●それではデータを送受信する段階になったとき、アプリデータにMAC,IP、TCPヘッダーを付ける作業をして通信を行い、その前の段階では(3-Way Handshake)MAC、IP、TCPヘッダーしかないパケットで通信する(コネクションを確立する)という認識で正しいでしょうか?

関連するQ&A

  • 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 このような順序になっているように思うのですが、これはなぜなのかご教授頂けないでしょうか? どうぞ、よろしくお願い致します。

  • C言語でTCPの3way handshake

    (C言語)Linuxのpacket socket(socket(AF?PACKET, SOCK_DGRAM, htons(ETH_P_IP))) を使ってTCPの3way handshakeをOSのプロトコルスタックに頼らず自力で挑戦しています。 RFCやほかの技術本をよんでIPヘッダやTCPヘッダの実装は一応できたのですが、肝心のsynパケットを送った後のackパケットが返ってきません。 wiresharkでは問題なくsynパケットと認識できているのですが、きっとどこかに不備があるはずです。 そこでC, C++ Javaでもいいのでこのプログラムの実装例が載っているサイトなどを教えてください。(英語でもかまいません)

  • ソケット通信の送受信遅延-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 + 返信データあり ↓ といった状況です どう解釈すれば良いのでしょうか 遅延の原因はソケットなのかそれ以外なのでしょうか?是非アドバイスをおねがいします。

  • TCPの接続処理と終了処理について

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

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

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

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

  • イーサネットヘッダは特別なのでしょうか

    ネットワークの勉強をはじめたばかりです。 ある本を讀んでいたら、TCP/IPに関して次のようなことが書かれていました。(多少表現は変えています。) 「アプリケーションで作られたデータは、アプリケーション層からトランスポート層のTCPに渡される。 ここでパケットに小分けされ、エラーチェックなどに使うTCPヘッダを付けられてTCPパケットになる。 TCPパケットはインターネット層のIPに渡され、宛て先のIPアドレスなどを含むIPヘッダを付けてIPパケットになる。 續いてIPパケットはイーサネットに渡ってイーサネットヘッダが付くと自然だが、実はそうではない。 イーサネットのためのヘッダもIPが付ける。 つまりIPでは、IPヘッダとイーサネットヘッダの2つを付けるのである。」 この本によると、イーサネットヘッダはIPが付けることになっているようですが、 他の本(とは言っても、そんなに何冊も讀んでいるわけではありませんが。)でこのような記述は見たことがありません。 「イーサネットヘッダはIPが付ける」というのは本当なのでしょうか。 そうだとすると、なぜこのような、「自然でない」仕組みになっているのでしょうか。

  • ノートン

    ノートンのログで「無効な接続上の TCP 非 SYN/非 ACK パケット。パケットを破棄しました」って出るのですが、どういう意味ですか?

  • 通信フローの数をsyn,ack,rst等のフラグで区別できるツールご存知ないですか。

    こんにちは。 RubyもPHPもPerlも使わず、C言語でパケットデータを測量したいと考えています。目的はsynフラグが立っているパケットデータを含む通信フローの数のみの取得です。ackやrstの立っているパケットデータは数えないで、synフラグのみの通信フローを取得したいと考えています。 このような通信フローの数を数えてくれるツールをご存知でしたら教えて頂けないでしょうか。 環境はCentosです。どうぞよろしくお願いします。

  • TCPでのACK確認応答のメカニズム

    TCPでの通信では、3ウェイハンドシェイク後、データ送信とACK確認応答の返答をしあい信頼性のある通信を行うと思うのですが、あるテキストによるとネットワークの関係上、順番どおりにTCPセグメントが届かない場合があるとの事でした。 データ受信ホストが発するACK確認応答の中に次の送信のシーケンス番号が指定されているともありましたので、TCPセグメントが順番どおりに来ないと通信が上手くいかないと思うのですが、思い違いでしょうか? このあたりのやり取りについて、教えて頂けないでしょうか?是非お願いします。