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

No.2 回答者： jyufi_february 回答日時： 2013/12/30 06:12

まず、パケット(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

No.1 回答者： Lchan0211b 回答日時： 2013/12/19 22:17

これは、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/n …

ただ、Fig.13のシーケンスは、あくまで例であり、FINにACKをつけて送ることも
間違いではありません。
(この場合(3)のACKは、(1)のFINに対する(2)のACKの再送です。)

では、なぜFINにACKをつけたシーケンス例が出ているかというと
私の推測ですが、
1.FIN送信時は、常にACKを付与して送信する処理にした方が、状態に応じて
ACKをつける/つけないの判断をするより処理が簡潔で確実になるし副作用もない。
2.仮に(2)のACKがロストした場合でも(3)のFINにACKがついていれば
切断シーケンスをそのまま進められるメリットがある。
といったようなことを考えて、FINにACKをつける実装をしてもよいということを
示したかったのではないかと思います。