• 締切済み
  • 困ってます

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と解釈しており、 問題視しておりませんが、ここの解釈が間違っていたら訂正お願いします。

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

  • 回答数2
  • 閲覧数777
  • ありがとう数0

みんなの回答

  • 回答No.2

まず、パケット(1)(3)は、FINとACKで別々のパケットという わけではなく、FINフラグとACKフラグ両方が立っている1つのパケット であるということに注意してください。 さらに、RFC793, 3.1 Header Formatにはこのような事が書かれています。 Acknowledgment Number: 32 bits If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent. つまり、最後のセンテンスに書かれているように、規格としてはTCPコネクション が一旦確立すると、常にACKフラグを立て、Acknowledgment Numberフィールドに しかるべき値を書き込むことになっていており、それは閉じようとしている コネクションについても例外ではありません。 コネクション終了の遷移パターンにより、確かにFINについているACKにあまり意味が無い 場合と、意味がある場合の両方があり得ますが、いずれにせよFINフラグが立って いるパケットがACKが兼ねていても特に害はない(パケット数やパケットサイズが 増えるわけではない)ので、上記のように決めていると考えられます。 むしろ、遷移パターンによってACKフラグ立てるかどうかを条件分岐するほうが 実装上大変でしょう。

参考URL:
http://tools.ietf.org/search/rfc793

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

関連するQ&A

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

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

  • TIME_WAIT 時の振る舞い

    現在、詳解 TCP/IP Vol.1 の第 18 章を読んでいます. P.275 の 2MSL 待ち状態の説明なのですが, 「MSL 値を実装する場合のルールは,TCP がアクティブクローズを実行し,最後の ACK を送ったとき,コネクションは MSL が2回繰り替えされる時間だけ TIME_WAIT に止まっていなければいけないというものだ.これにより,最後の ACK が消失した場合(この場合,他方のエンドはタイムアウトし,最後の FIN を再転送する)でも,TCP は再度 ACK を送ることが可能になる」 「コネクションが 2MSL 待ちにあるときに遅れて到着したセグメントは、いかなるものでも破棄される」 と書いてあります. 前者にある,再転送された FIN も破棄されるのですか? 破棄されるのに,それに対する ACK を送ることは可能なのですか?可能と書いてあるだけで,実際には,再転送された FIN に対する 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 以上

  • 回答No.1

これは、RFC793の「3.5. Closing a Connection」 「Figure 13.Normal Close Sequence」の図に対する質問ですよね? これについては「Figure 6.TCP Connection State Diagram」の状態遷移図 にもある通り、「CLOSE_WAIT」状態でCLOSEが来たらFINを送信する (FIN,ACK送信ではない)ようになっていますので、ACK送信は本来不要なもの だと思います。 別の解説書では、FINだけ送信するように解説されているものも見られます。 (参考) http://www.atmarkit.co.jp/ait/articles/0401/29/news080_3.html ただ、Fig.13のシーケンスは、あくまで例であり、FINにACKをつけて送ることも 間違いではありません。 (この場合(3)のACKは、(1)のFINに対する(2)のACKの再送です。) では、なぜFINにACKをつけたシーケンス例が出ているかというと 私の推測ですが、 1.FIN送信時は、常にACKを付与して送信する処理にした方が、状態に応じて ACKをつける/つけないの判断をするより処理が簡潔で確実になるし副作用もない。 2.仮に(2)のACKがロストした場合でも(3)のFINにACKがついていれば 切断シーケンスをそのまま進められるメリットがある。 といったようなことを考えて、FINにACKをつける実装をしてもよいということを 示したかったのではないかと思います。

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

