TCP vs UDP

"TCP vs UDP" is a networking interview certainty — it tests whether you understand the reliability-vs-speed trade-off and can match protocols to use cases. Know the differences cold and which real protocols use each.

The core difference

TCP (Transmission Control Protocol) is connection-oriented and reliable: it sets up a connection (3-way handshake), guarantees ordered, error-checked, retransmitted delivery, and provides flow and congestion control. UDP (User Datagram Protocol) is connectionless and unreliable: fire-and-forget datagrams with no handshake, ordering, or retransmission — but far lower overhead and latency.

Aspect	TCP	UDP
Connection	connection-oriented	connectionless
Reliability	guaranteed	best-effort
Ordering	yes	no
Speed	slower	faster
Header	20 bytes	8 bytes
Flow/congestion control	yes	no

Use cases

• TCP: HTTP/HTTPS, email (SMTP), file transfer (FTP) — correctness matters.
• UDP: DNS, video/voice streaming, VoIP, online gaming, DHCP — speed matters, occasional loss is OK.

Exam Tricks & Tips

• 🎯 TCP = reliable, ordered, connection-oriented (handshake); UDP = fast, connectionless, best-effort — the one-line contrast.
• 🎯 TCP header is 20 bytes, UDP header is 8 bytes — UDP's lower overhead is why it's faster.
• 🎯 DNS, streaming, VoIP, gaming, DHCP use UDP; HTTP, email, FTP use TCP — memorise these examples.
• 🎯 TCP provides flow control (receiver pace) and congestion control (network pace); UDP provides neither.
• 🎯 UDP is preferred when low latency beats reliability — a dropped video frame is better than a stalled stream.
• 🎯 HTTP/3 runs over QUIC, which is built on UDP — a modern twist worth knowing.
• ❌ Common mistake: saying UDP guarantees delivery — it's best-effort with no retransmission or acknowledgements.

Expected pattern

"TCP vs UDP", "which uses UDP: DNS or FTP?", "why is UDP faster?", "header sizes", "what does TCP provide that UDP doesn't?", and matching protocols to their transport.

Quick recap

TCP: connection-oriented, reliable, ordered, flow/congestion control, 20-byte header — HTTP/email/FTP. UDP: connectionless, best-effort, unordered, 8-byte header, low latency — DNS/streaming/VoIP/gaming/DHCP. Choose TCP for correctness, UDP for speed. HTTP/3 uses QUIC over UDP.

Cover the answer, recall, then check. 12 cards on TCP vs UDP.

Q1. Is TCP connection-oriented or connectionless?
A1. Connection-oriented — it establishes a connection via a three-way handshake before data transfer.

Q2. Is UDP reliable?
A2. No — it is best-effort/connectionless, with no guaranteed delivery, ordering, or retransmission.

Q3. Why is UDP faster than TCP?
A3. No handshake, acknowledgements, ordering, or congestion control, and a smaller header — less overhead and latency.

Q4. What are the TCP and UDP header sizes?
A4. TCP header is 20 bytes (minimum); UDP header is 8 bytes.

Q5. Name three protocols/applications that use UDP.
A5. DNS, video/voice streaming, VoIP, online gaming, DHCP (any three).

Q6. Name three that use TCP.
A6. HTTP/HTTPS, email (SMTP), and file transfer (FTP).

Q7. What two control mechanisms does TCP provide that UDP lacks?
A7. Flow control (matching sender to receiver pace) and congestion control (adapting to network conditions).

Q8. Does TCP guarantee ordered delivery?
A8. Yes — it reorders segments and delivers data in the order sent; UDP does not.

Q9. When would you prefer UDP over TCP?
A9. When low latency matters more than reliability — real-time streaming, gaming, VoIP, where occasional loss is acceptable.

Q10. How does TCP handle lost packets?
A10. It detects missing acknowledgements and retransmits the lost segments.

Q11. What transport protocol does HTTP/3 (QUIC) use?
A11. UDP — QUIC is built on top of UDP.

Q12. One-line contrast of TCP and UDP?
A12. TCP is reliable, ordered, and connection-oriented; UDP is fast, connectionless, and best-effort.

At the transport layer you choose one of two protocols, and the choice shapes everything above it: TCP (reliable, ordered, slower) or UDP (fast, best-effort, lightweight). Comparing them is one of the most common networking interview questions.

Core idea: TCP (Transmission Control Protocol) is connection-oriented and reliable — it guarantees ordered, error-checked, complete delivery via handshakes, acknowledgements and retransmission. UDP (User Datagram Protocol) is connectionless and best-effort — it just fires datagrams with minimal overhead, trading reliability for speed.

How it works

Beginner — the fundamental contrast

