TCP Connection Release

TCP, like most connection-oriented transport protocols, supports two types of connection releases:

1. Graceful connection release, where the connection is not closed until both parties have closed their sides of the connection.

2. Abrupt connection release, where either one user closes both directions of data transfer or one TCP entity is forced to close the connection.

Abrupt Connection Release

We’ve already had a brief overview of abrupt connection release with RST segments in a previous lesson. Let’s have a closer look.

An abrupt release is executed when a RST segment is sent. A RST can be sent for the following reasons:

• A non-SYN segment was received for a non-existing TCP connection (RFC 793).

• Some implementations send a RST segment when a segment with an invalid header is received on an open connection (RFC 3360). This causes the corresponding connection to be closed and has prevented attacks (RFC 4953).

• Some implementations send an RST segment when they need to close an existing TCP connection for any reason such as:

  • There are not enough resources to support this connection
  • The remote host has stopped responding and is now unreachable.

When a RST segment is sent by a TCP entity, it should contain the current value of the sequence number for the connection (or $0$ if it does not belong to any existing connection), and the acknowledgment number should be set to the next expected in-sequence sequence number on this connection.

Graceful Connection Release

The normal way of terminating a TCP connection is by using the FIN flag of the TCP header. This ‘graceful mechanism’ allows each host to release its own side of the connection individually. The utilization of the FIN flag in the TCP header consumes one sequence number.

FSM

The following figure shows an FSM that depicts the various ‘graceful’ ways that a TCP connection can be released.

Don’t feel overwhelmed if you don’t understand it yet, we’ll study each possible path individually.