TCP vs UDP

Why it matters

Transport is the layer that decides whether your bytes arrive in order, arrive at all, or arrive fast. Pick TCP and you get correctness for free but every lost packet stalls the stream; pick UDP and you get speed but must handle loss yourself. Video calls, games, DNS and HTTP/3 chose UDP for good reasons; databases, APIs and file transfers chose TCP for equally good ones. Knowing why lets you defend either choice.

The idea

Both protocols move data between ports on two hosts. They differ in what they promise.

TCP (Transmission Control Protocol) provides a connection: a three-way handshake to set it up, sequence numbers so the receiver can reorder and detect gaps, acknowledgements and retransmission so lost segments are resent, flow control so a fast sender does not overwhelm a slow receiver, and congestion control so senders back off when the network is full. The application sees a reliable, ordered byte stream.

UDP (User Datagram Protocol) provides none of that. It adds ports and a checksum to IP and sends each datagram independently. No handshake, no ordering, no retransmission, no congestion control. The application sees whatever arrives, in whatever order, and decides what to do about the rest.

Head-of-line blocking

TCP's ordering guarantee has a cost. If segment 2 is lost, segments 3 through 10 may have arrived, but the application cannot read them until 2 is retransmitted and arrives. For a file download that is correct. For a video call it is disastrous: the frame from 200 milliseconds ago is worthless, and waiting for it delays every frame after. Real-time workloads would rather drop a frame than stall the stream, which is why they use UDP and handle loss at the application layer.

QUIC: UDP with the good parts rebuilt

QUIC, the transport under HTTP/3, runs over UDP and reimplements reliability, ordering and congestion control per stream rather than per connection. One lost packet stalls only the stream it belonged to, not every request sharing the connection. It also folds the TLS handshake into connection setup, so a secure connection takes one round trip instead of two or three. It is the answer to "I want TCP's guarantees without TCP's head-of-line blocking".

	TCP	UDP	QUIC
Connection	Handshake, 1 RTT (plus TLS)	None	1 RTT including TLS, 0 on resume
Delivery	Reliable, ordered stream	Best effort, unordered datagrams	Reliable, ordered per stream
Loss handling	Retransmit; stalls the stream	Application decides	Retransmit; stalls one stream only
Congestion control	Built in	None; you must add it	Built in
Overhead	20+ byte header, state per connection	8 byte header, stateless	Moderate; encrypted headers
Use for	APIs, databases, file transfer, web (HTTP/1.1, HTTP/2)	DNS, video, voice, games, telemetry	HTTP/3, mobile-heavy clients, lossy networks

Trade-offs

TCP buys correctness with latency: a handshake before the first byte, and stalls on loss. UDP buys speed and control with responsibility: no delivery guarantee, no congestion control, so a careless UDP sender can flood a network and will be throttled or blocked by middleboxes. QUIC buys the best of both with CPU cost (it runs in user space) and with operational unfamiliarity (some networks still block or deprioritise UDP).

In an interview

Default to TCP for anything request-response and say so without ceremony. Reach for UDP, and explain the loss strategy, when freshness beats completeness: "Live video uses UDP with forward error correction and frame dropping; waiting for a retransmitted frame is worse than skipping it." Mention QUIC when the client population is mobile or the connection count is high; it shows you know where transport is going.