On the internet, data travels through unreliable networks filled with routers, switches, and countless devices. Packets can be lost, duplicated, damaged, or arrive out of sequence. Without a protocol to manage this chaos, applications would receive garbled, incomplete, or jumbled data. A file download could corrupt mid-transfer. A banking transaction might complete twice. A video call would be incomprehensible.

This is where TCP (Transmission Control Protocol) enters the picture as a lifesaver for reliable communication.

What is TCP

TCP is a connection-oriented protocol that sits at the Transport Layer (Layer 4) of the Internet model. Unlike UDP, which simply sends data without care about delivery, TCP ensures that:

• All data arrives at the destination, even if packets are lost during transmission

• Data arrives in order, exactly as the sender send the request

• Data is uncorrupted, verified using checksums

• Both endpoints are ready before communication starts

• Communication is gracefully closed when complete

Problems TCP is Designed to Solve

1. Packet Loss

   Networks are unreliable. Routers can be congested, links can fail, and packets get dropped. TCP detects when packets are missing and automatically retransmits them.

2. Out-of-Order Delivery

   In complex networks, packets taking different routes might arrive in the wrong sequence. TCP reassembles them using sequence numbers, ensuring applications receive data in the correct order

3. No Flow Control

   fast sender overwhelming a slower receiver's buffer causes data loss. TCP uses a sliding window mechanism to control transmission rates based on receiver capacity

4. No Connection State

   Without a handshake, how do both sides agree to communicate? TCP's 3-way handshake establishes a reliable connection before any data is exchanged

The TCP 3-Way Handshake: Establishing Trust

Before two computers exchange data over TCP, they must establish a connection through a process called the 3-way handshake. This elegant mechanism ensures both computers are ready and have agreed on initial sequence numbers.

The handshake is like two people confirming they can hear each other:

• Person A : "Can you hear me? I'm starting from word number 100”

• Person B : “Yes, I heard you! You said word 100. I'm starting from word 500“

• Person C : “Perfect! I heard you say word 500. Let's start talking“

Step 1: Client Sends SYN

The initiating computer (client) sends a SYN (Synchronize) packet to the server. This packet contains:

• SYN flag set to 1 – indicating this is a synchronization request

• Initial Sequence Number (ISN) – a random starting number for byte sequencing (e.g., 1000)

• Window size – how much data the client can accept

The client enters the SYN-SENT state, waiting for a response. Think of this as “Hello, I am ready to talk, and I am starting my count at 1000“

Step 2: Server Responds with SYN-ACK

The server, already in LISTEN state, receives the SYN packet. It responds immediately with a SYN-ACK packet containing:

• ACK flag set to 1 – acknowledging the client's SYN

• Acknowledgement Number = ISN_Client + 1 – confirming receipt of the client's starting number (e.g., 1001)

• SYN flag set to 1 – the server's own synchronization request

• Server's Initial Sequence Number – the server's starting number (e.g., 2000)

• Window size – the server's receive capacity

The server enters tge SYN-RECEIVED state. This says:” I got your message starting at 1000. I'm starting my count at 2000”

Step 3: Client Acknowledges with ACK

The client receives the SYN-ACK and responds with an ACK packet:

• ACK flag set to 1

• Acknowledgement Number = ISN_Server + 1 – confirming the server's sequence number (e.g., 2001)

Both client and server now enter the ESTABLISHED state, and the connection is ready for data transfer. This acknowledgement says: "I got your message starting at 2000. We're connected

How Data Transfer works in TCP

Once the connection is established, data flows bidirectionally using sequence numbers and acknowledgements.

Sequence Numbers : Tracking Every Byte

Every byte transmitted over TCP has a sequence number. When the client sends data, it includes-

• Sequence Number – the number of the first byte in this segment (e.g., 1000)

• Data – actual payload (e.g., 500 bytes)

• Length – how many bytes are in this segment

If a segment contains bytes 1000-1499, the sequence number is 1000. The next segment would start at 1500.

Acknowledgement Numbers:Confirming Receipt

When the receiver gets data, it sends back an ACK packet with:

• Acknowledgement Number – the sequence number of the NEXT byte it expects (e.g., 1500)

The number confirms: "I've successfully received all bytes up to 1499, and I'm ready for byte 1500 next”

How TCP Ensures Reliability: The Safety Net

TCP guarantees reliability through four complementary mechanisms:

1. Positive Acknowledgement with Retransmission (PAR)

   Every segment sent must be acknowledged. If no acknowledgement arrives within a timeout period, the sender assumes the packet was lost and retransmits it.

2. Sequence Numbers and Ordering

   Each byte is numbered sequentially. Out-of-order packets are reassembled correctly using these numbers, and duplicates are discarded.

3. Checksums for Error Detection

   TCP includes a checksum (calculated from the segment's contents) in every packet. If the checksum doesn't match upon arrival, the segment is discarded and will be retransmitted.

4. Retransmission Timeout (RTO) and Exponential Backoff

   If an acknowledgement isn't received within the RTO window, the sender retransmits the packet. If it fails again, the RTO is doubled (exponential backoff: RTO → 2×RTO → 4×RTO → 8×RTO) to avoid overwhelming a congested network.

Detecting Packet Loss: Two Methods

Method 1: Timeout Expiry

The sender sets a timer when transmitting a segment. If the timer expires without an acknowledgement, the segment is assumed lost and retransmitted.

Method 2: Duplicate Acknowledgements

If the receiver gets packets out of order, it sends duplicate ACKs for the same sequence number. If the sender receives multiple duplicate ACKs, it assumes a packet was lost and can retransmit immediately without waiting for the timeout.

How TCP Connection Closes: Graceful Termination

Closing a TCP connection properly ensures no data is left hanging. Unlike the 3-way handshake, closing involves a 4-way handshake because each side must signal independently that it's done sending data

The 4-way Closing Handsake

Step 1: Client Initiates Close (Sends FIN)

The client sends a FIN (Finish) flag packet, indicating "I have no more data to send." The client enters FIN-WAIT-1 state.

Step 2: Server Acknowledges (Sends ACK)

The server receives the FIN and acknowledges it with an ACK packet. The server enters CLOSE-WAIT state, but can still send data if needed.

Step 3: Server Closes (Sends FIN)

Once the server finishes sending any remaining data, it sends its own FIN packet. The server enters LAST-ACK state, waiting for the client's final acknowledgement.

Step 4: Client Acknowledges (Sends ACK)

The client receives the server's FIN and sends a final ACK. The client enters TIME-WAIT state for a brief period to handle any delayed packets, then fully closes.