TCP vs UDP: The Two Languages of the Internet

The Post Office vs The Radio Station

Imagine you need to send important legal documents to someone across the country. You would use registered mail - the post office tracks every step, gets a signature on delivery, and you know exactly when it arrived. That is TCP.

Now imagine you are a radio DJ broadcasting a live concert. You do not wait for each listener to confirm they heard the last note before playing the next one. You just keep streaming. Some listeners might miss a few seconds if their reception drops, and that is fine because the show must go on. That is UDP.

These two protocols carry every byte of data across the internet. Every time you load a webpage, send a message, stream a video, or play an online game, one of them is doing the heavy lifting underneath. Let us understand both deeply.

TCP: The Reliable Delivery Truck

TCP stands for Transmission Control Protocol. When your browser loads a webpage, it uses TCP because every single byte matters. If even one packet of data gets lost, the page would break. So TCP does something very careful:

1. It establishes a connection first (called a three-way handshake - like calling someone and waiting for them to say hello before talking)

2. It numbers every packet so the receiver can put them back in order

3. The receiver sends back acknowledgments (ACKs) for each packet received

4. If a packet goes missing, TCP automatically resends it

5. When done, it formally closes the connection (like saying goodbye before hanging up)

This reliability has a cost: it is slower. Each of those acknowledgments takes time. If you are sending a file from New York to Tokyo, each round-trip acknowledgment travels 13,000 kilometers. That adds up.

Flow Control and Congestion Control

TCP also has two built-in safety mechanisms most people do not know about. Flow control ensures the sender does not overwhelm a slow receiver - using a sliding window mechanism, the receiver advertises how much buffer space it has, and the sender never exceeds it. Congestion control prevents network overload - TCP starts slow (slow start), gradually increases speed, and backs off if it detects packet loss. This is why a fresh TCP connection takes a few round trips to reach full throughput.

UDP: The Speed Demon

UDP stands for User Datagram Protocol. It is beautifully simple. Take your data, slap a destination address on it, and throw it into the network. No handshake. No acknowledgments. No ordering guarantees. No retransmission.

Why would anyone want this? Because sometimes speed matters more than perfection:

• Video calls - if a frame arrives late, you would rather skip it than freeze the whole call waiting for a retransmission

• Online gaming - you need the latest position of other players NOW, not the position from 200ms ago that got lost

• DNS lookups - it is just a quick question and answer, no need for the overhead of establishing a full connection

• Live streaming - viewers can tolerate a tiny glitch but cannot tolerate a 3-second buffer delay

The Three-Way Handshake Visualized

Before TCP sends any real data, it does this dance:

  Client                          Server
    |                               |
    |---- SYN (seq=100) ----------->|
    |                               |
    |<--- SYN-ACK (seq=300,ack=101)-|
    |                               |
    |---- ACK (ack=301) ----------->|
    |                               |
    |==== Data flows both ways =====|
    |                               |

  Total time: 1 full round-trip (RTT)
  At 50ms latency = 50ms before first byte

Step by step: first the client sends SYN saying 'Hey, I want to talk. My starting sequence number is 100.' Then the server responds with SYN-ACK saying 'Got it! I am ready too. My starting number is 300. I acknowledge your 100.' Finally, the client sends ACK saying 'Great, I acknowledge your 300. Let us begin!' Only after this exchange does actual data flow.

UDP skips all of this - data starts flowing immediately with zero round trips of setup.

TCP vs UDP: Side-by-Side Comparison

Feature              TCP                    UDP
-----------------------------------------------------------
Connection setup     3-way handshake        None (connectionless)
Reliability          Guaranteed delivery    Best-effort (fire & forget)
Ordering             Packets arrive in      No ordering guarantee
                     order guaranteed
Speed                Slower (ACK overhead)  Faster (no overhead)
Header size          20-60 bytes            8 bytes
Congestion control   Built-in (backs off)   None (can flood)
Use cases            Web, APIs, files,      Video, VoIP, gaming,
                     email, databases       DNS, metrics, IoT

When to Use Which in System Design

Here is the practical decision framework for your architectures:

• Use TCP when data integrity matters: APIs, database connections, file transfers, emails, web pages

• Use UDP when speed matters and you can tolerate loss: video streaming, VoIP, gaming, metrics collection, IoT sensor data

• Use UDP with your own reliability layer when you need speed AND some guarantees: this is what QUIC (HTTP/3) does - it builds reliable streams on top of UDP, so it gets the speed of UDP with custom reliability per stream

Real-World Example: Why Netflix Uses Both

Netflix uses TCP for its API calls (fetching your watchlist, recommendations, account info) because that data must be perfect. But for the actual video stream, they use adaptive protocols that can tolerate packet loss, prioritizing smooth playback over perfect frame delivery. Discord does the same split: text chat (TCP, every message matters) and voice calls (UDP, a dropped audio frame is better than a frozen call).

Numbers That Matter

When estimating in system design interviews, these are the numbers worth knowing:

• TCP handshake adds 1 RTT (50-200ms across continents) before data flows

• TCP header is 20-60 bytes per packet vs UDP header at just 8 bytes

• TCP slow start means a new connection takes 3-4 RTTs to reach full bandwidth

• A single TCP connection between US and Europe has a theoretical max of ~15 Mbps due to the round-trip-based congestion window

• UDP can push data at line rate from the very first packet - no warm-up needed

Interview Tip

When an interviewer asks 'TCP or UDP?' they are testing whether you understand trade-offs. Never say one is better. Say: 'For this component I would use TCP because data integrity matters and latency is acceptable. For this other component I would use UDP because the latest data matters more than every data point arriving.' Then mention QUIC as a modern hybrid. That shows depth.

Key Takeaway

TCP guarantees delivery at the cost of latency. UDP prioritizes speed at the cost of reliability. Great system designers know which trade-off fits each component of their architecture. The trend is toward QUIC - reliable streams built on UDP - which gives you the best of both worlds.

Read on the next topic: HTTP/1.1, HTTP/2, and HTTP/3 (QUIC): The Evolution of Web Communication
Start solving HLD Levels: Level 1