TCP/IP Explained: How Unreliable Packets Become Reliable Delivery

The packet chapter ended with a problem: packet switching is efficient and resilient, but the packets arrive as a mess — out of order, duplicated, sometimes lost. Yet when you load a web page or transfer a file, you get the exact original, perfectly intact. Something is cleaning up that mess.

That something is TCP, working atop IP — together, TCP/IP, the protocol suite the entire internet is built on. This chapter shows how two protocols, each doing one job, combine to turn chaos into reliable communication — and why splitting the work into layers was the masterstroke.

Two problems, two protocols

The insight at the heart of TCP/IP is separation of concerns. Getting data across a network involves two very different problems:

1. Delivery — get this packet to that address, somehow.
2. Reliability — make sure the whole message arrives complete and in order.

TCP/IP refuses to solve both at once. It splits them:

IP is deliberately dumb. It knows how to look at a packet's destination IP address and move it one hop closer — and that's all. It makes no promise the packet arrives, arrives once, or arrives in order. It's pure best-effort delivery. This simplicity is a feature: because IP asks so little, almost any network can carry it.

TCP is the smart layer on top. It takes IP's unreliable best-effort delivery and, through some clever bookkeeping, builds the reliable ordered stream that applications actually want. Let's see how.

The three-way handshake: opening a connection

TCP is connection-oriented — before any data flows, the two sides establish a connection with a brief, famous three-message exchange (you met it in passing when typing a URL):

1. SYN — the client sends a "synchronise" message: "I'd like to open a connection, here's my starting sequence number."
2. SYN-ACK — the server replies: "Acknowledged, and I'd like to open my direction too, here's mine."
3. ACK — the client confirms: "Acknowledged. We're connected."

After these three messages, both sides know the other is present, reachable, and ready — and they've agreed on the numbering they'll use to track everything. Only now does real data flow. This handshake is literally the "connection" in "connection-oriented," and it's why there's a tiny setup cost before a TCP conversation begins.

How TCP actually guarantees delivery

With the connection open, TCP defeats the packet mess with three simple, combined mechanics:

That loop — number the pieces, confirm what arrived, re-send what didn't — is the whole trick. Layered over IP's unreliable delivery, it produces a channel that behaves as if the network never dropped or scrambled anything. The application above never sees the mess; it just reads a clean, ordered stream of bytes.

TCP does more with the same bookkeeping — notably flow control (don't overwhelm a slow receiver) and congestion control (back off when the network is overloaded, so everyone shares fairly). These are what keep the shared packet-switched network from collapsing under its own traffic.

UDP: when you don't want the guarantees

TCP's reliability isn't free — the handshake, the acknowledgements, the waiting-and-retransmitting all add delay. Usually that's a great trade. Sometimes it's exactly wrong.

Consider a live video call. A packet carrying 40 milliseconds of audio gets lost. TCP would notice and re-send it — but by the time the replacement arrives, that moment of speech is long past; playing it late would be worse than skipping it. For live media, a late packet is a useless packet.

For these cases there's UDP (User Datagram Protocol) — TCP's minimalist sibling. UDP is essentially "IP with ports": it sends packets and makes no guarantees about order, delivery, or duplicates. No handshake, no acknowledgements, no retransmission. It sounds worse, and for a web page it would be — but for the right job it's perfect:

The choice is a genuine engineering trade-off: completeness vs. timeliness. TCP guarantees you get everything, eventually. UDP gives you whatever's here now and moves on. Live experiences pick now.

The layer cake

Step back and you'll see TCP and IP are two floors of a taller building. The internet is organised as a stack of layers, each solving one problem and trusting the layer below:

• Link layer — moves bits over one physical hop (your Wi-Fi, an Ethernet cable, a fibre line).
• Internet layer (IP) — moves packets across many hops toward an address.
• Transport layer (TCP/UDP) — turns that into either a reliable stream or a fast datagram.
• Application layer — the protocols you actually use: HTTP for the web, DNS for name lookups, and so on.

Recap

• TCP/IP splits the work: IP delivers individual packets to an address on a best-effort basis (no guarantees); TCP sits on top and makes delivery reliable and ordered.
• TCP opens every connection with the three-way handshake (SYN, SYN-ACK, ACK) so both sides confirm they're ready.
• Reliability comes from sequence numbers (order + dedupe), acknowledgements (know what arrived), and retransmission (resend the lost) — plus flow and congestion control to share the network fairly.
• UDP drops the guarantees for speed — the right choice for live video, voice, and gaming, where a late packet is worthless: timeliness over completeness.
• The internet is a stack of layers (link → IP → transport → application); each solves one problem and trusts the one below, which is why it could evolve for decades without a redesign.

We've assumed packets somehow "find their way" across the world. Next, the system that actually steers them. Continue to How internet routing works.