TCP vs UDP: The Internet's Two Ways to Move Data

The big question

When one computer sends data to another, we have to answer a few questions. Does the data actually arrive? Does it arrive in the right order? And if something goes missing on the way, is it re-sent? There are two different answers to this problem, and you will see their names constantly in DevOps: TCP and UDP.

Where TCP and UDP sit

Both TCP and UDP live in the transport layer of the stack we built up in earlier parts. The layer below them, IP, decides where the data goes — the destination address. TCP and UDP decide how it gets there: reliably, or quickly.

TCP: the reliable one

TCP — the Transmission Control Protocol — is the protocol you will deal with most as a DevOps engineer. Its whole job is to make data transfer dependable.

• The data arrives — nothing is silently dropped.
• The data arrives in order, even if individual packets take different paths.
• Anything lost along the way is automatically re-sent.
• Duplicate data is detected and removed.

What “connection-based” means

Before TCP sends any real data, it does something important: it opens a connection. Conceptually it is a short back-and-forth — the client asks “can we talk?”, the server says “yes”, and the client confirms. This is the TCP handshake. If the handshake fails, nothing else happens — no data is ever sent.

Common DevOps errors when TCP fails

When a TCP connection cannot be established, you run into a familiar set of errors:

• Connection refused
• Connection timed out
• No route to host

These usually mean the application itself might be running fine, but TCP could not open a connection to it. The common causes are a firewall rule, a closed port, an app that is not listening, or simply the wrong IP or port.

What uses TCP

Almost everything you touch day to day runs on TCP, because for most things reliability matters more than raw speed.

UDP: the fast one

UDP — the User Datagram Protocol — solves a different problem. Instead of guaranteeing reliability, it optimises for speed.

• Sends data immediately — no handshake, no connection.
• Does not guarantee the data arrives.
• Does not guarantee the order it arrives in.
• Does not detect or re-send what is lost.

In short, UDP is fast but unreliable by design — and for some jobs, that trade is exactly right.

Why UDP exists

If UDP drops data, why use it at all? Because sometimes speed matters more than perfection, and losing a little data is perfectly acceptable.

• DNS queries
• Video streaming
• Online gaming
• Metrics and monitoring systems

In all of these, waiting for TCP to retry a lost packet would do more harm than just moving on. A dropped frame in a video, or a single missed metric sample, is not worth stalling for.

What uses UDP

DNS is a good example of the nuance here: it usually sends its queries over UDP first for speed, and only falls back to TCP when it has to — for example, when a response is too large to fit in a single UDP packet.

TCP vs UDP, side by side

Put next to each other, the trade-off is clear. TCP spends time to be reliable; UDP skips that time to be fast. Neither is “better” — they are built for different jobs.

How this changes your debugging

Knowing which protocol a service uses is a genuine debugging shortcut. When something breaks, two quick questions point you in the right direction: is this TCP-based or UDP-based, and does it expect reliability?

• An HTTP API that will not respond is almost always a TCP problem — a port, a firewall, or a service that is not up.
• DNS that works sometimes and fails other times often points to UDP packet loss plus a shaky network.
• Metrics that go missing are frequently just dropped UDP packets — not a bug in the app.

Testing a port from the command line

You can check reachability for both protocols with netcat (nc). The flags differ because the protocols differ — one checks for a connection, the other just fires a packet.

# Checks if TCP port 443 is open and reachable
nc -vz example.com 443

# Sends a UDP packet to port 53 (best-effort reachability check)
nc -vu example.com 53

Notice the difference: the TCP check actually confirms a connection was established, while the UDP check can only send a packet and hope — because UDP gives you nothing back to confirm with.

A real example: DNS that sometimes fails

Here is a problem you will eventually hit: your app can resolve DNS most of the time, but every so often it fails to connect. The reason is baked into how DNS works — it uses UDP, UDP packets can be silently dropped, and if your resolver or client has no retry logic, that dropped query just looks like a failure. This is exactly why DNS caching and sensible retries matter so much in production.