• 締切済み
  • すぐに回答を!

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フラグをつけるような挙動をみせるのはどのような状況が予想されるでしょうか?

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

  • 回答数2
  • 閲覧数1447
  • ありがとう数1

みんなの回答

  • 回答No.2

お使いのブラウザが複数のTCPコネクションを張っているからではないでしょうか。 例えばHTMLをダウンロードするための接続を終了している部分を、質問者がアイコンの取得のための接続を終了していると勘違いしていると予想します。 特定のサイトをアクセスする際に使ったブラウザの名前やOSがわからないとこれ以上はなんとも言えませんが。

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

質問者からの補足

ご回答いただきありがとうございます。 まず、OSとブラウザはWindows 7、IE9でした。 >お使いのブラウザが複数のTCPコネクションを張っているからではないでしょうか。 IEでは単一タブでそのサイトのみアクセスしている状態でした。 HTTPですので、複数のTCPコネクションは張ることになると考えています。 >例えばHTMLをダウンロードするための接続を終了している部分を、質問者がアイコンの取得のための接続を終了していると勘違いしていると予想します。 特定のJPGファイルをGETするために新たにTCPコネクションを張っています。

関連するQ&A

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

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

  • RFC793 TCPのコネクション解放について

    TCPのコネクションを解放するときの手続きについて、 フラグの意味がわからない部分があります。 A────────B  →FIN,ACK→→→   (1)  ←←←←←ACK←   (2)  ←←←FIN,ACK←   (3)  →ACK→→→→→   (4) 上記の手続きにより、コネクションの解放が完了しますが、 (2)は(1)に対しての肯定応答だとわかるのですが、 (3)のACKの意味がわかりません。 何に対して応答しているのでしょうか? Bは2連続でACKを送っている理由、決まりがわかりません。 RFCには「FINとセットでACKを送らなければならない」とは書いていませんので、 決められたものではないと解釈しております。 では、なぜFINとセットでACKを送るかがわかりません。 (1)のACKについては、今までのやり取りに対するACKと解釈しており、 問題視しておりませんが、ここの解釈が間違っていたら訂正お願いします。

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

  • 回答No.1
noname#174784

HTTPはCUNTです。

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

質問者からの補足

ご回答いただきありがとうございます。 恐れ入ります、CUNTとはどのような意味でしょうか?

