When a piece of data leaves your computer bound for another, it already has two problems solved: an address —the IP that says which machine— and a route to travel along. But that's not enough. The most interesting part is left: deciding how that data moves. Do we confirm it arrived? Does order matter? What happens if a piece gets lost? Those questions belong to TCP and UDP, and they answer them in opposite ways.
The transport layer
With an IP to know where to go and a route to get there, it's still left to decide how the data is transported end to end. That work lives in the transport layer, and it's done by two protocols with different philosophies.
With an IP (address) and a route already in place, it remains to decide how the data moves. That's the job of TCP and UDP, the two transport protocols.
Both use ports to deliver the data to the right program inside the machine. The difference is in what they guarantee along the way.
TCP: guaranteed delivery
TCP (Transmission Control Protocol) is connection-oriented: before sending anything useful, client and server establish an agreement. Then TCP numbers the data, confirms its receipt, retransmits what's lost and reorders what arrives out of order. The result is reliable, complete, in-order delivery —at the cost of more overhead and a bit more latency—.
It all begins with the three-way handshake, the greeting that opens the connection before transmitting a single byte of data:
- The client sends a SYN to the server: "I want to open a connection".
- The server responds with a SYN-ACK: "received, and I want to as well".
- The client responds with an ACK and the connection is established. From here on, the data flows.
That three-step dance costs one round trip before sending anything, but in return both ends end up synchronized and ready for a reliable transfer. Every block sent afterward is numbered and acknowledged; if an acknowledgment doesn't arrive, TCP resends. Nothing is considered delivered until the other side confirms it.
UDP: speed without guarantees
UDP (User Datagram Protocol) is the opposite philosophy: connectionless. There's no handshake, it doesn't confirm receipt, doesn't retransmit what's lost and doesn't reorder anything. It simply sends the packets and that's it.
That simplicity is its strength: it's fast and lightweight, without the handshake's round trip or the weight of acknowledgments. But it's also its limit: packets can be lost or arrive out of order, and UDP does nothing about it. The decision of whether that matters —and what to do if it happens— is left to the application.
"UDP is no good because it drops packets." It's not that it fails: it's that it makes no promise not to drop them. For many uses —a video call, an online game— a lost packet is preferable to one that arrives late. UDP hands over that contract on purpose, and the application builds on top whatever it needs.
Ports and sockets
Both TCP and UDP need a mechanism to deliver data not just to the right machine, but to the right program inside it. That's where ports come in.
A port is a number that identifies the service inside the machine: 80 for web (HTTP), 443 for HTTPS, 22 for SSH, and so on. When you combine an IP with a port you get a socket: the exact combination that identifies one end of the conversation.
Thanks to this, a single machine with a single IP can handle thousands of connections at once: each conversation is told apart by its socket. The browser reading this article and the email client open on the same machine use different ports, and that's why each one's data reaches the right place.
TCP and UDP, side by side
| Feature | TCP | UDP |
|---|---|---|
| Connection | Yes, with handshake | No |
| Guaranteed delivery | Yes | No |
| Guaranteed order | Yes | No |
| Speed | Lower | Higher |
| Overhead | Higher | Lower |
| Typical uses | Web, email, file transfers | Streaming, video calls, DNS, games |
Common mistakes
"UDP is worse than TCP." No. It's not worse: it's for something else. DNS and video calls use UDP on purpose —better a lost frame than one that arrives late—. A bank transfer, on the other hand, demands TCP: you can't lose a single byte. The best protocol depends on what you can tolerate losing.
- Believing "faster is always better". It depends on whether you tolerate loss. If you don't, UDP's speed is no use to you: you need TCP's guarantees.
- Confusing "connectionless" with "unreliable by design". UDP isn't careless; it delegates reliability to the application, which can add exactly what it needs and nothing more.
- Forgetting that the port defines the service. Opening 443 while thinking of 22, or vice versa, leaves the service unreachable even if the IP and route are correct.
The banking angle
In banking, transactions go over TCP. The reason is straightforward: guaranteed delivery and order, because you can't lose or duplicate a payment. A missing byte or a message that arrives twice isn't a tolerable glitch: it's money miscounted, a reconciliation that doesn't balance, an audit that falls apart.
Choosing the transport is, at bottom, choosing between guarantee and speed. For a video stream, speed rules and a lost frame is forgotten in an instant. In banking it's the reverse: guarantee rules, and the extra latency of the handshake and acknowledgments is a price gladly paid. It's the same criterion that leads to preferring SFTP over FTP: when what travels admits no errors, the guarantee isn't up for negotiation.
TCP and UDP don't compete: they solve opposite needs. One guarantees delivery, the other bets on speed, and neither is "better" in the abstract. Knowing which to use —and why— is part of the design, not an implementation detail.
