TCP Working: 3-Way Handshake & Reliable Communication

What happens if data is just sent, with no rules at all?

Imagine shouting a message across a crowded room, with no way to know if the other person actually heard it, no way to know if it arrived in the right order, and no way to know if part of it got lost in the noise. That’s roughly what sending data over a network would be like without any coordinating rules — packets can get lost, arrive out of order, or arrive duplicated, and neither side would have any built-in way to notice or fix it.

TCP (Transmission Control Protocol) exists specifically to prevent that chaos — turning an unreliable network into something applications can depend on completely.

What Is TCP and Why It Is Needed

TCP is a connection-oriented, reliable transport protocol — before any actual data is exchanged, both sides agree to talk, and once they do, TCP guarantees that data arrives complete, in order, and uncorrupted (or the sender is told it didn’t).

Without something like TCP, every single application would need to build its own logic for detecting lost data, handling out-of-order arrival, and confirming delivery — solving the exact same hard problem over and over, independently, in every piece of software that needs reliable communication.

Problems TCP Is Designed to Solve

Lost data

Networks aren’t perfect — packets can simply disappear in transit, dropped by an overloaded router or a bad connection along the way.

Out-of-order arrival

Packets can take different paths across a network and arrive in a different order than they were sent — without correction, a message could arrive scrambled.

Duplicate data

The same packet can sometimes be delivered more than once, due to retransmissions or network quirks — without detection, this could corrupt the data being reconstructed.

No confirmation of receipt

Without an acknowledgment system, a sender has no way to know whether their data actually arrived at all.

TCP is built specifically to solve all four of these, together, as one coherent system — which is exactly why it remains the backbone of things like web browsing, email, and file transfer, where correctness genuinely matters.

What Is the TCP 3-Way Handshake

Before any actual data flows, TCP requires both sides to agree to the conversation — a process called the 3-way handshake. Think of it like a phone call: you don’t just start talking the moment you dial — you wait for the other person to say “hello,” and only then does the actual conversation begin.

The handshake exchanges exactly three messages, confirming that both sides are ready, willing, and able to communicate — hence “3-way.”

Step-by-Step Working of SYN, SYN-ACK, and ACK

Step 1: SYN (“synchronize”)

The client sends a SYN message to the server — essentially saying, “I’d like to start a connection, and here’s a starting reference number I’ll use to keep track of the data I send.”

Step 2: SYN-ACK (“synchronize-acknowledge”)

The server responds with a SYN-ACK — a combined message that does two things at once: acknowledges the client’s SYN (“I received your request”), and sends its own SYN back (“and here’s my starting reference number too, since I’ll be sending data back to you as well”).

Step 3: ACK (“acknowledge”)

The client sends a final ACK, acknowledging the server’s SYN — confirming, “I received your response, and we’re both ready.” At this point, both sides have confirmed they can both send and receive — and the connection is officially established.

Why three steps, not two? Because communication needs to be confirmed in both directions — the client needs to know the server received its request, and the server needs to know the client received its response, before either side can trust the connection is genuinely ready in both directions.

How Data Transfer Works in TCP

Once the connection is established, TCP breaks data into smaller pieces (segments), and tracks each one using sequence numbers and acknowledgements — at a conceptual level, without needing to go deep into exact byte-level mechanics.

Sequence numbers

Each segment sent carries a sequence number, letting the receiving side know exactly where that piece fits in the overall stream of data — even if segments arrive out of order, the receiver can reassemble them correctly using these numbers.

Acknowledgements

After receiving data, the receiver sends back an acknowledgement, confirming exactly how much it has successfully received so far — letting the sender know what’s arrived safely, and what might still need to be resent.

This ongoing back-and-forth — data flowing one way, acknowledgements confirming receipt — is the core mechanism that lets TCP track exactly what’s been successfully delivered at any given moment.

How TCP Ensures Reliability, Order, and Correctness

Reordering using sequence numbers

If segments arrive out of order (a real possibility on a shared network), the receiver uses their sequence numbers to reconstruct the original, correct order before handing the data up to the application — the application itself never sees the scrambled arrival order.

Detecting and handling lost data

If the sender doesn’t receive an acknowledgement for a segment within an expected time, it assumes that segment was lost and retransmits it — TCP actively watches for missing acknowledgements and takes corrective action, rather than simply hoping everything arrived.

Detecting duplicates

Because every segment carries a sequence number, the receiver can recognize if it’s already seen a particular segment before — safely discarding any duplicate instead of processing it twice.

The overall guarantee

Put together, these mechanisms let TCP make a strong promise to any application using it: data will arrive complete, correctly ordered, and without duplicates — or, in genuinely broken network conditions, the connection will report a failure, rather than silently delivering corrupted or incomplete data.

How a TCP Connection Is Closed

Just as opening a connection requires an agreed handshake, closing one does too — using FIN (“finish”) and ACK messages, so that neither side loses data by ending the conversation too abruptly.

Why both sides send their own FIN

TCP connections are bidirectional — either side might still have data left to send even after the other side is finished. Each side sends its own FIN specifically when it has nothing further to send, and the connection isn't considered fully closed until both directions have been explicitly finished and acknowledged — a clean, deliberate handshake in reverse, mirroring how the connection was opened in the first place.

Final Takeaway

TCP’s entire design answers one central question: how do you build something trustworthy on top of a network that makes no promises on its own? The 3-way handshake ensures both sides genuinely agree to talk before any data flows. Sequence numbers and acknowledgements track exactly what’s been sent and received, in what order. Retransmission catches and corrects for lost data automatically. And a mirrored handshake on the way out — FIN and ACK in both directions — ensures the connection closes cleanly, without either side losing data mid-conversation. None of it is exotic — it’s a small set of deliberate confirmations, layered together, that turn an unreliable network into something applications can genuinely depend on.

Frequently Asked Questions

Why does TCP need a handshake at all — why not just start sending data immediately?

> Without it, neither side could be sure the other is actually ready and listening — data could be sent into a connection nobody’s prepared to receive. The handshake confirms both directions are genuinely ready before committing to send real data.

What happens if the 3-way handshake fails partway through?

> If an expected response (like the SYN-ACK or final ACK) doesn’t arrive within a certain time, the side waiting for it will typically retry or eventually give up and report a connection failure, rather than proceeding with an unconfirmed connection.

Does every lost packet cause a long delay while waiting for retransmission?

> TCP includes mechanisms to detect loss and retransmit reasonably quickly, though there is some inherent delay involved compared to if nothing had been lost at all — a deliberate tradeoff, prioritizing correctness over the absolute lowest possible latency.

Is TCP the same thing as HTTP?

> No — as covered elsewhere in this series, HTTP is an application-layer protocol that defines the content of a web request; TCP is the transport-layer protocol underneath it that guarantees that content is delivered reliably. HTTP relies on TCP; they solve different problems at different layers.