TCP vs UDP for Developers — When the Protocol Actually Matters

You’re building a multiplayer game. Players are complaining about lag. You’ve optimized your server code, reduced database queries, and your p99 latency looks fine. The problem is simpler: you’re using TCP. That’s it. That’s the lag.

TCP and UDP aren’t just two boxes on a protocol checklist — they represent fundamentally different bets on what the network will do. The wrong choice doesn’t just cost you performance. It changes the character of the failure when things go wrong.

The bet TCP makes

TCP promises you a reliable, ordered byte stream. If a packet drops, TCP will retransmit it. If packets arrive out of order, TCP will reorder them. Your application sees clean, sequential data, every time.

That guarantee costs you three things:

• Handshake latency — TCP requires a three-way handshake before a single byte of application data moves. On a 50ms round-trip network, you’re burning 150ms before your first request even starts.
• Head-of-line blocking — This is the one that kills games. If packet #5 drops, TCP holds packets #6, #7, and #8 in a buffer waiting for #5 to be retransmitted and arrive. The stream is blocked. Your player’s position update from 100ms ago is sitting in a buffer while the network sorts itself out.
• Congestion control overhead — TCP’s congestion window algorithm (CUBIC, BBR, etc.) throttles send rate when it detects loss. On a lossy network, this means TCP reduces throughput at exactly the moment the network is struggling — which is when your users feel it most.

What UDP actually gives you

UDP sends a datagram and doesn’t look back. No handshake, no acknowledgement, no retransmit. If a packet drops, it’s gone. The receiver gets whatever arrives, in whatever order it arrives.

That’s not a limitation — it’s the point. When you need low latency more than you need delivery guarantees, UDP lets you make that tradeoff explicitly. The reliability logic moves into your application layer, where you can make smarter decisions about what actually needs retransmitting.

In a game, a player position update from 50ms ago is worthless — you want the current one. With TCP, you’d buffer and wait. With UDP, you send the latest state and skip anything stale. The experience is smoother even under more packet loss.

TCP vs UDP: the comparison that actually matters

Propiedad	TCP	UDP
Connection setup	3-way handshake (adds 1.5× RTT before first byte)	None — fire immediately
Delivery guarantee	Yes — retransmit on loss	No — send and forget
Packet ordering	Enforced by the stack	Your problem
Head-of-line blocking	Yes — one lost packet stalls the stream	No — each datagram is independent
Congestion control	Built-in (CUBIC, BBR, etc.)	None — implement your own or skip it
Typical latency overhead	150–300ms on cold connections	Sub-millisecond
Casos de uso	HTTP/1.1, HTTP/2, databases, file transfer, email	DNS, gaming, live video, HTTP/3 (QUIC)

Where each protocol actually belongs

DNS runs over UDP — and there’s a lesson in that

Every DNS query your application makes goes over UDP by default. The request fits in a single packet, the response fits in a single packet, and you get your answer in one round trip. No handshake overhead, no state to maintain on the server.

If the response is too large (DNSSEC records, many A records), DNS falls back to TCP. But the common case — a lookup for a hostname — is pure UDP because the tradeoff is obvious: the three-way handshake would take longer than the actual query.

You can see this behavior in action with the IO Tools DNS Lookup tool — punch in a domain and watch how fast individual record types resolve. That speed is UDP eliminating a full round trip of handshake overhead.

Gaming: UDP is the only real answer

Every major game networking library — Valve’s GameNetworkingSockets, Epic’s EOS transport, Unity’s UTP — is built on UDP. The reason is head-of-line blocking.

In a competitive FPS, you’re sending position updates at 64 tick — every 15ms. If one packet drops and TCP holds the next five while waiting for a retransmit, you’ve introduced 75ms of stutter at exactly the wrong moment. With UDP, you send the next update immediately. The client interpolates over the gap. The experience is smooth.

Most game networking code built on UDP implements its own selective reliability — sequence numbers, priority queues, selective ACKs — but only for data that actually needs it: chat messages, item pickups, match state. Position data is unreliable by design. A stale reading is worse than no reading.

Video streaming: it depends on the use case

Live streaming (Twitch, sports broadcasts) uses UDP-based protocols — RTP, WebRTC, SRT — because a few dropped frames are acceptable but latency is not. You can’t buffer 30 seconds of a live match to guarantee smooth delivery.

VOD (Netflix, YouTube) actually uses TCP, because buffering hides the cost. A few seconds of pre-buffer means TCP’s retransmit overhead is invisible — you just see smooth playback. The latency penalty doesn’t matter when you’re watching something that happened yesterday.

HTTP/3 runs on UDP — and it changes web performance

HTTP/3 runs over QUIC, which runs over UDP. Google built QUIC specifically to fix TCP’s head-of-line blocking problem for web traffic. With HTTP/2 over TCP, a single lost packet stalls all multiplexed streams sharing that connection. QUIC implements stream multiplexing at the transport layer with independent acknowledgement — one lost packet stalls one stream, not all of them.

QUIC also integrates TLS into the handshake, reducing cold connection setup to a single round trip (0-RTT on session resumption). On lossy networks — mobile connections, congested WiFi — this is a meaningful improvement. As of 2024, roughly 30% of websites support HTTP/3, and all major browsers enable it by default. If you’re deploying behind Cloudflare or a modern CDN, you’re probably already serving HTTP/3 without having configured it explicitly.

The practical decision tree

When you’re choosing a transport for a new protocol or service, the question isn’t “TCP or UDP?” — it’s “which failures can I tolerate?”

• Every byte must arrive, in order, or the operation fails → TCP. File uploads, database connections, API calls, email. Missing data means corrupt data or a parse error.
• Latency matters more than guaranteed delivery → UDP. Games, live video, voice calls, sensor telemetry. A stale reading is worse than no reading.
• You need both, per-message → Build on UDP with selective reliability. QUIC does this. WebRTC’s SCTP data channel does this. Libraries like ENet and GameNetworkingSockets do it too — though implementing it yourself is non-trivial work that’s easy to get subtly wrong.

One mistake worth calling out: assuming “internal traffic” means you can use UDP carelessly. Packet loss within a datacenter is rare but not zero — hardware failures, network congestion under peak load, misconfigured switches. If your application silently corrupts data on loss, an internal network won’t save you.

Wrapping up

TCP is the right default for most application code. If you’re making API calls, talking to a database, or transferring files, TCP’s guarantees are exactly what you need and the overhead is invisible at human timescales.

UDP is the right choice when latency is a hard constraint and your application can own its relationship with reliability. That’s a specific set of problems — real-time games, live media, custom protocols — not a general performance optimization to reach for when TCP feels slow.

The actual mistake isn’t using TCP when UDP would be faster. It’s not knowing which one you’re choosing, or why, and being surprised when the failure mode arrives.

También te puede interesar