関連するQ&A

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

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

  • 「HttpSendRequest」の異常終了の原因について

    プログラム環境は「WinXP SP3 + VB2008 Express Edition」です。 Webサーバ上のファイルを取得するプログラムを作成しています。 「VB6」で「Inet/OpenURL」を使用して実現していた機能を「WinInet.dll」を使用して実現したいと思っています。 その処理の途中の「HttpSendRequest」で異常終了してしまいます。 「エラーコード:2(ERROR_FILE_NOT_FOUND:The system cannot find the file specified.)」です。 「Wireshark」でPCとサーバの交信をチェックしたところ、「Inet/OpenURL」でうまくいった時と、「HttpSendRequest」でうまくいかない時に違いが見当たりません。「HTTP:GET」に対して「HTTP:200 OK」が返ってきます。TCPでも「SYN-->ACK」で始まって、「FIN-->ACK」で終っています。交信は正常に行われているのに、「HttpSendRequest」の内部の処理でエラーにしているように見えます。(例えば、「HTTP:GET」~「HTTP:200 OK」でPCとサーバの間でパケットのやり取りがありますが、その回数が限界値を超えたため、エラーにしてしまうような処理があれば、エラーになりそうです。このあたりがわかりませんでした。) また、この「HttpSendRequest」が異常終了する事態は「GET」の対象が「*.php」の場合に発生します。「GET」の対象が「*.html」「*.jpg」「*.zip」の場合には、正常終了して、ファイルが正常に取得できます。「GET」の対象が「*.php」の場合に「HttpSendRequest」を実行する前に何か設定が必要なのでしょうか? よろしく、お願いいたします。

  • パケットキャプチャについて

    パケットキャプチャについて wiresharkでパケットキャプチャをやっております。tcpでsynのパケットのみを収集したいのですが、現在では、 (1)ファイルの読み込み (2)フィルタの条件でtcp.flag.fin == 0 and tcp.fla.syn ==1 and tcp.flg.ack == 0 と入れフィルタリング。 (3)結果のファイルを保存 となって大変時間がかかります。cuiでコマンドライン上で一発ですませられる方法はありませんか?

  • HTTPアクセスの処理

    HTTPで「http://www.yahoo.co.jp」にアクセスしようとした場合、どのような内部処理が行われるのでしょうか? 大まか流れとして 1・DNSによる名前解決 2・TCPセッションの確立 3・HTTP要求 と考えてます。(ARP解決は省略します) 1・DNSによる名前解決 プロトコルスタックの流れだとHTTP→DNS→TCP→IP→Ethernetでネットワークに送信され、応答がEthernet→IP→TCP→DNSになると思います。 2・TCPセッションの確立(省略) SYN→SYN ACK→ACK 3・HTTP要求(省略) HTTP GET→HTTP 200 OK わからない部分は1・DNSによる名前解決が終わったあとどうやって2・TCPセッションの確立に移行するのかということです。 (同様に2・TCPセッションの確立が終わったあとに3・HTTP要求)

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

  • 3wayハンドシェイクによるSYN+ACKがNG

     ■接続状況  <クライアント(1)>──<L3SW(2)>──<LB(3)>──<VPN装置(4)>──&#65374;&#65374;──>   ─>──&#65374;&#65374;──<FTPサーバ(Solaris)(5)>  ■環境   (1):Linux(red hat v5.6)   (2):Catalyst L3SW   (3):LB(ロードバランサー:NAT変換含む)   (4):VPN装置   (5):対向先のFTPサーバ(Solaris)  ■業務接続状況   5分周期のバッチで動いている。   クライアント(1)⇒対向先(5)のFTPサーバに対して、FTP接続をしており   ファイルのrename等を実施している。(TCP接続)  ■障害状況   1ヶ月に2,3回の割合で、クライアントSVから対向先へのFTP接続において   FTPエラーが発生している。     ■調査状況   <各キャプチャ設定状況>   (1)クライアントSVにて、tcpdump取得、I/F調査の観点でNIC周り調査   (2)L3SWに対しては、ミラーポートキャプチャーをしかけ、キャプチャを採取   (3)LBに対しても、対象IPアドレス、ポートを絞ってネットワークキャプチャを採取    (4)VPNに対しても、対象IPアドレス、ポートを絞ってネットワークキャプチャを採取   FTPエラー時のパケットキャプチャを見ると、3Wayハンドシェイクにおける   対向先(5)からのSYN+ACKがクライアントSV(1)に届いていない状況が判明。   クライアントSVからのSYNに対して、対抗先のFTPサーバからの応答で   SYN+ACKがL3SW(2)から出力している(届いている)ところまでは確認済み。   途中経路のLB、VPN含め、パケットドロップ等のエラーカウントアップは   されていないのも確認。   肝心のクライアントSVのNICドライバー層を確認するもパケットドロップも   カウントしていない為、OSとしては、受け取っていない状況。      FTPエラー時のパケットを見ると、必ずクライアントSV側で5万台の   特定ソースポートで接続するときに限って、SYN+ACKが届いていないことが分かった。   他のPort取得時は正常にFTP処理されている。   ただし、OSやNW専門部署に確認するも特定Portのみ、3Wayハンドシェイクが   確立しないような設定や事例もないの見解を聞いており、手詰まり状態となっている。   特定のPortに関しては、クライアントSVのLinux(OS)が自動で採番できる   Port範囲からrandomで取得しているPort番号なのは分かっている。   また、その特定Port番号に関して、アプリ観点等で固定のPort指定や、   エラー発生前に違うプロセスが掴んでしまっているような   競合もとくに見受けられなかった。(定期的に取っているnetstatコマンドより)   似たような事象に陥った方で、何か手がかりになりそうなヒントがあれば   ご教授いただけると助かります。

  • 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が省略されてしまうのか原因が知りたいです。また、自分の認識が間違っている場合のご指摘等頂ければと思います。 つたない文章で申し訳ありませんがご存知の方がいらっしゃいましたら教えて下さい。

  • 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 以上

  • httpsのページがIE 7で表示できません

    httpsのページがIE 7で表示できません。 表示できないページは、apache version 2.2系で自分で建てたサーバーです。 オレオレ証明書に使ったopensslのversionは0.9.8e, private keyの鍵長は、 1024でも2048でもだめでした。 また、mozilla firefox 3.0では同様に証明書の警告が出ますが、 例外設定をすることで表示されることを確認しています。 IE 7の現象としては、 "この Web サイトのセキュリティ証明書には問題があります。" - (A) と警告が出て、閲覧を続行すると "Internet Explorer ではこのページは表示できません" - (B) といわれます。 このとき、wiresharkでパケットのダンプを見てみると、 (A), (B)の通信が両方とも以下のようなシーケンスになっていました。 1, client -> server : tcp syn 2, server -> client : syn, ack 3, client -> server : syn 4, client -> server : client hello 5, server -> client : server hello, change cipher spec, Encrypted Handshake message 6, client -> server : change cipher spec, encrypted handshake message 7, client -> server : FIN ACK 8, server -> client : ACK 9, server -> client : encrypted alert 10, server -> client : FIN ACK 11, client -> server : RST ACK [ client: IE 7 ], [ server: apache22 ] 7の段階でIEからFIN ACKを送っているためページを表示できないのだと思うのですが、 なぜFIN 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でもいいのでこのプログラムの実装例が載っているサイトなどを教えてください。(英語でもかまいません)