TCP vs UDP, reliable letters vs shouted postcards

Field note. Game servers split traffic between both. Minecraft's handshake and chat ride TCP. Some action games push movement updates over UDP. Knowing which is which tells you what kind of network problem you have.

If IP and ports answer "where," TCP and UDP answer "how." They are the two main protocols that ride on top of IP and decide how data actually gets delivered. They behave so differently that picking the right one shapes the personality of the application using them.

This article explains both, with the specific use cases that make each one obvious.

The high-level distinction

TCP (Transmission Control Protocol) is the reliable, ordered, slow option. It's like sending registered mail: the post office confirms delivery, retransmits if anything goes missing, and guarantees the letters arrive in the order you sent them.

UDP (User Datagram Protocol) is the unreliable, unordered, fast option. It's like shouting from across a field: you say your piece, the listener catches what they catch, and you don't know what they missed.

That's the headline. The interesting question is when each is the right tool.

Why TCP exists

The internet's underlying protocol (IP) makes very few promises. Packets can:

• Arrive out of order.
• Get duplicated.
• Get dropped entirely.
• Take wildly different times to arrive.

For many applications, this is unacceptable. If you're loading a webpage, you want the HTML to arrive complete, in order, and only once. TCP provides this on top of IP.

TCP does several things:

1. Connection setup. A "three-way handshake" establishes a connection before data flows. The client sends SYN, the server replies SYN-ACK, the client replies ACK. Now both sides know they're talking.

2. Sequence numbers. Every byte sent has a position in the stream. The receiver can reassemble bytes in the correct order even if packets arrive out of order.

3. Acknowledgments. The receiver tells the sender what it has successfully received. If something isn't acknowledged, the sender retransmits.

4. Flow control. The receiver advertises how much data it can handle. The sender respects this, slowing down if the receiver is overwhelmed.

5. Congestion control. TCP probes the network's capacity. If it detects packet loss (a sign of congestion), it slows down. When it doesn't, it speeds up. This is the magic that keeps the internet from collapsing under load.

The cost of all this: latency. TCP requires at least one round-trip before any data flows. It introduces retransmission delays when packets are lost. It slows itself down when it senses problems, even if that's overcautious.

For loading a webpage, this is fine. For sending a real-time game position update, it can be catastrophic.

Why UDP exists

UDP is essentially "IP with ports added and almost nothing else." There's no handshake. No retransmission. No ordering. No congestion control.

When you send a UDP packet, you fill out:

• Source IP and port.
• Destination IP and port.
• The data.
• A checksum.

That's the whole header. The packet goes out. It either arrives or it doesn't. If it doesn't, you don't get notified. If it arrives out of order, the receiver gets it out of order. The reliability is your job (if you want it).

Why would you choose this? Because TCP's reliability comes at a cost in latency, and some applications would rather drop data than wait for retransmission.

When TCP is right

Web browsing (HTTP/HTTPS). Webpages must arrive complete. A missing byte means a broken page. TCP makes this trivially reliable.

File downloads. You need every byte. TCP retransmits anything missing.

Email. Email integrity matters. TCP is mandatory.

Database connections. Queries and responses must be reliable.

Remote shell (SSH). Commands and outputs must arrive in order.

Most gaming control traffic. Inventory changes, login, chat. Things that must arrive but aren't time-sensitive.

If your application can tolerate a few milliseconds of extra latency for guaranteed delivery, TCP is almost always the right choice.

When UDP is right

Real-time games. Player positions, projectile trajectories, mob updates. If a packet is lost, you don't want to wait for retransmission, because by the time it arrives the game state has moved on. You'd rather miss one update and get the next one fresh.

Voice and video calls. Same logic. If a packet is dropped, replaying it 200ms later is worse than just continuing with the next packet. The brain is forgiving of small audio/video glitches; it is not forgiving of latency.

DNS queries. A DNS query is tiny (often under 100 bytes). The cost of TCP's setup is higher than the cost of just sending it as a UDP packet and retrying if no answer comes. Modern DNS uses both, but the default for small queries is still UDP.

Streaming media (some forms). Live broadcasts often use UDP because mid-stream packet loss is preferable to retransmit-induced jitter.

Network monitoring (SNMP, syslog). Small messages, frequent, where occasional loss is fine.

