Understanding Full-Duplex Communication in TCP: Three-Way Handshake and Half-Close Mechanisms

Introduction

TCP Theory

TCP offers a connection-oriented, reliable byte stream service, ensuring full-duplex communication.

Connection-oriented: Both parties need to establish a connection beforehand, much like making a phone call in real life.

A TCP connection must undergo a three-way handshake, while releasing a TCP connection requires four-way handshake, due to TCP’s half-close feature. Since a TCP connection is full-duplex, TCP on both ends needs to execute closure independently. Notably, the end that actively closes the connection can still receive data from the other side after sending the FIN, but informs the other party that it has no more data to send. Similarly, the passively closing end can still send data until it too sends a FIN, after which it stops sending data.

TCP Packet Format

TCP_format.jpg

Three-way Handshake

Illustration of the Three-way Handshake

TCP_hand.jpg

Once the three-way handshake is complete, the client and the server can start transferring data.

Why Three-way Handshake?

To prevent expired connection request packets from suddenly being delivered to the server.

This is how an “expired connection request packet” is generated.

Four-way Termination

A TCP connection is full-duplex, so TCP on both ends needs to execute closure independently. Simply put, end A or B can propose disconnect by sending a packet to the other, asking it to stop sending data. Upon receipt, the other end responds and then informs the first end to stop sending data, closing its own send channel. The first end, upon receipt, also responds and closes its send channel.

Illustration of the Four-way Termination

TCP_bye_img.jpg

When the client has no data to send, it needs to release the request on its side by sending a packet (without data), with Flags set to FIN=1. The server responds with a packet and then requests the client to release the connection, also using FIN. The client then acknowledges this and enters the TIME_WAIT state, waiting for 2MSL time.

The server sends a FIN = 1 request to release the connection, but the packet is lost. A did not receive which means it won’t send acknowledgment. The server will retransmit after timeout, and the client in its WAIT_TIME can receive this request and reply with acknowledgment (WAIT_TIME restarts when the client receives FIN = 1).

Furthermore, the server has a keepalive state, meaning if the client suddenly crashes, when will the server-side connection resource be released? After keepalive time is reached, the server sends a probe message to decide whether to release the connection.

Here we assume the client initiates the disconnection. If it’s the server, the process is the same.

TCP Half-Close

TCP offers the ability for one end to still receive data from the other end after it finishes sending. This is TCP’s half-close.

Generation of Half-Close:

The client sends a FIN, and the other end sends an ACK segment for this FIN. The client is now in half-close.

Practical Packet Capture Demonstration (Wireshark)

Operational Steps:

START_server.png

Packet Capture Results

TCP2.png

First Handshake:

In the screenshot we only capture the protocol part of the transport layer.

Sending a Syn packet to the server. Sequence Number=0

TCP_hand_1.png

Second Handshake:

The server sends an Acknowledgment and Syn packet to the client. Acknowledgment number=1

Sequence number =0

TCP_hand_2.png

Third Handshake:

The client sends an Acknowledgment packet to the server. Acknowledgment number=1

Sequence number =1

Connection is then established

TCP_hand_3.png

First Data Sending

TCP_send_1.png

\

Second Data Sending

TCP_send_2.png

First Termination:

TCP_bye_1.png

Second Termination:

TCP_bye_2.png

Third Termination

TCP_bye_3.png

Fourth Termination

TCP_bye_4.png