TCP vs UDP

For this lesson, we'll cover what TCP actually does for you (handshake, acknowledgements, ordering, flow and congestion control, teardown), what UDP leaves out, why QUIC rebuilt TCP's job on top of UDP, and how to pick one in a design. Interviewers ask it because "TCP is reliable, UDP is fast" is only half an answer; the interesting part is what reliability costs and when an app is better off without it.

01Picture it first: a TCP connection's whole life

The fastest way to understand TCP is to watch one connection from start to finish. Every promise TCP makes shows up as a message in this picture.

Notice four things:

• The handshake is a round trip of pure overhead. SYN, SYN-ACK, ACK agrees on starting sequence numbers before any data moves. The client's request can ride on the final ACK, so setup costs one RTT, not one and a half.
• ACKs are cumulative. "ack=x+1001" means "I have everything up to byte 1000, send 1001 next". The sender doesn't need a receipt per segment.
• Loss is repaired by the sender. It notices either because a timer expires (RFC 6298 starts it at 1 second before any RTT is measured) or because it gets three duplicate ACKs for the same byte, which triggers a fast retransmit (RFC 5681).
• Closing is a two-way goodbye. Each direction sends its own FIN, so a connection can be half-closed for a moment.

02What TCP gives you, and what each promise costs

Flow control vs congestion control

The one-line split I use: flow control protects the receiver, congestion control protects the network.

• Flow control. Every ACK carries a receive window: the free space in the receiver's buffer. If your consumer reads slowly, the window shrinks to zero and the sender pauses. That's TCP doing backpressure for you, the same idea as backpressure between services.
• Congestion control. The sender also keeps its own congestion window, a guess at what the path can carry. It starts small, roughly doubles every round trip (slow start), then grows cautiously and cuts back when it sees loss. RFC 6928 raised the starting window to 10 segments, about 14 KB with typical 1,460-byte segments, which is why a fresh connection can't send a 1 MB response in its first round trip.

The sender may have whichever window is smaller in flight. In an interview, the point is that a brand-new connection is slow on purpose, which is a big reason to reuse connections.

Head-of-line blocking

TCP hands bytes to the application strictly in order. If segment 5 is lost and 6 to 20 arrive fine, the app sees nothing past 4 until 5 is resent. For a protocol that multiplexes many requests over one connection, like HTTP/2, one lost packet stalls every request, which is the main problem QUIC was built to fix.

Teardown and TIME_WAIT

After the last ACK, the side that closed first parks the connection in TIME_WAIT for twice the maximum segment lifetime. RFC 9293 takes the MSL as 2 minutes, so 4 minutes on paper; Linux hard-codes 60 seconds. The wait makes sure stray segments from the old connection die before a new one reuses the same address and port pair.

Here's why that matters in a design. A client making many short connections to one destination burns an ephemeral port per connection. Linux's default ephemeral range is 32768 to 60999, about 28,000 ports, so at 60 seconds of TIME_WAIT that's roughly 470 new connections a second to one destination IP and port before you run out. The fix is almost never kernel tuning; it's connection pooling.

03UDP: 8 bytes and a promise of nothing

UDP (RFC 768) adds four 16-bit fields to an IP packet and stops there:

 0               16              31
+---------------+---------------+
|  source port  |  dest port    |
+---------------+---------------+
|    length     |   checksum    |
+---------------+---------------+
|  data (one datagram) ...      |

No handshake, no ACKs, no ordering, no congestion control, no connection state. Each datagram arrives once, never, or (rarely) twice or out of order. The checksum is optional over IPv4 and mandatory over IPv6 (RFC 8200). Apps that pick UDP rebuild only the parts they need:

The pattern: a voice call wants loss detection (to conceal a gap) but not recovery, because a packet that arrives 300 ms late is worse than no packet. TCP can't give you that; it will always wait for the resend.

04QUIC: UDP plus reliability in user space

QUIC (RFC 9000) is a full transport, with streams, ACKs, retransmission and congestion control, built on top of UDP and shipped inside the application or library instead of the OS kernel. HTTP/3 (RFC 9114) runs on it. Three things matter for interviews:

1. Independent streams. Loss on one stream doesn't block the others, which removes TCP's head-of-line blocking.
2. Faster setup. QUIC does the transport and TLS 1.3 handshakes together in one round trip, and can send data in the first flight (0-RTT) when resuming. Encryption isn't optional.
3. Connection IDs, not addresses. A QUIC connection is identified by an ID, so a phone moving from Wi-Fi to cellular can keep the connection instead of reconnecting (RFC 9000 calls this connection migration).

