TCP shook hands three times and waved hands four times

TCP is a connection-oriented transport layer protocol. Before transmitting application data, both parties need to establish a connection through three handshakes; after the data transmission is over, the two-way connection is usually released through four message segments.

Relevant fields in TCP header

Serial number seq

The serial number field occupies 32 bits. TCP numbers the data in the byte stream, and the sequence number in a message segment usually represents the first byte number of the data carried by the message segment.

When establishing a connection, both parties to the communication will select the initial serial number respectively. Even if SYN and FIN do not carry application data, they each consume a serial number.

Confirmation No. ack

The confirmation number field occupies the 32 bit and represents the next byte sequence number that the recipient expects to receive.

For example, if data with serial numbers 100 to 199 has been correctly received, the confirmation number is usually 200.

ACK flag bit

ACK occupies 1. When ACK is 1, the confirmation number field is valid. After the connection is established, this flag bit will be set in most TCP message segments.

Need to distinguish:

• Lower case ack usually represents the value of the confirmation number field.
• The capital ACK represents the acknowledgement flag bit in the TCP header.

SYN flag bit

SYN is used to establish a connection and synchronize the initial serial numbers of both parties.

• SYN=1, ACK=0: usually represents a connection request.
• SYN=1, ACK=1: usually means agreeing to establish a connection and confirming the other party’s request.

FIN flag bit

FIN indicates that the sender has no data to send and requests to close the connection in the current direction. TCP is a full-duplex protocol, so after one direction is turned off, data can still continue to be transmitted in the other direction.

three-way handshake

Suppose that the initial serial number of the client is x and the initial serial number of the server is y.

First handshake: client sends SYN

The client sends a connection request to the server:

SYN=1, seq=x

After sending, the client enters SYN-SENT state from CLOSED.

Second handshake: server sends SYN+ACK

After receiving the client’s request, the server confirms the client’s serial number and sends its own initial serial number:

SYN=1, ACK=1, seq=y, ack=x+1

After sending, the server enters SYN-RECEIVED state from LISTEN.

Third handshake: client sends ACK

After receiving the server’s response, the client sends a confirmation message:

ACK=1, seq=x+1, ack=y+1

After the server receives the confirmation, both parties enter the ESTABLISHED state and can transmit application data.

If the pure ACK message in the third handshake does not carry data, it will not consume additional serial numbers.

Why do you need three handshakes?

The three handshakes mainly completed the following tasks:

• Confirm that the sending and receiving capabilities of both parties are basically normal.
• Synchronize the initial serial numbers of both parties.
• Avoid invalid old connection requests that directly cause the server to establish wrong connections.
• Negotiate TCP options such as maximum segment length and window expansion factor.

When there are only two interactions, the server cannot confirm whether the client has received the server’s initial serial number and connection confirmation, so a third confirmation is needed.

Wave four times

Here is an example of a client actively closing the connection. Suppose that the client sent FIN with the serial number u, and the server’s current serial number is v.

The first wave: the client sends FIN

The client indicates that it has no data to send:

FIN=1, ACK=1, seq=u

The client enters FIN-WAIT-1 state. FIN consumes a serial number.

Second wave: The server confirms the client’s FIN

The server sends a confirmation after receiving FIN:

ACK=1, seq=v, ack=u+1

The server enters the CLOSE-WAIT state, and the client enters the FIN-WAIT-2 state after receiving the confirmation.

At this time, the client-to-server direction has been turned off, but the server-to-client direction can still continue to transmit data that has not yet been sent. This state is called semi-closed.

The third wave: the server sends FIN

After the server completes sending the remaining data, it requests to turn off its sending direction. Suppose the server serial number is w at this time:

FIN=1, ACK=1, seq=w, ack=u+1

The server enters LAST-ACK state and waits for the final confirmation from the client.

Fourth wave: Client confirms server’s FIN

After receiving FIN from the server, the client sends an acknowledgement:

ACK=1, seq=u+1, ack=w+1

The client enters TIME-WAIT state. The server enters CLOSED state after receiving the acknowledgement.

Why does it usually take four waves?

Both transmission directions of TCP need to be turned off separately. After the active closing party sends FIN, the passive closing party may still have data to send. Therefore, it usually confirms the other party’s FIN separately first, and then sends its own FIN after the remaining data has been sent.

If the passive shutdown party has no data to send when receiving FIN, it may also merge ACK and its own FIN into the same message segment. At this time, the number of message segments seen on the network may be less than four, but the connection release logic still includes closure and confirmation in both directions.

TIME-WAIT status

The active shutdown party will usually wait for 2MSL in the TIME-WAIT state. MSL represents the maximum lifetime of a message segment in the network.

There are two main reasons for waiting:

• If the last ACK is lost, the passive closing party will retransmit FIN, and the active closing party can still confirm it again.
• Allow delayed messages generated by the current connection to disappear in the network to avoid affecting new connections established later using the same quadruple.

TIME-WAIT is an important mechanism for TCP to ensure reliable shutdown and is not equivalent to a program exception.

Summary of common status

Status	Meaning
LISTEN	Server listens for connection requests
SYN-SENT	client has sent a connection request
SYN-RECEIVED	server has received the request and is waiting for final confirmation
ESTABLISHED	Connection established
FIN-WAIT-1	The active closing party has sent FIN, waiting for confirmation
FIN-WAIT-2	The active closing party has received confirmation and is waiting for the other party’s FIN
CLOSE-WAIT	The passive closing party has confirmed the other party’s FIN, waiting for the application to close and connect to
LAST-ACK	The passive shutdown party has sent its own FIN, waiting for final confirmation of
TIME-WAIT	Active closing party waiting 2MSL
CLOSED	Connection closed