関連するQ&A

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

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

  • 80番ポート(TCP,UDP)の意味

    パケットフィルタリングの設定のために、許可するプロトコル/ポートを調査しています。 Wikipedia「TCPやUDPにおけるポート番号の一覧」によると、「80/TCP,UDP」のようにTCPとUDP両方記載されているものがあります。 私は80番ポート(HTTP)はTCPのみ使用していると思っていましたが、この表記によるとUDPも使用していると解釈できます。 80番ポートに限らず、22(SSH)、25(SMTP)なども同じ表記となっていますが、これはどういう意味なのでしょうか? 個人的には以下の3パターンのいずれかに分類されるのではと考えています。 ■80(HTTP)を例にとったパターン 1.HTTP通信はTCP、UDPどちらのプロトコルでも使用可能 (ソフトウェアはどちらのプロトコルが来ても対応できる) 2.HTTP通信はTCP、UDPの両方を使用している (ソフトウェアが必要に応じてプロトコルを使い分けている) 3.HTTP通信をTCP、UDPのどちらで実装するかはソフトウェアによって異なる ポートによって上記パターンのいずれになるかは異なりと考えられますので、TCPとUDP両方記載されているものは、両方セットでフィルタに設定しようと考えていますが、その判断について基準などがあればご教示をお願いいたします。

  • TCPコネクションについて

    はじめまして 宜しくお願いいたします。 以下ご質問させてください。 TCPコネクションについて クライアント⇔サーバ間通信において、 ポート21からポート80(HTTP)に対してTCPコネクションをオープン することはできるのでしょうか? (クライアントポート21からサーバポート80に対してアクセスする ことってできるのでしょうか?) 自分の認識では・・・ TCPクライアントはダイナミック(OSが割り当てたランダムなポート。しばしば1024から4000の間)にポートを選択すると認識しているので が。 最初にFTP通信をおこなっており、その継続セッションでHTTP通信をおこなうといった場合にそういった使い方をするのでしょうか? 以上 宜しくおねがいいたします。

  • TCPのコネクションについて。

    TCPのコネクションがよくわかりません。 3ウェイハンドシェークでお互いに通信するのを了承しあう、という説明がよくあると思うのですが、それをしたのがなぜコネクションになるのでしょうか?それをしないでデータを送っても破棄されるということでしょうか? よろしくお願いします。

  • 自己肯定って?

    唐突な質問ですみません。 (カテゴリーが違うかもしれませんね) 『自己肯定』ってどう言う意味ですか。 言葉だけを読むと、自分を肯定すると解釈できるのですが、 自分のすべてを肯定できる人はいないと思います。 そもそも、私自身、どこを肯定して良くて、どこを否定(訂正、修正)すべきかさえわかっていません。 『自己肯定』とは、どう言ったケースで使う言葉ですか。 (どのような言葉で質問したら、私の疑問を伝えられるかわかりません。) 支離滅裂ですみません。 『自己肯定』についての参考文献、資料、URLなどを教えていただけたらありがたいです。

  • 無線のパケットキャプチャにおけるプロトコルについて

    パケットキャプチャソフト(OmniPeek)を使用して802.11(無線)のパケットキャプチャを取得しています。 取得しているパケットキャプチャにプロトコルが表示されるのですが、”CFE"と言うプロトコルが表示されていますが、このプロトコルだけが調べても見つかりませんでした。 他にRTS,CTS, Encripted Data,ACK,BAのプロトコルがあり、それらは調べて以下のように意味を解釈しましたが、"CFE"については見つからないため、意味が理解できていません。 ご存知の方がいましたらご教示を頂けますようお願い致します。 -------------------------------- RTS(Request To Send):端末側からアクセスポイントに通信許可を問い合わせる信号。 CTS(Clear to Send):アクセスポイントから端末に通信許可を与える信号。 Encrypted Data:WEP、TKIP、AESで暗号化されたデータ。 ACK(Acknowledgment):データ伝送で受信側から送信側へ送られる肯定的な返事。 BA(Block Ack):フレームアグリメーション方式の種類であるA-MPDUにおいて複数のデータに対して一括のACK(肯定的)な返事。 -------------------------------

  • RS232Cからイーサネット(LAN)への通信移行

    現在RS232CでPCとある外部機器で通信しているシステムをLAN経由に変更します。PC側はアダプターを入れるのでなく、ソフト自体を書き換えます。外部機器側ははっきりしませんが既存のRS232C通信を何かで変換するのではないかと思います。この場合、通信方式として一般にTCPとUDPが考えられますが、どちらにするべきか決めかねています。それぞれの概略は理解しています。 現在はRS232Cなので、受信データエラーはアプリで判断し再送要求をだす仕組みです。通常は、PCからデータ送信要求を出す⇒外部機器からデータ送信⇒ACK応答⇒EOTの様な手順です(PCからデータを送ることもあります)。この手順をそのまま生かすのであればUDPにするのが妥当なような気がするのですが、TCPの方が一般的とも聞きます。TCPにした場合、通信エラーはTCPプロトコル内でリカバーされるのでアプリの再送要求などは無意味になってしまう用に思えます。解釈が違っているでしょうか。 アプリレベルでの通信手順に大幅な変更を加えないという条件でどちらにするのが妥当なのかご意見をお聞かせください。なお、1回の通信データは長くても200バイト程度で、、通信インターバルは1回/秒程度です。

  • TCPのコネクションを切断する方法

    FTPのように、制御と転送の2つのポートを利用し、送信元リモートホストごとにforkして対応するTCPサーバプログラムを利用しています。 ここで、OS側から、制御ポート(ログイン等)のコネクションは切断しないで、転送ポートのコネクションだけを切断したいと思うのですが、可能でしょうか。 1つのプロセスが、1つのホストとの制御、転送、両方のコネクションを担当するので、プロセスをkillするわけにはいきません。 Macでは、IPNetMonitorというGUIアプリケーションで、TCPコネクションごとの切断ができるので、Linuxでも可能ではないかと思うのですが... 環境は、redhat7.3です。 よろしくお願いします。

  • WindowsのTCPコネクション管理

    Windows server 2003及びwindowsXPにおいて、以下のような動作を確認しております。(他のバージョンは未確認) [動作] あるIFからTCPコネクションを張った状態で、そのIFの無効化(非活性化)を行うと、TCPコネクションが切断される。 これはWindowsの仕様なのでしょうか? ちなみにUNIX系OSで同様のことを行っても、TCPコネクションは切断されません。 また、通信の対向マシンではTCPのFIN、RSTなどは受信していないことから、WindowsOS内部で何かしらの形でコネクションを強制切断していると思われます。 以上、ご回答をお願いいたします。