Why not fix TCP instead? TCP lives in every OS kernel and middleboxes inspect it, so changing it takes years. UDP gets through almost everywhere, and logic in user space ships with the next app release. The figure lines the two stacks up.

05Connection reuse: the cheapest latency win

Every new HTTPS connection over TCP pays a TCP handshake, then a TLS handshake, then the request itself. Reusing a connection (HTTP keep-alive, a client-side connection pool, HTTP/2 multiplexing) skips the first two entirely.

Here's how I'd do it out loud (ignoring server processing time):

With TLS 1.2 it's one more round trip per new connection. Notice which number drives the design: two thirds of the fresh-connection time is setup. Pooling, keep-alive and putting a TLS-terminating proxy close to the caller all attack that, which is also why CDNs terminate TLS near users (see CDN).

06When to pick each

This is the table I'd sketch.

07In Java, briefly

You rarely touch raw sockets in a design interview, but the API shape shows the difference.

// TCP: connect (handshake), then a reliable ordered stream
try (Socket tcp = new Socket()) {
    tcp.connect(new InetSocketAddress("orders.internal", 8080), 2_000); // connect timeout, ms
    tcp.setSoTimeout(3_000);                                            // read timeout, ms
    tcp.getOutputStream().write(request);
}

// UDP: one datagram, no connection, no delivery report
try (DatagramSocket udp = new DatagramSocket()) {
    byte[] m = "checkout.latency:42|ms".getBytes(StandardCharsets.UTF_8);
    udp.send(new DatagramPacket(m, m.length, new InetSocketAddress("metrics.internal", 8125)));
}

Notice the UDP send returns happily even if nobody is listening. Real services use a pooled HTTP client instead; HTTP and HTTPS shows one.

08Trade-offs and failure modes

09How it shows up in design problems

• Design Zoom: media over UDP with loss concealment, signalling and chat over TCP. Saying "two transports for two jobs" is a strong signal.
• Design WhatsApp and Slack / Discord: long-lived TCP connections (WebSockets) per device; the deep dive is connection count per server and reconnect storms.
• Design a payment system: TCP plus TLS, pooled connections to the provider, timeouts and idempotent retries.
• Design a rate limiter: the limiter sits on the hot path, so pooled connections to its counter store matter more than you'd think.

At this point, you should ask your interviewer whether clients are on mobile networks. If they are, the transport choice (and HTTP/3) becomes part of your latency story.

10Follow-up questions

What if your service starts failing with thousands of sockets in TIME_WAIT?

That's a client opening and closing short connections to the same destination, and running out of ephemeral ports (about 28,000 by default on Linux, each held for 60 seconds). I'd fix the cause: a connection pool with keep-alive so a few hundred long-lived connections carry the traffic. Kernel options that reuse TIME_WAIT sockets exist, but they treat the symptom.

What if a user's phone switches from Wi-Fi to 5G in the middle of an upload?

Over TCP the connection is tied to the old IP address and port, so it breaks and the app must reconnect, redo TCP and TLS, and resume the upload, ideally from the last acknowledged chunk. Over QUIC the connection ID survives the address change, so the transfer continues. Either way, I'd design uploads as resumable chunks so a dropped connection costs one chunk, not the whole file.

What if you need reliable messages for a game but can't afford head-of-line blocking?

Split traffic by what it needs. Position updates go unreliable and unordered, since only the latest one matters. Events that must arrive (a purchase, a match result) go on a reliable channel: either your own ACK and resend on UDP, or separate QUIC streams so one lost event doesn't freeze movement updates.

What if the interviewer pushes: "Why not run HTTP/3 between your internal services too?"

Inside a data centre, loss is low, RTTs are about a millisecond and connections are long-lived and pooled, so QUIC's wins (faster setup, no cross-stream blocking on lossy links, migration) mostly disappear. Meanwhile TCP has mature kernel offloads, load balancer support and debugging tools. I'd use HTTP/3 at the internet edge where users are, and keep HTTP/2 or gRPC over TCP inside unless measurements say otherwise.

11How to say it in the interview

When I ask "TCP or UDP?", I'm listening for three things: that you know what TCP's reliability costs (round trips and head-of-line blocking), that you can say what a UDP app has to rebuild, and that you pick per use case rather than per system.