The pattern: UDP is right when latency matters more than reliability, and when the application can handle loss gracefully.

How games use both

Modern game servers typically use both, for different purposes.

TCP for:

• Initial login and authentication.
• Chat messages.
• Inventory changes.
• "Big" events like landing in a new level.
• Anything where reliability matters more than ms-level timing.

UDP for:

• Per-tick player positions.
• Mob movements.
• Projectile updates.
• Real-time voice chat.

Minecraft Java is unusual: it uses TCP for everything. This is a known limitation. Many gamers wonder why Minecraft "feels laggy" on slightly imperfect networks. Part of the answer: TCP retransmissions during packet loss cause stalls. Bedrock Edition uses UDP (via a custom protocol called RakNet), which is part of why Bedrock often feels smoother on poor connections.

Most other multiplayer games (Valve's source games, Call of Duty, Fortnite, etc.) use UDP for the time-critical data with custom application-level reliability for anything that needs to be guaranteed.

"Reliable UDP" is a thing

You can build reliability on top of UDP. Many games do. The pattern:

• Send a UDP packet for a critical event (e.g., a hit confirmation).
• Include a sequence number.
• Receiver acknowledges.
• If no ack within a deadline, sender retransmits.

This gives you UDP's low latency for the things that don't need reliability, and reliability where you actually need it, without TCP's "everything is ordered" stalls. The downside: you write the reliability code yourself.

Modern protocols like QUIC (Google's, now standardized) are essentially "TCP-quality reliability built on UDP foundations." HTTP/3 uses QUIC. QUIC handles loss without head-of-line blocking, can do faster handshakes, and migrates connections across network changes more gracefully than TCP.

Head-of-line blocking, the TCP weakness

Here's the specific TCP problem games suffer from.

TCP guarantees in-order delivery. Suppose you send segments 1, 2, 3, 4, 5. Segment 3 is dropped. Segments 4 and 5 arrive and sit in the receiver's buffer. The application can't see them yet, because TCP won't deliver them until 3 arrives. So the sender retransmits 3. Until that arrives, segments 4 and 5 are blocked.

This is head-of-line blocking. For games, where positions are time-sensitive, blocking 4 and 5 while waiting to redeliver 3 means the player sees old information when newer information is sitting in the buffer.

UDP doesn't have this problem: 4 and 5 arrive and the application deals with them immediately. 3 might never arrive; that's fine. The game just keeps moving.

QUIC solves this within a TCP-like model. It maintains multiple independent streams, so loss in one doesn't block the others.

The mental model

When you see a protocol mentioned as TCP or UDP, you can predict its behavior:

• TCP: reliable, ordered, slower setup, retransmission-tolerant, head-of-line blocking risk.
• UDP: unreliable, unordered, instant setup, application handles reliability.

When you're configuring a firewall, you need to know which one your service uses. Some games need both (Valheim uses UDP for game traffic; an admin panel might use TCP).

When you're picking a protocol for an app you're writing, the question is: "can my application tolerate loss?" If yes (e.g., positions), UDP. If no (e.g., chat), TCP.

A practical test

If you're not sure what your game uses, watch its server config or its required firewall rules:

• Valheim: UDP ports 2456-2458.
• Minecraft Java: TCP port 25565.
• Minecraft Bedrock: UDP port 19132.
• Vintage Story: UDP port 42420.
• Source-engine games: usually UDP 27015.

The protocol is determined by the application. You as the operator just open the right ports.

Why this matters for hosting

Three takeaways for game hosting:

1. Open the right ports for the right protocol. Players can't connect to a UDP service if you only opened the TCP version of the port.

2. TCP and UDP have different DDoS profiles. TCP floods exhaust connection tables; UDP floods exhaust bandwidth. Different protection strategies for each.

3. Game feel can be improved by switching to a protocol that uses UDP. If you're choosing between Minecraft Java and Bedrock for a casual community, Bedrock's UDP-based netcode can be more forgiving on imperfect networks. Java's TCP-based netcode is unforgiving.

What's coming

Next: packets. We've talked about packets abstractly. Now we'll see what they actually look like inside, how they're framed, and how the network handles them at scale. That's the building block under both TCP and UDP.