質問: 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と解釈しており、 問題視しておりませんが、ここの解釈が間違っていたら訂正お願いします。
回答: まず、パケット(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フラグ立てるかどうかを条件分岐するほうが 実装上大変でしょう。