TCP vs UDP
“Compare TCP and UDP. When would you choose UDP, and what do you have to build yourself when you do?”
What this tests
- The guarantees TCP provides and their cost
- Real use cases for UDP and the reliability that is rebuilt on top of it
- The understanding that "reliable vs unreliable" is about latency trade-offs
Answers by level
Read the beginner answer first and notice what is missing.
TCP gives an ordered, reliable byte stream between two endpoints: a handshake to set up state, sequence numbers to reassemble in order, acknowledgements and retransmission to recover loss, flow control (rwnd) so the receiver is not overrun, and congestion control (cwnd) so the network is not. UDP gives datagrams: a header of 8 bytes (ports, length, checksum) over IP, with no connection, no ordering, no retransmission, no rate control. Each datagram is delivered whole or not at all.
The price of TCP’s guarantees is time: one round trip before the first byte, and — crucially — head-of-line blocking: if segment 5 is lost, segments 6–20 wait in the receive buffer until 5 is retransmitted, even though the application might have used them. For a video call, a game state update or a DNS query, a packet that arrives 200 ms late is worthless; better to drop it and use the next one. That is when UDP wins: latency-sensitive data where the application knows better than the transport what to do about loss.
Choosing UDP means building what you need yourself: your own sequence numbers if order matters, your own acknowledgements and retransmission for the parts that must arrive (a game’s "you scored" message, but not a position update), your own congestion control so you do not flood the path, your own handshake if you need to prevent spoofed sources. DNS needs none of that for a single query/response (it just retries). QUIC builds all of it — plus TLS — in user space on top of UDP, which is how HTTP/3 gets streams that do not block each other on loss.
Green flags · Red flags
- Names the concrete TCP mechanisms (handshake, sequence numbers, ACKs, rwnd, cwnd) rather than "reliable"
- Explains head-of-line blocking as the reason latency-sensitive apps avoid TCP
- Lists what must be rebuilt over UDP and mentions QUIC as the full-scale example
- Says UDP is not faster per byte, just non-blocking
- Mentions an operational hazard: NAT timeouts, blocked UDP, no backpressure
- Says UDP is faster and stops there
- Believes UDP is only for "unimportant" data
- Does not know UDP has no congestion control
- Thinks QUIC eliminates all head-of-line blocking (it removes cross-stream blocking; loss still blocks within a stream)