Why client will send a RESET when it is closed state?

Question

Suppose I have an TCP state transition diagram. And assume that the last ACK is lost. Then, B will think that A did not receive the FIN and will retransmit the FIN. From B point of view this is the same as if the FIN was lost, from A point of view this different since A now is in the

Case1 :TIME_WAIT

or

Case2 :CLOSED state.

case1: When A receives the new FIN from A if it is in the TIME_WAIT state it will send the ACK again(Understand this).

case2:If A is in the CLOSED state it will send a RESET(Don't Understand this), in either case B will be able to close its side of the connection.

A -----FIN-----> B
FIN_WAIT_1       CLOSE_WAIT
A <----ACK------ B
FIN_WAIT_2

(B can send more data here, this is half-close state)

A <----FIN------ B
TIME_WAIT        LAST_ACK
A -----ACK-->X(Lost)   B
TIME_WAIT        LAST_ACK
|
2MSL Timer
|
CLOSED
                 (timeout waiting for ACK)
A <----FIN------ B
A -----RST-----> B
                 CLOSED

My question is that why A send RST whenever it is in closed state?

Answer 1

See RFC 793:

Reset Generation

As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case.

Answer 2

In order to see why this is happening we need to consider these two things:

1. TCP is stateful, in that both end-points of the connection are holding connection state. When the connection is closed, this state has to be deleted at some point. In TCP, connection state can be deleted when (immediately after) switching to CLOSE state.

2. When TCP receives a segment, it has to be able to associate this segment to any existing connection. If there is no connection to associate the segment to, then TCP sends RST (see the answer of Zac67).

This is how these two facts apply to the situation.

A -----FIN-----> B
A <----ACK------ B

A <----FIN------ B
A -ACK ->   ???  B

A has sent an ACK. At this point the connection is closed by both A and B. So, the connection state is not needed anymore. However, since that last ACK can be lost, the standard specifies that A has to retain (portion of) connection state for 2 * MSL time interval. If the ACK is lost B will retransmit the FIN and A can resend it's ack. It also resets this 2*MSL timer.

According to the standard (RFC 793):

MSL - Maximum Segment Lifetime, the time a TCP segment can exist in the internetwork system. Arbitrarily defined to be 2 minutes.

I think some systems allow to configure the value of that timer. But, it should be large enough, so that retransmission(s) of the FIN arrives before the timer expires.

So, this can happen:

A -----ACK-->X(Lost)   B
TIME_WAIT        LAST_ACK

                 (timeout waiting for ACK) 
A <----FIN------ B
A -----ACK-----> B
|
restart 2MSL timer
|

And this should not have happened. If it does, it means that the timer was too short.

A -----ACK-->X(Lost)   B
TIME_WAIT        LAST_ACK
|
2MSL Timer
|
CLOSED
// timer value was too short(!)
                 (timeout waiting for ACK)
A <----FIN------ B
A -----RST-----> B
                 CLOSED

Let's see why is RST sent:

...
A -ACK ->   ???  B
TIME_WAIT     // A goes into TIME_WAIT state  
|
2MSL Timer
|            // The timer expires
CLOSED      // A deletes any connection state associated with this connection

So, if for some reason this gets to happen:

A <----FIN------ B

A does not have any connection state that is associated with this segment. It does not know what to do with it. Thus, according to specification it sends its RST.