TCP vs UDP: Choosing Your Transport

📘 Chapter 2: How the Internet Works ⏱️ 7 min read 🎯 Networking Fundamentals

Below HTTP, below TLS, there's a layer that decides how data actually moves between machines. You have two choices: TCP (reliable but slower) or UDP (fast but no guarantees). This choice ripples up through your entire architecture.

TCP: The Registered Mail

TCP (Transmission Control Protocol) guarantees that every byte arrives, in order, without corruption. It's like registered mail — you get delivery confirmation, and if something gets lost, it's re-sent automatically.

TCP's Promises

  • Reliable delivery: Lost packets are detected and retransmitted
  • Ordered: Data arrives in the same sequence it was sent
  • Error-checked: Corrupted packets are discarded and re-requested
  • Flow control: Sender won't overwhelm a slow receiver
  • Congestion control: Backs off when the network is overloaded

The cost of these guarantees? TCP must establish a connection first (the "three-way handshake"), track the state of every packet, and wait for acknowledgments. This adds latency and overhead.

TCP Three-Way Handshake Client Server SYN "Hey, want to connect? My seq # is 100" SYN-ACK "Sure! ACK 101. My seq # is 300" ACK "Got it! ACK 301. Let's go!" ✓ Connection established — data can flow t=0ms t=RTT t=1.5×RTT
Fig 1. TCP three-way handshake — 1.5 round trips before any data flows. At 100ms RTT, that's 150ms of pure overhead.

UDP: The Megaphone

UDP (User Datagram Protocol) is the opposite philosophy: just send the data. No connection setup, no acknowledgments, no ordering guarantees. It's a megaphone — you shout your message and hope someone hears it.

UDP's Non-Promises

  • No delivery guarantee: Packets can be lost silently
  • No ordering: Packets may arrive out of order
  • No congestion control: Will flood the network if you let it
  • No connection state: No handshake, no teardown

The upside? Minimal overhead and latency. A UDP packet is just data with a source/destination — no state machine, no retransmission timers, no head-of-line blocking.

Side-by-Side Comparison

TCP Sending packets 1, 2, 3, 4, 5... 1 2 3✗ 4 5 ⚠️ Packet 3 lost! Everything waits... Retransmit packet 3, then deliver 3,4,5 in order 1✓ 2✓ 3✓ 4✓ 5✓ ✓ All data delivered, in order Cost: ~200ms delay waiting for retransmit Overhead: 20-byte header + state + ACKs Head-of-line blocking: YES UDP Sending packets 1, 2, 3, 4, 5... 1 2 3✗ 4 5 Packet 3 lost? ¯\_(ツ)_/¯ Keep going! Receiver gets: 1, 2, 4, 5 (immediately) 1✓ 2✓ — 4✓ 5✓ ⚡ Fast delivery, one packet missing Cost: 1 lost packet (acceptable for video/audio) Overhead: 8-byte header, no state Head-of-line blocking: NO
Fig 2. TCP vs UDP when a packet is lost — TCP blocks and retransmits; UDP skips it and keeps going.

When to Use Which

Use CaseProtocolWhy
Web pages / APIsTCPEvery byte matters — you can't render half an HTML page
Database queriesTCPA missing byte in a SQL response would be catastrophic
File transferTCPEvery bit of the file must arrive intact
Email (SMTP)TCPYou need the whole email, in order
Video streamingUDPA dropped frame is invisible; a delayed frame causes stutter
Online gamingUDPPlayer position from 200ms ago is useless — send the latest
DNS lookupsUDPSingle small packet, retry if lost — no connection overhead needed
Voice calls (VoIP)UDPA 20ms gap in audio is unnoticeable; 200ms delay is unbearable
IoT sensor dataUDPHigh volume, each reading is independent, some loss is OK

The System Design Impact

TCP Considerations at Scale

  • Connection limits: Each TCP connection consumes memory (kernel buffers, file descriptors). A server with 65,535 ports can't handle unlimited connections.
  • Head-of-line blocking: If one packet is lost on a TCP connection carrying multiple HTTP/2 streams, ALL streams stall — even unrelated ones.
  • Slow start: TCP ramps up speed gradually on new connections. Short-lived connections never reach full throughput.
  • TIME_WAIT: Closed TCP connections linger for 60 seconds, consuming ports. High-churn services can exhaust ports.

UDP Considerations at Scale

  • No built-in reliability: If you need any reliability, you build it yourself (like QUIC does on top of UDP).
  • Firewall issues: Some corporate firewalls block UDP. Your system needs TCP fallback.
  • Amplification attacks: UDP's connectionless nature enables DDoS amplification — spoofed source IPs get massive responses sent to victims.
  • Application complexity: You handle ordering, retransmission, and congestion control in your app code.

Why Video Calls Use UDP

Imagine you're on a Zoom call and packet #47 (containing 20ms of audio) is lost. With TCP, the system would pause everything, request packet #47 again, wait for it to arrive (~100ms round trip), then deliver it. By then, the conversation has moved on — you'd hear a jarring delay.

With UDP, packet #47 is simply gone. The codec interpolates or plays silence for that 20ms. You might hear a tiny glitch, but the conversation flows naturally. In real-time communication, latency is worse than loss.

Why QUIC (HTTP/3) Was Built on UDP

Google built QUIC on top of UDP to solve TCP's head-of-line blocking problem. In HTTP/2 over TCP, if one packet is lost, ALL streams on that connection freeze until it's retransmitted — even streams whose data is fully received.

QUIC on UDP gives each stream independent loss recovery. If stream A loses a packet, stream B continues unaffected. The result: 35% fewer connection failures on poor networks and measurably faster page loads on mobile connections.

QUIC also integrates TLS 1.3 into the transport layer, achieving a secure connection in just 1 round trip (vs. TCP + TLS = 2-3 round trips).

Pick the Right Transport

For each scenario, choose TCP or UDP:

1. A stock trading platform sending order confirmations

2. A multiplayer game sending player positions 60 times/second

3. A live sports score ticker updating every second

4. A security camera streaming live footage

🎯 Key Takeaway

The transport layer choice ripples up through your entire architecture. TCP gives you reliability at the cost of latency; UDP gives you speed at the cost of complexity. The right choice depends on one question: is a late packet worse than a lost packet? If yes → UDP. If no → TCP. And increasingly, protocols like QUIC show you can build custom reliability on top of UDP when you need the best of both worlds.

Further reading: "TCP/IP Illustrated" by W. Richard Stevens · QUIC RFC 9000 · Cloudflare's "The Road to QUIC" blog series