• TCP: like a phone call — establish a connection (handshake), talk with confirmation, hang up. Reliable but with setup cost.
• UDP: like a postcard — write the address and send; no connection, no guarantee it arrives or arrives in order, but instant and cheap.

Intermediate — the feature table

Feature	TCP	UDP
Connection	connection-oriented (3-way handshake)	connectionless
Reliability	guaranteed (ACKs + retransmit)	best-effort (no guarantee)
Ordering	in-order (sequence numbers)	unordered
Speed / overhead	slower, 20-byte header	faster, 8-byte header
Flow/congestion control	yes	no
Use cases	web, email, file transfer	streaming, gaming, DNS, VoIP

Advanced — the reliability machinery and why UDP omits it

TCP achieves reliability with: sequence numbers (order + detect loss), acknowledgements + retransmission timers (resend lost data), flow control (a sliding window so a fast sender doesn't overwhelm a slow receiver), and congestion control (slow-start/AIMD to avoid collapsing the network). All of this adds latency and state. UDP deliberately omits it — no handshake, no ACKs, no ordering — so it's ideal when timeliness beats completeness: in live video a late-but-perfect packet is useless, so you'd rather drop it than wait for a retransmission. Applications needing reliability over UDP (like QUIC/HTTP-3) rebuild it themselves for finer control.

Worked example — choosing the protocol

Two scenarios:

1. Downloading a file / loading a web page: every byte must arrive correctly and in order — a single missing byte corrupts the file. → TCP (its retransmission and ordering are exactly what's needed).
2. Live video call (VoIP): a 200 ms-old audio packet is worthless; retransmitting it would add lag and stutter. Better to skip it and play the next. → UDP (low latency, tolerate loss).
   The decision rule: use TCP when you can't lose data, UDP when you can't wait. DNS uses UDP for its small, fast, single-request queries (falling back to TCP for large responses) — a classic example of picking speed over connection overhead.

Interview & exam relevance

Guaranteed: "difference between TCP and UDP", "when would you use UDP over TCP", "why is UDP faster", "does UDP guarantee delivery/order" (no to both), and "which protocol does DNS/HTTP/video streaming use". The feature table and use-case reasoning are the graded content.

Tricks & gotchas

• TCP guarantees delivery and order; UDP guarantees neither — applications must handle loss themselves if needed.
• UDP's smaller 8-byte header (vs TCP's 20) and lack of handshake/state are why it's faster and lighter.
• "Connectionless" (UDP) means no setup handshake — not that data can't be sent, just that there's no established session.
• Mnemonic: "TCP = Trustworthy (Careful Protocol); UDP = Unreliable Datagram (Prompt)."

Worked Example

Problem: For each application, choose TCP or UDP and justify with the specific property that matters: (a) transferring a bank statement PDF, (b) a live video call, (c) a DNS lookup, (d) online multiplayer game position updates. Then explain what "reliability" costs in latency.

Solution:
TCP is connection-oriented and reliable: it does a 3-way handshake, numbers bytes, acknowledges them, retransmits losses, reorders segments, and applies flow + congestion control — guaranteeing an ordered, complete byte stream. UDP is connectionless and best-effort: it just fires datagrams with a checksum, no handshake, no ACK, no retransmit, no ordering — minimal overhead and latency.

(a) Bank statement PDF → TCP. Every byte must arrive intact and in order; a single missing byte corrupts the file. Reliability and ordering are essential and there is no hard latency deadline. → TCP.

(b) Live video call → UDP. Timeliness beats perfection: if a packet is lost, retransmitting it (TCP) would arrive too late and stall playback. It is better to drop the packet and keep going (a momentary glitch) than to wait. Real-time media therefore uses UDP (often via RTP), tolerating loss for low latency.

(c) DNS lookup → UDP (primarily). A query/response fits in one small datagram; UDP avoids the handshake round-trips, so resolution is fast. If the response is too large or truncated, DNS falls back to TCP. The dominant case is a single quick UDP exchange.

(d) Multiplayer game position updates → UDP. Positions are sent many times per second; a lost update is instantly superseded by the next one, so retransmitting stale data is pointless and would add lag. Low latency matters more than delivering every packet. → UDP.

Reliability's latency cost: TCP's guarantees require a handshake before any data (extra round-trips), ACK waits, and head-of-line blocking — if one segment is lost, later segments already received must wait for the retransmission before being delivered in order. Real-time apps avoid this by using UDP and handling loss at the application layer.

Answer: (a) TCP (ordered, complete file). (b) UDP (timeliness over retransmission). (c) UDP (single fast datagram, TCP fallback if large). (d) UDP (fresh updates supersede lost ones). TCP's reliability costs handshake round-trips and head-of-line blocking, which real-time UDP avoids.