Once data knows where it's going (IP's job), there's a second decision: how carefully should it travel? The internet offers exactly two service levels — TCP and UDP — and nearly everything you do online has quietly picked one. Understanding why each gets picked is one of those concepts that makes a dozen other things suddenly make sense.
TCP: signed-for delivery
TCP treats data transfer as a formal, tracked relationship. Before anything is sent, both sides perform a quick handshake to agree they're talking. Then every chunk of data is numbered, every received chunk is acknowledged, anything lost in transit is noticed and re-sent, and everything is reassembled in the correct order at the far end — even if packets took different routes and arrived shuffled. The cost of all that care is overhead: acknowledgements flowing backward, waiting for stragglers, re-transmissions.
That's the right trade for anything where correctness beats speed: web pages, email, file downloads, messaging. A file with one missing chunk is corrupt; you'd rather wait.
UDP: paper planes
UDP does none of it. No handshake, no numbering, no acknowledgements, no retries — fold the data into a plane, throw it, immediately throw the next. Some planes miss. UDP does not care, and that indifference is the feature: no waiting, minimal overhead, maximum speed.
That's the right trade when freshness beats completeness — live video calls, online games, streaming. Here's the counterintuitive bit worth sitting with: re-sending a lost packet from half a second ago is worse than useless in a video call, because that moment has already passed. A glitched frame that's current beats a perfect frame that's late. Real-time applications don't tolerate loss reluctantly — they prefer it to delay.
This explains a support classic: on a struggling network, video calls get robotic and glitchy but web pages still load fine. UDP loss shows up instantly as glitches; TCP quietly repairs itself and just feels "a bit slow." Same broken network, two completely different symptoms — because two different delivery philosophies.
One more piece: ports
Both protocols use port numbers to identify which application a packet belongs to — the flat number of the building's address. Web traffic runs on TCP port 443 (HTTPS), DNS queries on UDP port 53, and so on. When a firewall rule says "allow TCP/443," it's specifying both the delivery method and the flat number. You'll write and read rules like that constantly — and now you know what both halves mean.