Episode 1 — Fundamentals / 1.3 — Internet Protocols

Interview Questions: Internet Protocols (TCP & UDP)

Practice questions with model answers for transport-layer topics commonly asked in software engineering, networking, and backend interviews.

How to use this material (instructions)

  1. Read lessons in order — README.md, then 1.3.a → 1.3.e.
  2. Practice out loud — 60–120 seconds per question; avoid reading the model answer mid-answer.
  3. Draw timelines — for handshakes, interviewers reward clear sequence diagrams.
  4. Pair with exercises — use 1.3-Exercise-Questions.md for drills.
  5. Quick review — skim 1.3-Quick-Revision.md the night before.

Beginner (Q1–Q6)

Q1. What is TCP, and how does it differ from UDP?

Model answer:

  • TCP is connection-oriented, reliable, and ordered. It establishes a session (handshake), uses sequence numbers and ACKs, retransmits losses, and applies flow control and congestion control. Best when correctness and completeness dominate (HTTP/1.1–2, SSH, SMTP, most APIs).
  • UDP is connectionless and best-effort: no built-in reliability or ordering. Lower overhead and no “wait for retransmit” at the transport layer—great for latency-sensitive or loss-tolerant workloads (VoIP, many games, DNS for small queries). QUIC/HTTP/3 builds reliability on top of UDP with stream independence.

Q2. Explain the TCP three-way handshake.

Model answer:

  1. SYN — client picks an ISN and asks to start a connection.
  2. SYN-ACK — server acknowledges client ISN and sends its own ISN.
  3. ACK — client acknowledges server ISN.

Now both sides agree on starting sequence numbers and can send application data. This costs about 1 RTT before data can flow (client may piggyback data on the third segment in some cases).

Q3. Why does TCP use congestion control?

Model answer:

Without congestion control, many TCP senders could blast packets into a congested network, causing collapse (massive drops, retries, worse delays). Congestion control algorithms adjust the sending rate based on signals like packet loss and RTT (and modern approaches like BBR use bandwidth/RTT estimates). Goal: high throughput without harming the network.

Q4. What is a SYN flood?

Model answer:

An attacker sends many SYN packets (often with spoofed source IPs) causing the server to allocate state for half-open connections waiting for ACKs. Defenses include SYN cookies (stateless SYN handling), rate limiting, firewalls, and DDoS mitigation services.

Q5. Why is UDP used for DNS queries (typically)?

Model answer:

DNS queries are often small request/response pairs. UDP avoids TCP’s handshake overhead for a single exchange. If the response is too large or truncated, DNS may fall back to TCP (or use mechanisms like EDNS).

Q6. What is head-of-line blocking, and how does QUIC help?

Model answer:

With HTTP/2 over TCP, a lost TCP segment can delay all multiplexed streams until the loss is repaired—TCP-level head-of-line blocking. QUIC runs over UDP and provides per-stream reliability, so one stream’s loss does not necessarily block unrelated streams the same way.

Intermediate (Q7–Q10)

Q7. Compare TCP and UDP for building a real-time game.

Model answer:

Game state updates are frequent; late state is often as useless as lost state. UDP avoids pausing all streams for a retransmit of stale data. Reliability for critical events can be added selectively at the application layer (or via a protocol like QUIC). Chat/login might still use TCP/TLS for simplicity.

Q8. What does “TLS is not TCP” mean in the context of HTTP/3?

Model answer:

HTTP/3 uses QUIC over UDP, not TCP. Security is provided by TLS 1.3 integrated with QUIC (different framing than “TLS on top of TCP”). Same HTTP semantics, different transport and handshake story.

Q9. Explain NAT timeouts for UDP vs TCP (conceptually).

Model answer:

NAT devices track flows. TCP has clear connection lifecycle signals; UDP has less explicit connection state, so mappings may expire faster unless keepalives/heartbeats refresh them. That’s why long-lived UDP apps must handle NAT refresh explicitly.

Q10. When would you still choose TCP for an internal service?

Model answer:

When you want kernel-supported reliability, simple debugging, universal firewall compatibility, and you don’t need QUIC’s features—especially for request/response RPC over HTTP/2, databases, message brokers over TCP, etc.

Quick-fire

QuestionShort answer
Does UDP guarantee delivery?No
Does TCP guarantee bounded latency?No
Is DNS always UDP?No (TCP fallback / large responses)
Can reliability be implemented over UDP?Yes (e.g., QUIC, app protocols)

Interview tips

  1. Start with definitions, then trade-offs, then examples.
  2. Mention HTTP/3/QUIC when discussing UDP today—it shows currency.
  3. Separate reliability vs latency vs throughput—they are different axes.

← Back to 1.3 — Internet Protocols (README)