• 締切済み
  • 困ってます

TCP/IP ACKについて

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

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

  • 回答数1
  • 閲覧数791
  • ありがとう数0

みんなの回答

  • 回答No.1
  • foitec
  • ベストアンサー率43% (1079/2453)

受信側が応答するACK番号は、スリーウェイハンドシェイクでは「シーケンス番号+1」ですが コネクションが確立して実際にデータを送受信する段階では、「送信側のシーケンス番号+受信データバイト数」をACK番号として応答するようになります。

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

質問者からの補足

foitec さん、回答有難うございます。 表現がたりなく申し訳有りません。 現在の状態は、スリーウェイハンドシェイク時の問題です。 クライアント SYN = 1 ----> サーバー サーバー ACK,SYN = 1 ----> クライアント(本当はこの時点でおかしいのかも知れませんが、確認で来ていません。) クライアント ACK = 1 ----> サーバー のときにSEQナンバーが2067011292のように 大きな値が出てきて、通信が確立出来ていない状態です。 ちなみにクライアント側のシーケンスナンバーは20000からスタートしています。 他のクライアントソフトでは通信は確立しています。

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

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

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

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

  • ACK信号について

    ACK信号は接続してきたノードに対して送り返す 肯定応答であるという認識なのですが ではもし返送路がなくなってしまった場合はどうなるのでしょうか? 例えば端末Aがサーバに通信をした瞬間シャットダウンしてしまったとするとサーバからのACK信号は一度送信してまた再送するといったような動作なのでしょうか? この場合同時刻に通信をした端末Bがいたら、待たされることになりますよね?また、こういったことが連続して起こったらサーバがダウンしてしまうのではないかと考えております ACK信号が返送路を失った場合、その行き先と動作と負荷についてを教えてください、よろしくお願いします。

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

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

  • FIN,ACKとACKについて

    はじめまして。5月よりTCPソケット通信を勉強しているものです。 クライアントとサーバーのプログラムを作り試行錯誤しながら動かしているのですが一つ不思議な現象が起きたので質問させて頂きます。 処理が終わり、通信を切断する時なのですが、ソケット通信に関連する書籍やWebページを見ていると接続を切断するときにFIN,ACKを送信して相手側がACKを送信し、FIN,ACKを送信して最後にACKを送信するとなっています。図にすると以下のような感じでしょうか。 PCA       PCB FIN,ACK送信 → FIN,ACK受信 ACK受信   → ACK送信 FIN,ACK受信 → FIN,ACK送信 ACK送信   → ACK受信 この手順でPCA,PCBともに切断されるとあるのですが、自分が作ったプログラムを実行させて、etherealでパケットをモニタリングすると以下のような状態で終わってしまいます。 PCA       PCB FIN,ACK送信 → FIN,ACK受信 FIN,ACK受信 → FIN,ACK送信 ACK送信   → ACK受信 PCAからのFIN,ACK受信に対してのACKの送信が省略されて、いきなりFIN,ACKを送信してしまいます。その後PCAからはACKが返されて終了となります。 プログラム的には希望通り動作しているので問題は無いのですが、なぜ途中のACKが省略されてしまうのか原因が知りたいです。また、自分の認識が間違っている場合のご指摘等頂ければと思います。 つたない文章で申し訳ありませんがご存知の方がいらっしゃいましたら教えて下さい。

  • HTTP GET直後のFIN,ACKについて

    ある特定のサイトをWebアクセスした際のWiresharkトレースを解析しています。 そのWebサイトにはTwitterのAPIが埋め込まれていて、Twitterのアイコンを取得するためにJPGファイルを取得しているTCPセッションがあります。 3WAYハンドシェイクの後、クライアントはHTTP GETでJPGファイルを要求しているのですが、直後にFIN,ACKフラグを伴うパケットを送出しています。 クライアントは自らHTTP GETしておきながら、JPGファイルを受け取る前にTCPセッションを終了しようとするのは理解しがたいと思っています。 このようにHTTP GET直後にFIN,ACKフラグをつけるような挙動をみせるのはどのような状況が予想されるでしょうか?

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

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

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

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

  • etherealのinfo[RST ACK]について

    windowsXP SP2 ノートンインターネットセキュリティ2005 ethereal 0.10.12 WinPcap version 3.1 beta4 フレッツADSL―モデム―パソコン(ルーターつきではない) etherealでモニターしていると妙なログを記録します。 それが、RST ACKなのですが、それで検索したところステルススキャンが出てきました。 少し前から、中国のIPアドレスを発信源とするパケットが自分のパソコンの10000以上のポート番号(TCP)で受信され、そのinfoがRST ACKでした。 しかし、今日はいつもやってくるepmapTCP135での受信に対して、その発信源に対する送信を記録しました。自分の発信したものが、infoでRST ACKでした。しかも送信してきた相手にでした。 このような通信は、ノートンの接続ログには記録されません。 その通信はすぐに終わりましたが、ほかからも同じようなepmapがやってきてもこちらは反応しません。 これをどのように解釈したらよいでしょうか。発信源の大部分は、ノートンのネットワーク部分で遮断しています。 私のようなものがここのカテゴリーで質問するのは場違いですが、よろしくお願いします。