TCP vs UDP
Computer Networks · 10 interview questions
TCP is connection-oriented and reliable: it establishes a connection with a three-way handshake, numbers every byte, retransmits what's lost, delivers in order, and controls its sending rate. UDP does none of that — it sends datagrams and forgets them.
The interesting part is that UDP's lack of guarantees is often the point. For live audio and video, a packet that arrives late is worthless, so retransmitting it wastes bandwidth and adds delay. For DNS, a query and reply fit in one exchange and a timeout-and-retry is cheaper than a handshake.
TCP's own guarantee creates head-of-line blocking: one lost segment stalls delivery of everything behind it, even data that arrived fine. That's the specific problem QUIC was designed to solve, by running independent streams over UDP.
TCP vs UDP interview questions
- Describe the TCP three-way handshake.
- The client sends SYN with an initial sequence number. The server replies SYN-ACK, acknowledging it and sending its own. The client sends ACK. Both sides now know the other's starting sequence number and that both directions work.
- Why does the handshake need three messages rather than two?
- Because both directions must be confirmed. Two messages would prove only that the client can reach the server and that the server replied; the third confirms the client received the server's sequence number, so both sides agree on both directions.
- Why does closing a TCP connection take four messages?
- Because it closes each direction separately. Each side sends FIN and receives ACK, so a half-close is possible — one side stops sending while still receiving. The handshake can combine flags; the teardown usually cannot.
- What is TIME_WAIT and why does it exist?
- The side that closes first waits roughly twice the maximum segment lifetime before releasing the socket. It lets delayed duplicates from the old connection die out, and ensures the final ACK can be retransmitted if lost.
- Why they ask: Comes up whenever someone asks why a server has thousands of sockets in TIME_WAIT.
- What exactly does TCP guarantee that UDP doesn't?
- Delivery through retransmission, ordering through sequence numbers, deduplication, flow control and congestion control. UDP guarantees only a checksum and port multiplexing.
- When is UDP the better choice?
- Live audio and video, where a late packet is useless and retransmission adds delay for nothing. Simple request-reply like DNS, where a retry costs less than a handshake. And anything implementing its own reliability, like QUIC.
- What is head-of-line blocking in TCP?
- TCP delivers bytes in order, so one lost segment stalls everything behind it even if it arrived. With many multiplexed HTTP/2 streams on one connection, a single loss stalls all of them.
- What does QUIC change?
- It runs over UDP with independent streams, so loss in one stream doesn't block others. It also folds the TLS handshake into the transport handshake, cutting connection setup to about one round trip.
- What do sequence and acknowledgement numbers actually count?
- Bytes, not packets. The sequence number is the position of the segment's first byte in the stream; the acknowledgement number is the next byte expected, which cumulatively acknowledges everything before it.
- What is a SYN flood, and how do SYN cookies defend against it?
- An attacker sends many SYNs without completing handshakes, exhausting the half-open connection table. SYN cookies encode the connection state into the sequence number instead of storing it, so nothing is allocated until the final ACK arrives.
You'll forget most of this by next week
That's not a discipline problem, it's how memory works. In the app these come back on an expanding schedule — right before you'd lose them.
Start free for 7 days