Reputation: 7544
I'm working on implementing TCP myself for a class project, and there's one detail I can't seem to understand. What is a FIN+ACK message? In the diagram I included here, receipt of a FIN+ACK will take a host from the FIN_WAIT_1 state to the TIME_WAIT state. Yet, NO state transition in the entire diagram sends a FIN+ACK. So how could a FIN+ACK ever be received if nothing is ever sending it?
Upvotes: 8
Views: 28934
Reputation: 3541
When an application calls close
it moves to FIN_WAIT_1
From FIN_WAIT_1
multiple things can happen:
Application receives ACK:
This means that the peer as acknowledged the last sent data packet. Local application moves to FIN_WAIT_2
Application receives FIN:
This indicates that peer has called close
. And local application should acknowledge that. Hence ACK goes out to peer. Local application moves to CLOSING
Application receives FIN + ACK:
What FIN+ACK
as you put it means is that the peer has called close
as well as in the same TCP segment is acknowledging the data received last. Local application will acknowledge the FIN and this takes the state to TIME_WAIT
.
Upvotes: 7
Reputation: 17176
TCP is defined by more than just that state diagram, the basic specification can be found in RFC 793. One particular statement is as follows (page 15, description of ACK
field):
Once a connection is established this is always sent.
So basically this says an ACK must always be present after the initial three-way handshake, including during the four-way disconnect phase. There are subsequently only 2 messages that do not include an ACK:
So to answer your question: in that diagram, whenever a FIN is sent, the ACK flag will also be set and an ACK nr will be present, even though it is not explicitly stated.
Upvotes: 7