TCP vs UDP: What's the Difference?
TCP and UDP solve the same problem — moving data from one program to another — in opposite ways. Here is the difference between TCP and UDP, how to tell which one your service needs, and what happens when you get it wrong.
The difference in one sentence
TCP guarantees that data arrives complete and in order, and is willing to wait to make that happen. UDP guarantees nothing, and never waits.
Everything else follows from that trade.
Comparison table
| TCP | UDP | |
|---|---|---|
| Connection | Established up front | None, packets go straight out |
| Delivery acknowledgement | Yes | No |
| Retransmission | Automatic | No (or handled by the app) |
| Packet ordering | Restored | However they arrive |
| Congestion control | Yes | None |
| Latency | Higher, and spikes on packet loss | Lower and steadier |
| Overhead | Larger | Minimal |
| Typical use | Websites, files, SSH, databases | Voice, video, games, DNS |
How to tell which one your service uses
No guesswork needed — it is a fixed property of the service and almost always stated in its documentation. A quick heuristic:
- Files, text, commands, pages — TCP. Losing a chunk destroys the meaning.
- A real-time stream — UDP. A stale chunk is worthless.
- A game — check that specific game; there is no single rule.
That last point is the main source of confusion:
| Service | Protocol |
|---|---|
| Minecraft Java Edition | TCP 25565 |
| Minecraft Bedrock Edition | UDP 19132 |
| CS 1.6, Day of Defeat, Condition Zero, Sven Co-op | UDP 27015 (RCON on TCP) |
| Valheim | UDP 2456–2458 |
| Terraria | TCP 7777 |
| Rust | UDP 28015 |
| TeamSpeak 3 | UDP 9987 (voice) plus TCP |
| Web server, API | TCP |
Two editions of Minecraft, two different protocols. One game, CS 1.6, using UDP for play and TCP for the admin console. So check the specific service rather than reasoning about "games" in general.
What happens if you pick the wrong one
Nothing dramatic — it simply will not work. Traffic goes out on a protocol nobody is listening on at the other end, and the client either sees the server as unreachable or hangs on connecting forever.
This is the most common cause of "the tunnel is up but I cannot join": the server speaks UDP while the tunnel was created as TCP. The fix is recreating the tunnel with the right protocol.
Can I just enable both?
Sometimes that is exactly what you need: TeamSpeak carries voice over UDP while file transfer and server queries use TCP; GoldSrc servers play on UDP and run RCON on TCP.
But "both" is not a switch — it is two independent channels. In a tunnel each protocol gets its own tunnel with its own external address. Spending slots on that is only worth it when the service genuinely needs both; most need only one.
FAQ
Which one is more secure? Neither. Encryption is a separate layer: HTTPS encrypts on top of TCP, WireGuard on top of UDP.
Which one is faster? UDP has lower latency. On a clean link the throughput difference is small — it shows up under packet loss, when TCP starts waiting and backing off.
Why are TCP and UDP ports with the same number different? The numbering is independent per protocol. The operating system distinguishes them by the protocol-plus-number pair.
What does HTTP/3 use? UDP, by way of QUIC, which layers reliability and encryption on top of UDP under its own rules, without TCP's stalls.
Opening a port on either one
A tunnel supports both protocols plus an HTTPS mode, picked with a single toggle when you create it. The general walkthrough is in How to expose a local port to the internet.
More on each: what is TCP · what is UDP